Question

We have a .NET application which our customers consider too large for mass deployment and we would like to understand what contributes to our memory footprint and is it possible to do any better without completely abandoning .NET and wpf.

We are interested in improving both Total Size and the Private Working Set (pws). In this question I just want to look at pws. VMMap typically reports a pws of 105 mb. Of this 11mb is image, 31mb is heap, 52 mb is managed heap, 7 mb is private data and the rest is stack, page table etc.

The largest prize here is the managed heap. We can account for approx 8mb of the manged heap directly within our own code, i.e. objects and windows we create and manage. The rest is presumable .NET objects created by the elements of the framework that we use.

What we would like to do is identify what element of the framework account for what portion of this usage and potentially re architect our system to avoid their use where possible. Can anyone suggest how this investigation can be done?

Further clarification:

I have used a number of tools so far, including the excellent ANTS profilers and WinDbg with SOS, and they do allow me to see the objects in the managed heap, but of real interest here is not ‘What?’, but ‘Why?’ Ideally I would like to be able to say, “Well, there a 10mb of objects been created here because we use WCF. If we write our own native transport we could save 8mb of that with x quality risk and y development effort.”

Doing a gcroot on 300,000+ objects is not possible.

Answer 1

WinDbg might be a useful tool for you. It comes with the Debugging Tools for Windows.

Once your app is running, you can attach WinDbg and explore the managed heap. (Or you can take a memory dump and explore it offline). It will be able to very quickly tell you the object types consuming the largest amounts of memory.

First you will need to load the SOS extension which enables debugging of managed applications:

.loadby sos mscorwks

Then you can use !dumpheap to get heap information, the -stat switch gives overall heap info on which types are allocated:

!dumpheap -stat

The -type parameter gives specific information on allocated instances of the specified type:

!dumpheap -type System.String

There’s a bunch of other commands you might find helpful like:

• !gcroot – to follow an allocated object back up it’s root to find why it is in memory.
• !dumpobj – to dump out a specific object so you can see it’s contents.
• !EEHeap – to give some general heap stats.

MSDN has a full list of SOS commands and their switches.

WinDbg is a pretty complex tool, but there are lots of tutorials and guides online if you search to help you get started. Alternatively, I can recommend the book Debugging Microsoft .NET 2.0 Applications by John Robbins which goes into some good detail in the .net debugging abilities of WinDbg and SOS.

You can load the SOS extension into visual studio instead by entering this into the immediate window, then you should be able to use the SOS commands directly in the VS immediate window:

.load SOS.dll

You also might find the CLR Profiler and this Usage guide helpful.