What is WinDbg <unknown> Memory?

Question

I'm debugging a Winforms application for a memory leak. In the dump file provided by the customer there is a large discrepancy between the unknown memory usage and the .NET Heap size. (Approximately 1000mb vs 200mb). So what is in the unknown segment other than the VirtualAllocs done by the CLR?

!eeheap -gc output

!address -summary output

Mumble

In a winforms app that is usually the pixel data required by Bitmap objects. Forgetting to call their Dispose() method is a very common bug. Windbg doesn't give much insight into this oversight. Run Task Manager and add the GDI objects and USER objects columns, ensure the values for your program don't climb constantly and don't get excessively high. And favor a managed memory profiler. And don't wait so long to start looking for the leaks so you don't drown in the data. – Inadequate

Just to add a little: Bitmap is a legitimately finalizable object. What GC does if you forget to forcefully dispose the object is queue it to a finalizer thread where it does get disposed at some indeterministic future time. Finalizable objects "literally die a second death" according to MS, and will only actually be freed after 1) A GC runs that places it on the finalizer queue after all references vanish. 2) The finalizer run on the object and frees the unmanaged bits, and then 3) GC runs again and frees the managed portion. – Compressed

Answer 1

Memory that is reported as <unknown> by WinDbg is memory that was allocated via VirtualAlloc(). Some commonly known sources are:

• .NET (because it has its own heap manager)
• direct VirtualAlloc() calls in your code
• C++ HeapAlloc() calls that are larger than some limit (512k if I recall correctly)
• MSXML
• Bitmaps (according to @Hans Passant's comment)

Elusion

Interesting fact about the behavior of HeapAlloc . Also thanks should go to Hans for mentioning bitmaps. Which is most likely the culprit. – Mumble