UPD: I got now some callstack of the crash, but for old ver v.121-dbg, for which I have created stripped pdb, as I described early.

No linenumbers info, But looks better

UPD: @win32ss, I have seen additional pdb's you have uploaded here
https://github.com/win32ss/supermium/releases/tag/v122-hf
It contains only information about object modules. And no other info, including function names. Its only 5 Mb. And useless.

Can you upload this #338 ?, as we discussed at the bottom, so I will ty.

UPD: got the SallStack using new updated PDB. Pdb is ok for now.

Callstack is near some as I got before for v121-dbg
So what about the bug ?
@win32ss, What do you think about this Call Stack of functions?

I see some garbage, called from function. at 0x0211e200 :

Why the code crashes, while calling Win32 API CreateWindowExW() ??
@win32ss, What is inside win32 here ?

I'm got more precise results:

1. Its a CallStack:

2. Its a function mixed code, where problem occured: register edi has garbage :

3. Its a function source code:

4. Its a function, which called in normal situation (OnWndProc) :

But instead called some garbage from 0x0211e200...

So "window" pointer or its fields have garbage. I can't see fields contents, because VS2010 dont show it. (Dont know about other VS versions (later), they are not compatible w/remote debug on XP)

Any idea if these failed calls came from WM_NCCREATE or not?

I wonder if the WindowUserData got overwritten with garbage after the window was created, as the WindowImpl is inherited by HWNDMessageHandler, and the pointer to that instance of WindowImpl is passed to CreateWindowExW as the lParam value, which is then set as WindowUserData on the WM_NCCREATE message. Is there anything that could be hooking the windows and potentially overwriting the WindowUserData?

The bug was found by me and fixed.

The bug was in my own (and very old) application layer compatibility dll from 2009 year for DWMAPI.dll for XP.
The function DwmExtendFrameIntoClientArea()
Bug was with missing __stdcall specifier, so default __cdecl was applied by compiler.
As result, the returned ESP was wrong.