It’s always fun to add a new blog tag – VS2013. In today’s post I’d like to tell you about the Heap View feature (a.k.a. “Debug Managed Memory”) that you can use to analyze dump files in Visual Studio 2013, announced at Build last week. Although this feature is far from baked and would likely only be useful for simple investigations, I welcome any improvements to the diagnostic tooling built into Visual Studio and look forward to the day I can solve most bugs without leaving the IDE.
Essentially, Heap View is a simple explorer for your application’s most heavy memory consumers and their references. As with every memory investigation, you must first determine which objects are consuming lots of memory, and which objects are growing over time. Then you can start looking at reference chains holding these particular objects alive, and even drill down into specific object instances to see more detailed information on an instance level. Visual Studio 2013 lets you do just that, albeit in a somewhat rudimentary way compared to a real memory profiler like .NET Memory Profiler or ANTS Memory Profiler.
In the following screenshot, you can see the new “Debug Managed Heap” option in the dump file summary in Visual Studio 2013.
When you click it, you are taken to a view that lets you select a baseline (another dump file) to compare with, and generates a diff that shows which objects are growing in memory.
Now, you can click a type that looks suspicious to you, and review the reference chains in the bottom pane. Specifically, you can see that >29MB of strings are being retained by references from String objects andFileInformation objects. Unfortunately, the breakdown, again, is fairly rudimentary – you don’t see the retained size for each type of reference, so it’s quite hard to explore this information on a detailed level. Still, if you expand the entire chain, you get this:
Now it’s pretty evident that we have an EventHandler holding down a bunch of memory, but what is referencing this EventHandler? “System.Object [Pinned Handle]” is not very useful, and you are supposed to know that this is how the CLR keeps references to static objects – through a single global pinned array. The name of that static variable? Go fish :)
In summary, Visual Studio 2013 has some nice facilities for displaying heap information and analyzing object reference chains, but it’s still very far from being a threat to commercial profilers in this field. It’s always great to see innovation in the diagnostics area, and I look forward to more features like this. In the meantime, WinDbg and SOS – my trusty friends – are not going anywhere.