Troubleshooting Memory Leaks With Just a Dump.

[JMH]

Hello debuggers, the debug ninja is back again. Sometimes we have a scenario where a process is using a lot of memory, and the only data we are able to get at the moment is a user dump. Ordinarily data from tools such as umdh or xperf would be preferable because they provide memory usage data over a period of time and can include call stack information. However, umdh requires restarting the process (which loses the state of high memory usage), and xperf requires the installation of the Windows Performance Toolkit which may not always be an immediate option.

When we have such a dump we may not be able to specifically identify what piece of code is generating the high memory usage, but we may be able to narrow the scope of troubleshooting to a specific dll.

The first thing we need to do is identify what type of memory is using most of the address space. The debugger command !address –summary allows us to do this:

http://blogs.msdn.com/b/ntdebugging...leshooting-memory-leaks-with-just-a-dump.aspx

 

[Vir Gnarus]

Sweet! This sucker has evaded me. I normally check their blog frequently but this one just slipped past.

A couple things of note here:

1. This will not work with a minidump.
2. This was done with a user mode dump of a process, not a kernel dump. Be aware that if these commands mentioned do work with a kernel dump, the output may be very different as it displays overall kernel memory usage as opposed to being specifically related to just this process.