WinDbg Address Summary

Question

Our wcf service hosted in IIS crashes (w3wp.exe ~ 1.6 GB) as the user load increases. We have got a dump through Debug Diag and ran this command in windbg. This is the outpu

Answer 1

WCF (Windows Communication Foundation) is a .NET technology. .NET does not make use of the Windows Heap Manager, so using any !heap command will not work for .NET. No wonder that it's small.

Instead, the .NET framework has its own memory manager due to garbage collection. You already used the correct command !eeheap -gc to display information about the .NET heaps. The last line of that command says:

GC Heap Size:            Size: 0x175de850 (392030288) bytes.

So .NET is responsible for almost 400 MB of <unclassified> (<unknown>) memory. The rest could be caused by

• direct calls to VirtualAlloc() of course
• allocations via the Windows Heap Manager that are larger than 512 kb (see the statement by Sasha Goldshtein). This could be some C++ code, for example. Working with images or video could often fall into this category.
• some versions of MSXML
• potential other garbage collecting memory managers, e.g. the heap manager from Java (a guess, I never verified, but the Windows Heap Manager does not work well for garbage collecting)

If these values remain constant, there's nothing to worry about. But if it increases, this might indicate a leak. I personally consider those 87000 timer callbacks as a potential source. What are all those timer callbacks doing? Are they ever able to finish their work?

79baa808    87474      1749480 System.Threading._TimerCallback

Answer 2

About unclassified, a lot of posts on the Internet show that in late versions of WinDBG unclassified entries has just replaced the things that were mapped to different regions before. In previous versions of debugger you had these RegionUsageIsVAD, RegionUsageImage.

On my side, I also have a lot or unclassified entries in !address -summary output, but it doesn't prevent me from future debugging.

No, go back to your other results:

According to my experience with WinDBG, if eeheap shows ~300Mb of memory when MEM_COMMIT gives 1.3Gb, it could be a native memory leak.

See CodeProject on how you could catch it.

Note, that you possibly won't have stacks when running !heap -p -a, so you need to run your process with proper gflags before debug. You can read more about it

Then, you may possibly got another, simpler situation with repeated strings. I've run into such situation one time and described it.