Error Handling in user32.lib

Question

Error Handling in user32.lib

KevinL 0

CreateWindowEx is trying to call a NULL defined WndProc and silently crashes.

If I register a WNDCLASS like this:

WNDCLASSA wc =
    {
        .lpszClassName = "Test"
    };
RegisterClassA(&wc);

the class is registered successfully. But if I call CreateWindowExA() with that class the CreateWindowExA function is silently crashing without any error, because it is trying to call a NULL function.

Only the debugger is giving me an error. But nothing else.

Why is there no proper error handling for such case?

Like returning a NULL HWND and an error I can get with GetLastError()?

Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-18T11:01:22.56+00:00

Hi @KevinL

I'm looking into this and will get back to you as soon as possible.
KevinL 0 Reputation points

2026-03-18T11:07:18.83+00:00

The AI answers were incomplete. So for more clarification:

The AI here said that CreateWindowExA is actually returning a valid HWND and therefor no LastError is set. It crashes afterwards. But then the question is why does it even succeed if it crashes afterwards either way?

The reference that in the documentation it says: You must fill the structure with the appropriate class attributes. is also not really a hint since it is nowhere defined what appropriate attributes are?

(So what you MUST fill and what is OPTIONAL is not documented at all)
Darran Rowe 2,606 Reputation points

2026-03-21T15:41:03.66+00:00

My bet is that this is one of those "obvious" things. The window procedure basically controls the behaviour of the window. CreateWindowEx is documented to send 3 messages to created windows, WM_NCCREATE, WM_NCCALCSIZE and WM_CREATE. These three messages are then documented to go through the window procedure.

The documentation for WNDCLASS and WNDCLASSEX also gives hints as to what is optional. For the style, it tells you that it can be any combination of the class styles, 0 is valid if you don't want any of this behaviour. The class and window extra bytes are initialised to 0. The icon, small icon (for ex), cursor and brush handles all give an if/when null text. The same is true forthe menu name. This gives 3 for non ex and 4 for ex members that the docuemtation implicitly states must be set. The window procedure, the instance, the class name and, for ex, the structure size.

But if we then look at About Window Classes, under Elements of a Window Class, the three things that I mentioned above are all documented with either needs or requires. So all of this is documented, but in the usual documentation style for the Windows API, not all of it is in the structure or function documentation.
RLWA32 52,261 Reputation points

2026-03-21T16:37:26.53+00:00

It sounds to me like the Questioner is asking "why doesn't the CreateWindowEx function examine the window class and if it contains a null pointer for the window procedure return a null window handle to indicate failure and set an appropriate error code?"

I suppose the unsatisfying answer is because Microsoft didn't choose to do it that way.
Darran Rowe 2,606 Reputation points

2026-03-21T18:54:26.92+00:00

CreateWindowEx is in the Windows 3.1 SDK, so it is an old function. It could be a mix of reducing checks to make it perform better and the major assumption that people knew what they were doing.

I think this also now has the ironic thing that if CreateWindowEx is changed to check, it could introduce a compatibility issue.

2 answers

Your answer

Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-18T11:01:22.56+00:00

Hi @KevinL

I'm looking into this and will get back to you as soon as possible.
KevinL 0 Reputation points

2026-03-18T11:07:18.83+00:00

The AI answers were incomplete. So for more clarification:

The AI here said that CreateWindowExA is actually returning a valid HWND and therefor no LastError is set. It crashes afterwards. But then the question is why does it even succeed if it crashes afterwards either way?

The reference that in the documentation it says: You must fill the structure with the appropriate class attributes. is also not really a hint since it is nowhere defined what appropriate attributes are?

(So what you MUST fill and what is OPTIONAL is not documented at all)
Darran Rowe 2,606 Reputation points

2026-03-21T15:41:03.66+00:00

My bet is that this is one of those "obvious" things. The window procedure basically controls the behaviour of the window. CreateWindowEx is documented to send 3 messages to created windows, WM_NCCREATE, WM_NCCALCSIZE and WM_CREATE. These three messages are then documented to go through the window procedure.

The documentation for WNDCLASS and WNDCLASSEX also gives hints as to what is optional. For the style, it tells you that it can be any combination of the class styles, 0 is valid if you don't want any of this behaviour. The class and window extra bytes are initialised to 0. The icon, small icon (for ex), cursor and brush handles all give an if/when null text. The same is true forthe menu name. This gives 3 for non ex and 4 for ex members that the docuemtation implicitly states must be set. The window procedure, the instance, the class name and, for ex, the structure size.

But if we then look at About Window Classes, under Elements of a Window Class, the three things that I mentioned above are all documented with either needs or requires. So all of this is documented, but in the usual documentation style for the Windows API, not all of it is in the structure or function documentation.
RLWA32 52,261 Reputation points

2026-03-21T16:37:26.53+00:00

