Debugging huge memory leak in application

Question

My application has just leaked 1.5GB of memory. I guess since I don't have a ton of data available to me, I'm assuming that it's leaked the memory, but it could also just be holding onto it.

I'm currently using perfmon to gather as much information as I can, to try to understand what could be causing the problem. I don't have a whole lot of leads at this point, and was hoping to get more hints from people here.

1. The first thing I can say is that I do not implement IDisposable in any of my classes. However, I know I do not call Dispose on any of the GUI elements, like SolidColorBrush. As my app isn't graphics-intensive by any means, I figure this can't be causing the problem. However, I will add the necessary calls.

2. I don't know if I'm using any other classes in the framework that implement IDisposable. I read a post here on SO about FxCop. I installed and used it to analyze my assembly, but it seems to only check for my own classes' correct implementation of IDisposable. Is there another tool that can tell me ALL classes that implement IDisposable?

3. I'm currently using WF in my application, and WFs are constantly being launched and finished. Perfmon shows that WFs are ending properly, and I am using the "using" keyword, which I understand deals with proper disposal for me.

4. Is there a simple way to tell if the memory being "leaked" is from unmanaged or managed code?

5. The app was using 77k+ handles at the time I got the OOM exception.

Any tips on how to proceed next would be greatly appreciated. I am planning on running the app again and monitoring the performance counters, and maybe stubbing out certain calls. I can also run the simulation for comparison's sake, since in that mode it won't call into my C DLL.

Answer 1

Before you go and invest in tools, you should try to find out what is leaking...

You already attached perfmon, and that is great. I would monitor the following perfcounters.

Process\PrivateBytes process\Handle Count Process\NonPagedPool

.NET CLR Memory*

If your private bytes is growing, as well as .NET CLR Memory\BytesInAllHeaps, it points to a managed leak. NEXT STEPS: Take a process dump and analyze using CLR Profiler, or alternately, attach windbg.exe to the process, load the sos extension dll, and analyze your managed heap for leaks.

IF private bytes is growing, without a corresponding increase in .NET CLR Memory* counters, then it points to an unmanaged leak. You will have to attach windbg.exe to the process and use the !heap extension to examine the process heaps.

If you are seeing a monotonically increasing HandleCount as well as NonPagedPool, then you have a handle leak - this can be in managed code, or native code. You will have to figure out which handles are leaking - you can use processmon.exe from sysinternals to get a list of handles,and investigate further.

Hope this helps.

Answer 2

Tess Ferrandez has a number of blog posts that could be of interest to you.

• .NET Memory Leak reader email: Are you really “leaking” .net memory

• .NET Memory Leak: To dispose or not to dispose, that’s the 1 GB question

Also ANTS Memory Profiler is a great tool for finding leaks.

Answer 3

Red-Gate has a memory profiler (http://www.red-gate.com/products/ants_memory_profiler/index.htm) that is extremely useful for these sorts of things. I highly recommend it. 30 day trial.

Randy

Answer 4

Not directly answering your question, but I always use Process Explorer which shows process Virtual Size, Working Set, Gen 0,1 and 2 Collections and private Bytes (related to unmanaged memory). Basically it's just a nice UI for regular windows Tasks Manager, and performance counters. Can help you observe the memory-related behaviour of your application.

Answer 5

Use CLR Profiler to figure out what you're leaking. Then fix it.