I got an email today on an issue that I think is pretty common when you try to memory leak analysis on a dump with debug diag.
They had set up a leak rule in debug diag to monitor for leaks and then ran the memory analysis on it to see what was leaking and the results looked something like this:
|Warning||mscorwks.dll is responsible for 372.46 MBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:
mscorwks!EEVirtualAlloc+119: 312.00 MBytes worth of outstanding allocations.
mscorwks!EEHeapAlloc+142: 60.46 MBytes worth of outstanding allocations.
|If this is unexpected, please contact the vendor of this module, Microsoft Corporation, for further assistance with this issue.|
So what does this mean? Is mscorwks a really leaky component?
Turns out that debug diag leak monitoring feature is really good when it comes to native leaks (non .net), and not so good with high .net memory usage.
The reason for this is pretty simple. If you have a native component (like a COM+ component) making allocations etc. debug diag will pick up the stacks that did virtualalloc or heapalloc and point out the ones that haven’t de-allocated their memory so you can see stacks that still have outstanding allocations.
As most of you know, memory management in .NET is centralized through the garbage collector, so this means that any and all memory used for .net objects is actually allocated by the GC (through functions in mscorwks.dll). This means that when you use something like debug diag, that focuses on native allocations, it will seem like mscorwks.dll is leaking, while what is really happening is that you have growing .net memory usage.
The reason it says for you to contact Microsoft is because mscorwks.dll is part of the Microsoft .NET Framework, and while you are welcome to call our support to troubleshoot these kind of things, it will likely come down to high memory usage caused by the application in question.