Show me the memory: Tool for visualizing virtual memory usage and GC heap usage.

A colleague of mine, John Allen, created an awesome tool way back that displays memory usage in a process very nicely.  I use screenshots from it from time to time in presentations or posts but unfortunately that tool is not publicly available.

Since lots of people have asked me about it I figured I would just do a quick and dirty mock-up (based on the same ideas) and post the VS solution here.

This sample tool will give you a visual overview of the virtual memory space (from a memory dump), show you where your allocations exist and what types of allocations you have.   For example in the screenshot below you can see that at the beginning of the memory space we have a lot of virtual allocations (dark green – committed, light green - reserved), then we have a lot of free space (white) and towards the end of the memory space we can see our dlls scattered out (dark red).

In the bottom screen we can see our GC (.NET) Heaps.  In other words, most of the virtual allocations we see in the top screen are really GC Heaps. One little caveat is that for the GC heaps it doesn’t show what is reserved for the GC heaps, only what is committed, i.e. what we actually use.

I have separated them out so that you can use the tool for apps as well if you want to.

The purpose of looking at something like this is to get a grasp for how much fragmentation we have, how much reserved vs. committed memory we have etc.  and if we do have a lot of fragmentation, where should we start looking in order to reduce it.


The original tool is a bit more complex as it can read in memory dumps etc. and lets you zoom into different areas to get more details but for the most part what you see above is enough.

   The sample tool posted here is almost completely void of error handling, and does a lot of output parsing so just be aware that it is by
   no means claiming to be robust…   I just wanted to get it out there so you have the functionality

To use the sample tool follow these steps:

1. Open the memory dump in windbg and set the symbols properly

.symfix c:\mycache

2. Run !address and copy the output to a text file.

3. Load sos

.loadby sos mscorwks

4. Run !eeheap –gc and copy the output to another text file

5. Open the tool, click on Load !address and load the !address output,  click on Load !eeheap –gc and load the !eeheap –gc output

Suggestions for features you might want to implement:

There is a lot of info stored in just these two files, including how much memory the process is using, how much is reserved and committed etc.  as well as sizes of GC heaps, number of GC heaps and so on.   

I didn’t have time to add all this but it would probably be nice to show it, as well as automatically gathering the info from a dump, or even doing the right-click on a memory area for more info + zoom in.

Feel free to build on it, and if you do and post it somewhere, please add a comment with a link to your version and share the wealth:)

Have fun,

Comments (25)
  1. What's New says:

    A colleague of mine, John Allen, created an awesome tool way back that displays memory usage in a process

  2. PJ Gray says:


    I wrote a similar tool, but rather than using output from windbg, I gather as much information as I can from the process live, based on procID.   Obviously, this is a different situation, but I feel like it might be useful for people diagnosing issues with virtual address space.

    I originally wrote it cause we were having severe fragmentation issues, and I wanted to visually see how our DLLs and whatnot were laid out in address space.

    Holding Left-button pans around, and holding right-button zooms in.  Hope its helpful.

  3. Tess says:

    Very nice PJ…

    For some reason it started going into an infinite loop in the opengl libraries the 2nd time i used it, im guessing it will probably work again if i reboot.   But i got a chance to try it once and really liked it

  4. James Alexander says:

    Very cool Tess, Thanks for sharing.

  5. jcopenha says:

    cool.  What about putting it up on codeplex so people could contribute changes to it =)

  6. Thank you for submitting this cool story – Trackback from DotNetShoutout

  7. David Smith says:

    I was thinking CodePlex is a good place for it as well.

  8. My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. US ISV Developer Evangelism Team posted some links to money saving offers for ISVs when purchasing or upgrading Visual Studio or MSDN

  9. gOODiDEA.NET says:

    .NET C# COM Object for Use In JavaScript / HTML, Including Event Handling Show me the memory: Tool for

  10. gOODiDEA says:


  11. Warren Tang says:


  12. daveblack says:

    Hi Tess,

    Great tool!

    Alas, !eeheap gives an error message of "Doesn’t work with 2.x" in the latest version of WinDbg (6.11.0001.404)

    When will these commands work with .NET 2.0+?

  13. Tess says:

    !eeheap works in 2.0, you just need to use the 2.0 version of sos.dll

  14. Eric says:

    Hey Tess,

    Just found this little jewel and we have found some use for it. I do have a question though, the Heap Allocs, are these unmanaged allocs?

  15. Ling says:

    cool, it helps a lot.

    This tool can be updated to show the statistic data about complicated query for memory usage and state, for example, list the size about RegionUsageHeap|MEM_RESERVE. However, !address command doesnot support it.

  16. pete says:

    good info…for this you get the last two …

  17. Very cool tool!

    You could make things even easier by making a script out of it. For example:


    .logopen C:addresses.txt



    .logopen C:eeheap.txt

    !eeheap –gc


    In WinDBG you can simply type $<C:PathToScript.txt

    All that you then need do is to update it to handle the "Opened log file", "Closed log file" and command lines.

    If you combine that with your "Associate With WinDBG" post you can also write a script that will do everything.

  18. Thomas says:

    It seems that the output format of !address in the latest version of WinDbg (I use 6.12.0002.633 X86) is no longer compatible with the tool. It worked fine before…

  19. Tess says:

    thanks for letting me know Thomas,  I will try to get some time to fix a new one that works with that output…

  20. j. appleby says:

    way over my head.

  21. Hi Tess,

    is there some other alternative for this utility? It doesn't work with latest windbg output, sure I can correct it, just I'm curious maybe there's something inside by default.

    Would be great to have some export to VMMap utility 🙂

  22. Just open sources and change text parsing method. And it'll work.

    But latest windbg hides a lot of interesting under <unclassified> memory usage.

  23. steve says:

    how on earth is this thing working?!

Comments are closed.

Skip to main content