Memory Leaks - Part 2: Debugging Tools to Diagnose a Memory Leak

If you are reading this you may be in the unfortunate position of looking for an elusive and possibly intermittent problem in your production application. Debugging and diagnosing a memory leak or an OutOfMemoryException can be a daunting, intimidating and challenging task. Fortunately, there are a number of tools to help; some of these are "paid license" apps, but there are even more tools that are free. I'll discuss some .NET Debugging Tools available. I've used all of the following tools with the exception of SciTech .NET Memory Profiler. Each has its advantages and disadvantages. Personally, I prefer the free tools for several reasons:

1. Getting approval for licensing and purchase of a 3rd-party tool is an uphill task and you rarely have time to wait for the approval process when it is a production issue.
2. I find the feature set of a combination of the free tools gives you the largest "surface area" of features to help. Some are better at strict data collection, others have graphical views, some are static for post-mortem debugging, and others can do real-time analysis.
3. Even though these are free, they are very robust and provide just as much data as the paid license tools. A good example of this is WinDbg which was developed in 1993 by Microsoft for in-house debugging of the Windows Kernel.

Free Tools

Advantages

• Duh! It's free
• There are lots of tools to choose from
• All of the ones I've seen are from reputable and well-known companies.
• You can often find blog posts (ahem...), articles, reddit threads, etc. that can provide some direction for getting started.

Disadvantages

• Formal documentation can be lacking. Finding a blog post or article is great but comprehensive detail is often missing or at best glossed over. This can make getting started a bit more of a challenge if the tool is new to you.
• Your company may have restrictions on using free tools for fear of malware, liability, or other reasons.

• Windows Task Manager: taskmgr.exe. Make sure to make the following columns visible:
• Memory - Working Set
• Memory - Private Working Set
• Memory - Commit Size
• Threads
• Handles
• USER Objects (if WinForm or Native app)
• GDI Objects (if WinForm or Native app)
• Windows Performance Monitor: perfmon.exe
• Process Explorer (SysInternals)
• VM Map (SysInternals)
• Debugging Tools for Windows (WinDbg, SOS, Kernel Debugger, etc.)
• Microsoft Debug Diagnostic Tool (DebugDiag)
• Psscor2 - WinDbg debugger extension for ASP.NET 2.0, 3.5
• Psscor4 - WinDbg debugger extension for ASP.NET 4.x
• SOSEX from Steve Johnson (.NET 2.0, 3.5)
• SOSEX 4 from Steve Johnson (.NET 4.x)
• IISInfo - WinDbg debugger extension (included with DebugDiag)
• Microsoft Application Verifier
• CLR Profiler 2.0 (good for finding heap fragmentation)
• CLR Profiler 4.0 (good for finding heap fragmentation)
• Windows Performance Toolkit (xperf)

Licensed Tools

• RedGate Ants Memory Profiler
• Micro Focus DevPartner Studio (formerly Compuware)
• SciTech .NET Memory Profiler
• AQ Time Pro

Hope this helps!

Want to have "WinDbg and SOS-like" features in VisualStudio?

While I've become adept at using WinDbg and all of it's extensions to do post-mortem crash-dump analysis, I've not yet ventured down the path of live-debugging strictly with WinDbg.  Maybe I'm dense, but it's anything but intuitive to me.  Call me "new-school" but there's just something about having a real UI while debugging that makes me more productive.

So, if you've ever needed to use some functionality of WinDbg or SOS (and any of the other extensions) while debugging in VisualStudio, there is some hope...

I've added 2 feature suggestions on the Microsoft Connect website for two features:

1. View an object's rooted references at runtime - https://connect.microsoft.com/VisualStudio/feedback/details/637376/add-feature-to-debugger-to-view-an-objects-rooted-references
2. View an object's memory footprint/usage - https://connect.microsoft.com/VisualStudio/feedback/details/637373/add-feature-to-debugger-to-view-an-objects-memory-footprint-usage

If either of these are something you'd like to see in an upcoming version of VisualStudio, please click the links above and vote for them!


As a side note, if you can't wait for the next version of VisualStudio, there are 2 different workarounds in the meantime:

1. Load SOS into the Immediate Window as documented here:  http://msdn.microsoft.com/en-us/library/yy6d2sxs.aspx
2. The other option is to stop at a breakpoint in VisualStudio, and then attach WinDbg in "non-invasive" mode.

While these workarounds seem to be mildly satisfactory, it'd be great if these features were already built in to the VS Debugger - so vote!