Am I crazy? Is there a bug in a so simple code?

[VictorN]

Don't trust Task Manager!
Have a look at How Big Is My Program? essay.

[juern]

I am aware of the fact, that the TaskManager is not showing used memory but used address space. I am just worried about the fact, that the address space is growing bigger and bigger even if there should be enough free space to address in it.

[streamer]

I'm using Process Explorer to check detailed information on running programs, memory leaks, handle leaks. It can be downloaded from https://technet.microsoft.com/en-us/.../bb896653.aspx. Its far way better than using task manager for the same purpose.

[juern]

Yes the Process Explorer is quite handy. Thanks for the link.

But still it doesn't change the fact that the working set/private bytes are increasing constantly ~4KB/second and continues over 6 hours without any sign of change.

[juern]

I made some more testing. The program will ultimately run out of memory and CreateDialog fails (of course).

Can anybody explain that to me? The only thing that would come into my mind would be a leak or memory fragmentation. I don't see a possible leak (except it is in the WinAPI itself) but the constant memory growth does not look like fragmentation.
Are there any other things I am not aware of that could produce such a result?

[VictorN]

It is hard to say something about the reason of your problem without seeing your code. Could you post a small project reproducing such a behaviour?

[juern]

I believe it is essentially the same as the original poster.

while (true)
{
	HWND hwnd = CreateDialog(NULL, MAKEINTRESOURCE(IDD_ABOUTBOX), NULL, DefWindowProc);
	::DestroyWindow(hwnd);
}

or

while (true)
{
	CDialog dlg;
	dlg.Create(IDD_ABOUTBOX);
	dlg.Destroy();
}

and other variations, like with a CAboutDlg dialog created by the app wizzard.
They all produce the same result.

First I thought WM_NCDESTROY is not called and the dialog will not be destroyed properly, but that is not the case.