where did my memory go? large private bytes count

Question

I have a WPF app that among other things display a lot of images, large and small. My problem is that the app uses a lot of memory and I cannot figure out where it's coming from.

The scenario, when stressing the app some I get this graph in perfmon:

http://www.imagechicken.com/uploads/1244548604007097000.jpg

The big black line is Process\Private bytes and the other lines are the CLR mem counters (the pink one is Total committed bytes)

In numbers in the graph are:
Private bytes ~ 350 Mb
Committed bytes ~ 100 Mb

I have been digging around a lot with WinDbg and other tools, and they all report that the managed stack behaves (!eeheap reports total managed stack of around 100 Mb)

I've been poking around with apps like LeakDiag,LDGrapher but found nothing.

So, finally to my question, how do I proceed in finding out where my memory is going?

Even just starting the app uses 100Mb in committed bytes but 190Mb in private bytes.

References:

I've read a lot about this, among others on the great sites:

Tess Ferrandez: http://blogs.msdn.com/tess/archive/2009/02/27/net-memory-leak-reader-email-are-you-really-leaking-net-memory.aspx

Rico Mariani: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

MSDN mag: http://msdn.microsoft.com/en-us/magazine/cc163528.aspx

Answer 1

I had a similar problem in a WPF application, and used UMDH to track where the native memory was being allocated. (Note that it is usually helpful to set _NT_SYMBOL_PATH to get good stack traces from the OS components.

The logs showed that almost all of the memory was being allocated in the video driver. I found that the driver was more than a year out of date; I installed the latest version from the manufacturer's website and that fixed the problem.

Answer 2

Just because your application uses a lot of memory doesn't necessary mean that you have a memory leak. From the information in your question it is difficult to assert what may be wrong.

When troubleshooting managed memory leaks with WinDbg I do the following:

• Get an overview of the heap usage with !eeheap (this reports the heap usage and not the stack as you mention - each stack has a default size of 1 MB, so unless you have changed this there's no way you can use 100 MB on the stack)

• Do a !dumpheap -stat to find out what is on the heap. Chances are that if you have a memory leak the guilty type(s) will be among the top consumers. To get an idea of how heap usage develops you can resume your application, break it a little later and then repeat the !dumpheap -stat command.

• If you find any types with more instances than you would except, list those using !dumpheap -mt <MT of type>. This will list all the instances of the particular type. Pick random instances and check roots using the !gcroot command. This will tell you what keeps the instances in question alive. If there are no root these instances will be collected at some point.

UPDATE to reply to your comments:

The managed heap is only a part of a managed application's memory footprint. Remember, that a .NET application is really an application inside another application - the host process, which loads the CLR, which in turn loads your application. So before your application starts to use any memory the CLR has already taken a fair share. On top of that .NET applications store both MSIL code and JIT compiled code as part of the foot print. The CLR takes up space for various bookkeeping stuff as well (e.g. the CLR creates two additional AddDomains for internal use).

The numbers you give do not strike me as over the top, but since I don't know your application it is hard to say if the are excessive.

100 MB on the managed heap could be okay, depending on what your application is doing. Did you check the heap? And if so what did you find?