Heap Corruption while using CreateWindowExW

Question

I have some problems with heap corruption. The warning can be observed while using CreateWindowExW function. I know that it is usually a memory error, but how could I search it out in such situation? There are no new variables before calling CreateWindowExW and I can't step into this function. Here is the code.

HWND GetMainWnd(HINSTANCE hInstance){
static HWND hWnd = NULL;
if (hWnd)
    return hWnd;

RETURN_AT_ERROR(hInstance, NULL);

WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };
wcex.style          = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc    = MainWndProc;
wcex.hInstance      = hInstance;
wcex.hCursor        = ::LoadCursorW(NULL, IDC_ARROW);
wcex.lpszClassName  = g_config->GetWndClass();

ATOM atom = ::RegisterClassExW(&wcex);
RETURN_AT_ERROR(atom != 0, NULL);

hWnd = ::CreateWindowExW(WS_EX_LEFT, g_config->GetWndClass(), 0, WS_POPUP | WS_MINIMIZEBOX | WS_CLIPCHILDREN, 0, 0, 0, 0, 0, 0, hInstance, 0);

return hWnd;}

On this string

hWnd = ::CreateWindowExW(WS_EX_LEFT, g_config->GetWndClass(), 0, WS_POPUP | WS_MINIMIZEBOX | WS_CLIPCHILDREN, 0, 0, 0, 0, 0, 0, hInstance, 0);

there is a warning message box

Windows has triggered a breakpoint in drm.exe. This may be due to a corruption of the heap, which indicates a bug in drm.exe or any of the DLLs it has loaded. This may also be due to the user pressing F12 while drm.exe has focus. The output window may have more diagnostic information.

I press "Continue" and it shows

Unhandled exception at 0x77dae753 in app.exe: 0xC0000374: A heap has been corrupted.

However CreateWindowExW returns a non-zero value and window is created as it should be...

Radiometer

Heap corruption often shows up after it has happened, so this function may just be pointing out the issue and no be related to it at all. Look at what you've done before you call this. – Medievalism

Knowing all the madness ensuing in your WndProc is potentially going to be telling for what may be corrupting your heap. – Sesquiplane

The heap corruption may have occurred before the call to CreateWindowEx, or during the evaluation of any of its arguments (e.g., g_config->GetWndClass()), or it may be happening in one of the message handlers invoked during window creation (like WM_CREATE). You'll have to narrow it down. – Pneumonoultramicroscopicsilicovolcanoconiosis

In my experience this is often due to clearing memory incorrectly, usually because the pointer to the memory is out of date, which corrupts the memory. – Leveller

Answer 1

As pointed out above, heap corruption is often detected after the real corruption has already occurred by some DLL/module loaded within your process. From your post it looks like this issue is windows platform specific so I would suggest you to use WinDBG/Pageheap and find out where actual memory corruption is happening. One very very good article about heap memory corruption analysis can be found from the book "Advanced Windows Debugging, Author: By: Mario Hewardt; Daniel Pravat" Chapter 06

https://web.archive.org/web/20171128180258/http://advancedwindowsdebugging.com/ch06.pdf

Serica

That book is simply outstanding, btw. – Sesquiplane

Well, you all were right: the deal was not connected with CreateWindowExW. I used WinDBG and Application Verifier and VS debugger.. So got deeper and find out that the reason was in absolutely another function while trying to free the heap. thx – Radiometer

Answer 2

Change

WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };

to

WNDCLASSEX wcex = { 0 };

You're initializing pointer members of WNDCLASSEX to non-null (but nonsensical values, namely sizeof(WNDCLASSEX)).

Talia

No, he isn't. tail-initialization zero fills remaining unspecified members. – Sesquiplane