Dmitry Jemerov's Weblog

Analyzing memory usage with LeakDiag

Yesterday, when doing a scan of blogs.msdn.com, I noticed a reference to a blog of Slava Oks, who seems to be working on low-level features of SQL Server (like memory management). In one of his posts he wrote about a little-known utility from Microsoft Product Support, called LeakDiag.

The tool works by intercepting the memory allocation functions in a process, recording the call stack of every allocation and logging the allocations grouped by call stack. It can work on many different levels – VirtualAlloc(), heap allocation functions, C runtime memory allocator and others.

The most interesting results for Omea were obtained by VirtualAlloc() traces. We have really good tools to analyze the usage of managed memory by the Omea process (in particular, we are using SciTech Memory Profiler). But the large difference between the size of the managed heap and the VM size of the process reported by Task Manager has always been somewhat of a mystery for us.

Now, with LeakDiag and a small Python script I wrote to post-process its results, I can get a complete breakdown of where our virtual memory goes. Later I’ll publish some more details on the results of my analysis.

The main problem with LeakDiag is that it can only attach to a process which is running, so the first bunch of allocations made at process start are not caught by it. I tried to attach LeakDiag to a process halted in the debugger immediately after creation, but it seems like attaching LeakDiag so early interferes with USER32 initialization, and some very weird effects result – basically, Omea cannot initialize its user interface completely. So, instead of that, I made an option to show a message box on entry to the Main() function, and attach LeakDiag when the message box is shown.

Another tip is that the option “Use DbgHelp StackWalk APIs to walk stacks” does not really work for managed processes – if it’s enabled, LeakDiag hangs when writing the log.