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:
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.
memory leak is a quite headache problem
This just means the memory has not been released, but not leak. Maybe the next GC could release the memory.
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 firstname.lastname@example.org