HDC memory never released?

[rquattlebaum]

While trying to reduce the RAM footprint of my program, I found that the HDC (printer device context) never releases the memory it allocates. Is there a way to free up the 4 megabytes of memory used by the CDC?

I've included sample code with comments below. I'm running on XP Pro, so some of the things I do may be specific to NT/XP programming.

/////////////////////////////////////////////////
HDC hdc;
char szName[256];
GetProfileString(TEXT("Windows"),TEXT("Device"),_T(",,,"), szName, sizeof(szName)); // Get default printer info

CString strTmp = szName ;
if (strTmp.Find(",") > 0)
strTmp = strTmp.Left(strTmp.Find(",")) ; // Parse out the printer name

// The CreateDC() call consumes 4 megabytes of memory...
hdc = CreateDC(NULL, strTmp, NULL, NULL) ;

// Code to do printing goes here

// Try to get rid of the hDC and it's memory...
DeleteDC(hdc) ;

// At this point I'm still out 4 megabytes of memory - and it is never recovered until the program exits.
// I've also tried using PrintDlg() and the MFC equivalent CPrintDialog() to get a DC. Same problem with memory in all cases.

[Yves M]

It may be that you still have some objects selected into the DC when you try to call DeleteDC.

[rquattlebaum]

This is not the case. I created a program that does nothing but make the call to CreateDC(). I then immediately call DeleteDC(). The memory allocated by CreateDC() is never released.

Try it and see!

[Yves M]

Does DeleteDC return an error ?

[rquattlebaum]

It returns TRUE. The documentation indicates this means a successful delete.

[Yves M]

Which operating system are you running this on ?

[rquattlebaum]

"Microsoft Windows XP Professional Version 2002"

[SilentJackqh]

Sorry to interrupt just wanna ask, how do u know that they consumes 4 MB ?

[rxbagain]

I think, it's not a problem with CreateDC. The reason why your memory consumption grows that big is that when you call CreateDC, GDI32 will load all DLLs and drivers as needed by the operation. You can notice it in the debug window that when you call the CreateDC it will load many DLLs and each of them consumes memory resource.

Hope it will clarify your concern

[rquattlebaum]

I will answer SilentJackqh's question below my response to rxbagain...

Thanks for the clue, rxbagain. This may be the information I need. If I can find out what DLLs are being loaded, then maybe I can manually force them to unload. Ongoing memory usage is critical in my application, so I'm looking to remove every possible megabyte.

SilentJackqh - On NT/2000/XP Pro systems you bring up the Task Manager. and select the Processes tab. This lists all running processes and the amount of RAM and CPU time they are consuming. Since this is an always-on-top window, you can single-step through your code and see which line(s) bump up memory usage.

[Amn]

I believe rxbargain is right. For one thing, you do not have direct control for memory allocation several layers deep under WinAPI calls. Windows, by the way, has its own garbage collectors, so when you call a DeleteObject or DeleteDC, the object is marked for deletion. It may be later reused for other means, and the same behavior share all your loaded WinAPI DLLs which you did not allocate yourself but indirectly asked to. This is normal behavior.

The memory footprint the Task Manager reports is not what you might want to call a memory footprint, but rather an amount of memory, the allocation of which originated from your application or process. This means, that EVERY SINGLE BYTE that originates from your process, including CRT, CreateThread and CreateProcess call consequences, it will be tracked by Task Manager. Do not pay too much attention to it, rather use the debugger which will track your memory leaks. There is no reliable way to obtain memory footprint, because it is simply a too broad of a concept: Will you count the stack frame your program uses which is 1Mb for most Win32 applications ? Will you count all the Windows handles your program indirectly creates through its lifetime ?

Hope this helps In short: Memory in Windows is a bowl of chicken-chop soup, and while you are trying to count the chops, the soup gets cold