Menu
Story:
We are facing unmanaged memory leak in our .NET 2.0 application. Process after start consume about 150MB (most of it is .NET managed, object states and so). After about 12 hours of running process consumed up to 800MB and after next 12 hours process have about 1.8GB of RAM. I just tried JetBrains .NET Memory Profiler, ANTS, .NET Memory Profiler (and maybe 2 next mem profiles available on market) none of this helps me because as i detect later our process consume that much memory in unmanaged area not managed. To detect this i used Perf monitor with counters: Private Bytes(Process) and # Bytes in All Heaps (.NET CLR Memory) where Private Bytes consume about 90% of all memory allocated by process. This is why i switch to unmanaged debugging.
DebugDiag: So i run debugdiag on process and get full dump, here is snapshot of it:
mscorwks.dll (a known Windows memory manager) is responsible for 781,73 MBytes worth of outstanding allocations. These allocations appear to have originated from the following module(s) and function(s):
ntdll.dll (a known Windows memory manager) is responsible for 98,24 MBytes worth of outstanding allocations. These allocations appear to have originated from the following module(s) and function(s):
Top 4 functions by allocation count
Top 4 functions by allocation size
Interesting logs found:
Function details
Function mscorwks!EEVirtualAlloc+15b
Function mscorwks!EEHeapAlloc+15b
Function mscorwks!CExecutionEngine::CheckThreadState+fe
Function mscorwks!CLRMapViewOfFileEx+4a
I want someone to push me in right direction how can i found memory leak from this dump? I'm able to loaded dump into windbg and run standard set of windbg command but i dont know which one are the right commands to be able to isolate leak.
I can provide full dump if anyone want to help with this.
387
Unmanaged memory: memory allocated outside of the managed heap and not managed by Garbage Collector. Generally, this is the memory required by . NET CLR, dynamic libraries, graphics buffer (especially large for WPF apps that intensively use graphics), and so on. This part of memory cannot be analyzed in the profiler.
Common Types of Memory Leaks. Leaks in managed platforms are effectively references to an element that is no longer necessary. There are many samples of this, but they all boil down to discarding said reference. The most common problem is caching.
Start the debug diagnostic tool and select 'Memory and handle leak' and click next. Select the process in which you want to detect memory leak. Finally select 'Activate the rule now'. Now let the application run and 'Debugdiag' tool will run at the backend monitoring memory issues.
A memory leak may happen when your app references objects that it no longer needs to perform the desired task. Referencing said objects makes the garbage collector to be unable to reclaim the memory used, often resulting in performance degradation and potentially end up throwing an OutOfMemoryException.
Looking at the dump file it does seem to be a managed leak, only not on the managed heap. The dump shows that the managed heap is quite small, but the loader heap is 1 GB. The process has over 35000 dynamic assemblies. I looked at a few of them and they appear to be serialization (XML and binary). Take a look at this blog post. It describes a similar issue.
57
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
