Unmanaged memory leak in mscorwks helps analyze

Question

History:

We encounter an unmanaged memory leak in our .NET 2.0 application. The process after startup consumes about 150 MB (most of them are managed .NET, object states, etc.). After about 12 hours of operation, consumed up to 800 MB, and after the next 12 hours, the process has about 1.8 GB of RAM. I just tried JetBrains.NET Memory Profiler, ANTS, .NET Memory Profiler (and maybe the following 2 mem profiles available on the market), none of this helps me because, as I discovered later, our process consumes so much memory in an unmanaged area that is not managed. To detect this, I used a Perf monitor with counters: Private Bytes (Process) and # Bytes in all heaps (.NET CLR Memory), where Private Bytes consume about 90% of the total memory allocated by the process. This is why I switch to unmanaged debugging.

DebugDiag: So I run debugdiag for the process and get a full dump, here is a snapshot of it:

• mscorwks.dll (a well-known Windows memory manager) is responsible for 781.73 thousand ounces of unpaid allocations. These distributions apparently arose from the following modules (modules) and Function (s):

• ntdll.dll (a well-known Windows memory manager) is responsible for an outstanding allocation of 98.24 MB. These distributions, apparently, arose from the following modules and functions:

Top 4 Counting Functions

• mscorwks! EEHeapAlloc + 15b - 80,957 (s)
• mscorwks! CLRMapViewOfFileEx + 4a - 4,171 location (s)

Top 4 features by size

• mscorwks! EEVirtualAlloc + 15b - 117.50 MB
• mscorwks! EEHeapAlloc + 15b - 15.03 MB

Search for logs found:

Feature Details

Function mscorwks!EEVirtualAlloc+15b

• Distribution Type Virtual Memory Allocation
• Distribution Count (amount) 1471 (s)
• Distribution Size 117.50 MB
• Leakage Rate 73%

Function mscorwks!EEHeapAlloc+15b

• Type of distribution. Heap distribution.
• Count allocation 80957 (s)
• Distribution Size 15.03 MB
• Leakage Rate 72%

Function mscorwks!CExecutionEngine::CheckThreadState+fe

• Type of distribution. Heap distribution.
• Heap Handle 0x00000000`00000000
• Distribution of the 2nd distribution (s)
• Allocation Size 304 Bytes
• Leakage Rate 98%

Function mscorwks!CLRMapViewOfFileEx+4a

• Distribution Type Virtual Memory Allocation
• Distribution Quantity 4171 (s)
• Distribution Size 0 Bytes
• Leakage Rate 73%

I want someone to push me in the right direction, how can I find a memory leak from this dump? I can load the dump into windbg and run the standard set of windbg commands, but I don’t know which ones are the right commands to isolate the leak.

I can provide a complete dump if someone wants to help with this.

Answer 1

Looking at the dump file, it seems to be a managed leak, but not on a managed heap. The dump indicates that the managed heap is quite small, but the bootloader heap is 1 GB. The process has over 35,000 dynamic assemblies. I looked at some of them and they seem to be serializable (XML and binary). Take a look at this blog post . He describes a similar problem.

Answer 2

My favorite way to debug .NET and Silverlight memory leaks is using the SOS extension. See here for a quick walkthrough: http://blogs.msdn.com/b/ricom/archive/2004/12/10/279612.aspx

What I usually do:

• ! DumpHeap -stat to get a list of what objects exist in memory; this usually indicates the source of the problem (for example, if I see a million tiny objects that should be used only once and thrown away).
• As soon as I know what type of object causes this, I will give a list of such objects using! DumpHeap and accidentally get the roots of several of them (! GCRoot). This will usually indicate which object unexpectedly contains links to leaking objects.

This assumes that you are dealing with a managed memory leak (the link is stored where you do not expect it). This will not help if you are dealing with unmanaged memory leak, but it is much less likely if your application does not do a lot of manual unmanaged memory management (for example, sorting objects for P / Invoke).

Answer 3

Using weak links can reduce memory usage http://en.wikipedia.org/wiki/Weak_reference .. this is very common, but as soon as it saved me almost several times. >