WinDBG – Inspecting Memory in Managed Code

Although WinDBG has been around for a long time, it is still one of the great memory analysis tools for use with your managed code applications.  I recently went through the exercise of installing, configuring, and using WinDBG on my Windows 7 dev box and I thought I would post about just how useful and simple to use this tool can be.

Installing WinDBG:

Download it from it is a part of the debugging tools for windows SDK.  The download link should redirect you to the version that works with your version of Windows.


In order to get meaningful results from WinDBG, it needs to know the debug symbols used by Windows.  Configure this by selecting File -> Symbol File Path.  It is easiest to use the symbol file provided online by Microsoft.  Just add the value:

Basic setup is now complete.  That was easy!

Using WinDBG to examine an object in memory:

Now we get to the good stuff.  I used WinDBG to examine the memory of a Windows Service I wrote using C#.  You can attach WinDBG to a running process by clicking File->Attach to a process  Then just select your process from the list of all processes running on your machine.  I attached to my Windows Service and a prompt opened up.

At the prompt type:

.loadby sos mscorwks



Entering .loadsys into the WinDBG console

WinDBG - .loadsys command


The .loadsys command loads a file into WinDBG that extends it’s functions to include the commands lower down in this article.  Every useful thing that I’ve ever done with WinDBG required loading sos first.

Now to look at the memory heap, use the command:

!DumpHeap -stat

Output from the WinDBG !DumpHeap command

WinDBG - !DumpHeap


This command lists everything on the memory heap, organized by class.  In my particular case, I was looking for an object that was a class I had created, so I simply found the entry that was in the namespace of my process for that class.  There is a lot of good information in the -stat dump, but for the moment all I needed was the full name of the class so I could run the next command.

!DumpHeap -type System.Collections.Hashtable+bucket[]

Output from the WinDBG !DumpHeap -type command

WinDBG - !DumpHeap -type


When you run DumpHeap by type, it lists all instances of that type of object that are on the heap.  I was looking for a hashtable array that was particularly large, so I scanned the output of the type dump for anything big.(the last column is the object size)  Once I had found a suspect object, I wrote down the address (the first column) it was located at.  With the address I could now run a few more commands to inspect the object.

!DumpObj 0x00f991a8

(I combined the screenshots for !dumpobj and !objsize below)

I was looking at an array, so there were no fields to list out.  If I had been looking at a more standard class object, it would have listed all the instance variables for that class as fields.  One thing to watch out for is the size entry in the object dump.  If your object contains pointers, this size is the total of all the pointer sizes, not the size of the objects they point to.  In most cases you will want the size of the referred objects as well as the pointers themselves.  To get this size use the !objsize command.

!objsize 0x00f991a8

Output from the WinDBG !DumpObj and !ObjSize commands

WinDBG - !DumpObj and !ObjSize


More Reading

There are many more things you can do with WinDBG, I’ve only scratched the surface here.  you can find a list of common comands at the link below.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: