If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

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

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

Rate This
  • Comments 25

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 non-.net 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.

image

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.

<disclaimer> 
   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
</disclaimer>

To use the sample tool follow these steps:

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

.symfix c:\mycache
.reload

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,
Tess

Attachment: MemoryDisplay32Bit.zip
  • 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.

  • good info...for this you get the last two ...

  • Very cool tool!

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

    .reload

    .logopen C:\addresses.txt

    !address

    .logclose

    .logopen C:\eeheap.txt

    !eeheap –gc

    .logclose

    In WinDBG you can simply type $<C:\Path\To\Script.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.

  • 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...

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

  • Looks cool! Added to my memory visualization links:

    http://www.dumpanalysis.org/blog/index.php/2010/04/29/memory-map-visualization-tools-revised/

  • way over my head.

  • 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 :)

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

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

  • how on earth is this thing working?!

Page 2 of 2 (25 items) 12
Leave a Comment
  • Please add 7 and 6 and type the answer here:
  • Post