Why does the sum of objects in !DumpHeap -stat not match !EEHeap -gc?

Question

I'm looking at a full application dump in WinDbg, and trying to understand where my memory is being consumed.

I've parsed the output of !DumpHeap -stat and summed the total memory in this report, getting ~7 GB. By comparison, if I run !EEHeap -gc, it reports a total of ~11 GB.

Why is there such a big difference between the two reports? How can I find out where the additional 4 GB is going?

Answer 1

The value of !eeheap is the sum of the segment sizes allocated by .NET.

This value is always larger than the sum of output of !dumpheap. In some cases it differs much because there are only a few objects in some segments, e.g. pinned objects, which are used for native PInvoke or COM interop stuff. That can prevent .NET from releasing the segments. You can check for pinned objects with !gchandles.

Cross check the value of !eeheap against the <unknown> value reported by !address -summary. Assuming you have no native code that calls VitualAlloc() directly and you don't use MSXML, the value of !eeheap should be close to that.

Answer 2

I am dev from .Net team. I believe this might be a bug in SOS. For eeheap, the way we calculate the segment size is using the last object’s ending address in the segment minus the starting address of the segment. Then adding all those segment size together to get the total heap size.

Here is the code for sos eeheap(https://github.com/dotnet/coreclr/blob/bc146608854d1db9cdbcc0b08029a87754e12b49/src/ToolBox/SOS/Strike/eeheap.cpp), you can look at GCPrintSegmentInfo, GCPrintLargeHeapSegmentInfo and GCHeapInfo.

Sometime, due the object aligned in the segment, the segment size actually won’t equal the total objects size in the same segment. Also !DumpHeap filter out some object which isn’t alive. These two factors can cause the total size of objects listed by !DumpHeap is not equal to the !eeheap. But 4GB seems bigger than usual. It might be bug. But without something I can play with, I can't make the conclusion.

You can file us a bug using connect, we will take a look. Here is the intrustion https://connect.microsoft.com/IE/content/content.aspx?ContentID=29582. For investigation purpose, if you don’t mind, can you send us a program or a dump which can repro the problem you have? That will be helpful for our investigation. Thanks