Best Practice: A Summary of Normal Way to Debug Memory Leak

Step1. Is it really a memory leak?

http://blogs.msdn.com/tess/archive/2009/02/27/net-memory-leak-reader-email-are-you-really-leaking-net-memory.aspx

Step2. Determine .NET memory leak or native memory leak

http://blogs.microsoft.co.il/blogs/sasha/archive/2008/07/13/is-it-a-managed-or-a-native-memory-leak.aspx

If it is a .NET memory leak,

Run SOS commands in Visual Studio or windbg upon the process and see what’s too big. You can start with:

!dumpheap -stat

!eeheap (check the size of all heaps reported there)

!dumpdomain (check to see if you have an out-of-control number of app domains)

!address -summary (does anything obvious pop out?)

From that point forward, investigating the issue is dependent on what was “too big” in the output of the commands above.

1. If it’s too many managed objects, check:

a. Are they considered dead (!gcroot) but the GC hasn’t freed them? Probably a CLR issue.

b. Are they considered live (!gcroot)? Then you need to track down what’s holding references to them.

2. If it’s too many app domains or modules within an app domain, you’ll need to check to see when/why your program loads so many and when it’s supposed to unload them.

3. If it’s other weird heap issues (loader heaps (high/low frequency) too large, or other issues similar to that) then it’s likely a CLR issue, or at least you’d need a CLR dev to help figure it out.

If it is a native memory leak,

These tools can help you:

1. UMDH http://support.microsoft.com/kb/268343

2. LeakDiag http://mcfunley.com/cs/blogs/dan/archive/2005/12/11/674.aspx

3. “!heap -l” command in windbg

4. Enable pageheap, and use the "!heap -p -a" in windbg

5. Debug CRT http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

Other Reference materials

Book: Advanced Windows Debugging

http://advancedwindowsdebugging.com/

Tess’s .NET Debugging Labs

http://blogs.msdn.com/tess/archive/2008/03/17/net-debugging-demos-lab-6-memory-leak.aspx