It sounds to me like the Questioner is asking "why doesn't the CreateWindowEx function examine the window class and if it contains a null pointer for the window procedure return a null window handle to indicate failure and set an appropriate error code?"

I suppose the unsatisfying answer is because Microsoft didn't choose to do it that way.
Darran Rowe 2,606 Reputation points

2026-03-21T18:54:26.92+00:00

CreateWindowEx is in the Windows 3.1 SDK, so it is an old function. It could be a mix of reducing checks to make it perform better and the major assumption that people knew what they were doing.

I think this also now has the ironic thing that if CreateWindowEx is changed to check, it could introduce a compatibility issue.

Answer 1

Taki Ly (WICLOUD CORPORATION) 150 Microsoft External Staff Moderator

Hello @KevinL ,

After reproducing the issue on my end, I understand your concern.

CreateWindowExA sends WM_NCCREATE and WM_CREATE during the call itself, before it gets a chance to return anything. So when Windows tries to call your procedure at address 0x00000000, the Access Violation may stop everything right there, which could be why CreateWindowExA never gets to return NULL or set a GetLastError code.

I suggest you can check lpfnWndProc before calling RegisterClassA. This way you could catch the problem early, where you still have control:


// Guard before RegisterClassA

if (!wc.lpfnWndProc) {

    // handle the error yourself here

}

Hope this clarifies your question. If you found my answer helpful, thank you in advance for following this guide to give feedback.

Thank you.

Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-19T07:32:13.07+00:00

Hello @KevinL ,

Regarding your follow up questions:

Looking at this more closely, the reason it "succeeds" is likely that CreateWindowExA and the message dispatch are designed as two separate responsibilities. From the API's point of view, its job is to allocate the window object and return a handle. Validating whether lpfnWndProc is actually callable may not be part of that, and that contract could sit with the caller at registration time, through RegisterClassA. So, when CreateWindowExA returns a valid HWND, it may have genuinely done its part correctly. The crash could then come later, when the system tries to dispatch a message and calls through the NULL pointer, and by then, CreateWindowExA has already exited. It might not be a case of "succeed and then fail" in the same operation, the two steps could be intentionally independent.

I see what you mean here, and I think this is a genuine gap in the documentation. The WNDCLASSA structure page describes each field individually but never explicitly labels any of them as required or optional, which is a genuine gap. That said, lpfnWndProc and lpszClassName could be considered effectively mandatory by design. Without a window procedure the window has no way to process any messages, and without a class name CreateWindowExA has no class to look up. The remaining fields like hIcon, hCursor, or hbrBackground would likely default to NULL gracefully, so the window can still create and operate without them, though none of that is stated explicitly anywhere, and I understand why that leads to confusion.

Hope this clarifies your follow up questions. If you found my explanation helpful so far, kindly leave your feedback following this guide.

Thank you.
Taki Ly (WICLOUD CORPORATION) 150 Reputation points Microsoft External Staff Moderator

2026-03-23T07:43:48.2866667+00:00

Hi @KevinL ,

I’ve shared an answer. Did you get a chance to look at it? If you have any questions, just drop a comment and I’ll try my best to help.
Darran Rowe 2,606 Reputation points

2026-03-23T15:50:36.1433333+00:00

@Taki Ly (WICLOUD CORPORATION)

The About Window Classes documentation under Elements of a Window Class does clearly state what is required and what is optional in WNDCLASS. By extension, with the documentation in WNDCLASSEX, it also states what is required in WNDCLASSEX. While it isn't all in one place, it is documented.
RLWA32 52,261 Reputation points

2026-03-23T16:05:07.32+00:00

From the documentation link posted by @Darran Rowe

Although a complete window class consists of many elements, the system requires only that an application supply a class name, the window-procedure address, and an instance handle.

Notwithstanding the documentation for the benefit of those who may be confused about a successful window class registration when the WNDCLASS structure contains a NULL hinstance as in the Questioners example --

From Private classes, superclassing, and global subclassing "Before continuing the discussion, I’ll first address the issue of leaving NULL in WNDCLASS.hInstance: The value NULL for the instance handle is not legal when registering a class. Each class is associated with a module instance, and NULL is not a module instance. The window manager autocorrects this mistake by registering the class under the module corresponding to the executable. This is the same special-case behavior you get if you call GetModuleHandle(NULL), so it’s not something completely out of the blue."

Answer 2

The code failed to specify a Window procedure in the class registration.

After setting the compiler in VS2022 to use C++ 20 a windows was successfully created with this -

WNDCLASS wc =
{
    .lpfnWndProc = WndProc,
    .lpszClassName = "Test",
};

Even so, I suggest you more completely fill out the WNDCLASS structure a documented at https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-wndclassa

In many cases, allowing an application to crash is often preferable to catching an exception or returning an error result and allowing execution to continue in a corrupted state.

Share via

Error Handling in user32.lib

2 answers

Your answer