Partilhar via

Debug Diag: mscorwks.dll is responsible for 372.46 MBytes worth of outstanding allocations

  • Artigo

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.

To troubleshoot these types of memory issues, a good start might be to go through the memory leak labs or to look at any posts tagged with memory.

Laters,

Tess

Comments

  • Anonymous
    October 09, 2009
    memory leak is a quite headache problem

  • Anonymous
    October 09, 2009
    This just means the memory has not been released, but not leak. Maybe the next GC could release the memory.

  • Anonymous
    October 11, 2009
    i learn asp.net from 1 year but today i see a girl programmer on internet i like this post but are you give me some other link for learn mvc or asp.net if yes send it to anirudhakumar.gupta@gmail.com