Find Memory Leaks or Infinite Loops From a Memory Dump with WinDBG

If you have a memory leak or infinite loop on production that you don't know how to reproduce easily on your development box, it's easy to investigate by analyzing a memory dump of the application running in production. If you can reproduce it on your development box, it's easier to use a profiling tool like JetBrains dotTrace or RedGate Ants Profiler.

Capture a memory dump

#1 -> Reproduce the problem on any machine

#2 -> Get a memory dump of the program while experiencing the problem

2a) Open Task Manager

2b) Find program in processes tab. Pay special attention to if the process name has a "*32", meaning 32-bit process

2c) Right click on process & choose create dump file

2d) A pop up window will show you where the memory dump was saved (usually C:\Users\#User#\AppData\Local\Temp\)

#3 -> Copy the memory dump to your development machine.

Analyze a memory dump

#1 -> Install WinDBG. (http://msdn.microsoft.com/en-us/windows/hardware/gg463009)

1a) When installing, check all the boxes for a full install, otherwise you won't get both the 32 & 64 bit versions.

1b) After installing, open this folder (C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\)

1c) Install both the dbg_x86.msi & dbg_amd64.msi files. (one of them will probably already be installed, based on your type of cpu, but you need both)

#2 -> Open the version (32 or 64 bit) of WinDbg that matches the type of memory dump you have. If the task manager process name had "*32", you'll need 32-bit WinDbg.

2a) C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe (64-bit)

2b) C:\Program Files (x86)\Debugging Tools for Windows (x86)\windbg.exe (32-bit)

#3 -> In WinDbg select File/Open Crash Dump from the menu.

#4 -> Open the memory dump .DMP file you created from the task manager

#5 -> Find out which version of the .NET Framework the program for your crash dump runs on. [3/3.5 are extensions of 2]

#6 -> Find the directory for the correct version of the .NET Framework on your computer (including 32/64 bit).

6a) C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319

6b) C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319

6c) C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

6d) C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727

#7 -> Type the following commands to load the .NET Debugging extension SOS into WinDbg

7a) .exepath+ C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\ (use the path for the .NET Framework directory corresponding to your app)

7b) lmv m clr (this loads the clr dll, which is the core of the .net framework)

Note: If you get an error, you can try this alternative .load c:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

7c) .loadby sos clr

Note: If you get an error, you can try this alternative .load c:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll

7d) .loadby mscordacwks clr

Note: If you get an error, you can try this alternative .load c:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

#8 -> You should now be setup to analyze the dump file. Here are a few helpful commands:

Useful Commands

Investigate Memory Leak

!dumpheap -stat

!dumpheap -mt <string MT> (shows addresses of all strings, you can use whatever datatype is using all the memory)

!do 02ebf628 (the # should be the memory address of the object you want to view)

!gcroot 02ebf628 (find the containing class for the object at # memory address)

Investigate High CPU

!threads

~5s (change context to thread id 5)

kb 2000
!clrstack

!threadpool

!runaway

~* kb 2000

~* e !clrstack

!pe (show current exception on thread)

!dso (print objects on stack)

You can try these random commands, but the best thing is to follow the walkthrough on the following blog that matches the scenario you're experiencing:

http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx