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 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.
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
Comments
Anonymous
April 22, 2009
PingBack from http://asp-net-hosting.simplynetdev.com/show-me-the-memory-tool-for-visualizing-virtual-memory-usage-and-gc-heap-usage/Anonymous
April 22, 2009
A colleague of mine, John Allen, created an awesome tool way back that displays memory usage in a processAnonymous
April 23, 2009
Coooooool. 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. http://www.saygoodnight.com/AvidMemSpyy.zipAnonymous
April 23, 2009
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 itAnonymous
April 23, 2009
Very cool Tess, Thanks for sharing.Anonymous
April 23, 2009
cool. What about putting it up on codeplex so people could contribute changes to it =)Anonymous
April 23, 2009
Thank you for submitting this cool story - Trackback from DotNetShoutoutAnonymous
April 23, 2009
I was thinking CodePlex is a good place for it as well.Anonymous
April 24, 2009
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 MSDNAnonymous
April 29, 2009
.NET C# COM Object for Use In JavaScript / HTML, Including Event Handling Show me the memory: Tool forAnonymous
April 29, 2009
.NETC#COMObjectforUseInJavaScript/HTML,IncludingEventHandlingShowmethememory...Anonymous
May 06, 2009
Thesearetwoawesometoolsthatcanvisualizevirtualmemory:Anonymous
June 01, 2009
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+?Anonymous
June 02, 2009
!eeheap works in 2.0, you just need to use the 2.0 version of sos.dllAnonymous
June 10, 2009
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?Anonymous
August 18, 2009
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.Anonymous
September 23, 2009
good info...for this you get the last two ...Anonymous
January 03, 2010
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: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.Anonymous
April 11, 2010
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...Anonymous
April 11, 2010
thanks for letting me know Thomas, I will try to get some time to fix a new one that works with that output...Anonymous
April 29, 2010
Looks cool! Added to my memory visualization links: http://www.dumpanalysis.org/blog/index.php/2010/04/29/memory-map-visualization-tools-revised/Anonymous
February 27, 2012
The comment has been removedAnonymous
April 01, 2012
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 :)Anonymous
November 27, 2012
Just open sources and change text parsing method. And it'll work. But latest windbg hides a lot of interesting under <unclassified> memory usage.Anonymous
April 29, 2013
how on earth is this thing working?!