.NET Memory Dump Analysis in Visual Studio 2013

By | 2013-11-14T09:54:51+00:00 November 14th, 2013|Application Lifecycle Management (ALM)|0 Comments

There are only a few things that are stressful on a workday:  angry drivers, accidentally closing documents, and computers freezing. 

A few possible causes of poor performance with applications on a machine:

  • Inefficiencies – Especially pertaining to memory use. Example: An application calling a function too many times, duplicate code.
  • Memory leaks – Objects designed to be temporary but kept permanently because of unreachable code. Or in the instance of physical resource leaks, if a file is kept open without being used and consuming memory.
  • Unnecessary allocations – Self-explanatory, but if the garbage collector is called too many times for particular CPU-intensive applications, well, you can take a guess at what happens.

When any of these three grace your applications, you can get an “Out of Memory” exception (my personal favorite with C/C++ programming), poor application performance, or even an entire machine with poor performance. Users are becoming more impatient and expecting of fast applications, so how do we fix this?

Memory Dump Analyzer in Visual Studio 2013 is the solution to your computer troubles. Using this tool, you can create a dump (.dmp) of the data, analyze it, and bring back the intended efficiency. And all of this is in Visual Studio, no extra software to download. Similar to a tool like Code Clone Analysis, you can dive right into your code at whatever magnification necessary to find those nagging memory leaks. You can see the size and counts of memory usage, largest instances of objects, and what holds them alive in memory. Even more insightful, you can compare two memory dumps to check how the memory usage changes over time.

A complete walkthrough of an example program using the Memory Dump Analyzer (first link is RC overview, second is RTM enhancements) is at “Using Visual Studio 2013 to Diagnose Net Memory Issues in Production” and “Net Memory Analysis Enhancements in Visual Studio 2013.”

The one caveat is that you need an Ultimate copy to debug, as well as .NET 4.5 framework or higher.

So how does this help increase value? First and foremost, users have a certain threshold of expectations from software performance: if you’re below the line, you’re not going to make it. If memory leak issues are resolved, that will create happy customers with positive feedback, and in turn a happy team. If you especially check for memory leaks early on in the development process and continuously, this can be a major contribution to your project’s success. And again, no one enjoys sitting there while their computer jitters and freezes.

Here’s a story: I was testing out a piece of software that was getting close to the wire on release. The primary concern? Performance. There were worries primarily centered around why the application was taking 45 minutes to perform when it was supposed to finish within minutes. It frustrated the testers (or you can consider us the part of the future users), and to me at least, the development team lost some credibility when they said it was a unique case and the performance issues weren’t solved in the following release. If they had access to the Memory Dump Analysis, they would have reduced the amount of time for looking for performance issues and perhaps even have been successful at finding them to deliver high-quality releases.

Memory Dump Analyzer in Visual Studio 2013 can’t guarantee that it will help you solve all of your performance problems all the time, but it gets you pretty darn close.


Sources and Further Reading:





About the Author:

Leave A Comment