How to Diagnose Memory Issues with Diagnostic Hub & RevDeBug
Memory issues can often impact .NET applications running in production environments. Consequently, it can take longer to ship high-quality software through the application lifecycle because you have to spend more time fixing bugs and resolving memory problems.
Microsoft acknowledges these issues and have invested in tools in the Diagnostic Hub, including the Memory Usage Tool, which can be used alongside RevDeBug to fix memory issues faster.
When Microsoft first introduced this tool it only worked with the Ultimate version Visual Studio 2013, running .NET 4.5 or higher. At the time, this didn’t work with Premium or Professional versions. It should also be noted that the feature only works with .dmp files, providing the dump files were collected using an application created within .NET 4.5 (or higher). Before explaining how to solve these issues with the Memory Usage Tool, let’s review why these tend to cause problems in production environments.
What's the problem with Memory in .NET?
As a platform, .NET is generally effective at collecting garbage. Most of the time, the framework’s inbuilt garbage collector cleans up memory without end-users and developers even noticing. Unfortunately, as anyone who’s created applications using .NET knows, this doesn’t work all of the time. When it breaks, this can have a negative impact on hardware and software.
1. Memory Leaks. In a framework with a garbage collected runtime, developers shouldn’t need to free up memory space as they would in another production environment. However, the restriction is that the garbage collector only makes memory free when it determines that an object isn’t “reachable (referenced) by other objects that are still active in memory,” according to a Visual Studio blog on this subject.
Some of these attachments between objects could be bugs, since a reference that was retained in error will contribute to memory issues, causing the garbage collector to overlook something that needs clearing away. This will force the tool, inadvertently, to contribute to poor performance and more memory is used by unnecessary features.
2. Inefficient Memory. In these situations, there isn’t a leak, but an application is using far more memory than it should. One example would be a web application that is bringing back more results than needed from a database than it should need. RevDeBug can be used alongside the memory tool to determine the cause of the database issue, while the tool can pinpoint the “area” the problem occurs.
3. Allocation Failure. In .NET applications, allocation often happens quite fast, but this can cause problems later on. When memory gets allocated, it means the garbage collector has to operate more frequently, which can increase the costs quite quickly and knock the programs performance.
The consequences of memory leaks, insufficient memory or other issues include applications crashing due to an “Out of Memory” exception, poor performance, or other programs running slowly due to memory capacity issues.
Diagnose Memory Issues
Capturing the dump files to analyse potential memory issues is the first step. One way is to use third-party applications, such as ProcDump, “a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike.” Microsoft also has ways to capture memory issues within the Usage Tool, in the Diagnostic Hub.
Capturing memory spikes means running an application - in the production environment - so that you have files to analyse. There are several ways to do this using .NET.
Now you have this data you can use Visual Studio to analyse the dump files. See the image below for an idea what this should look like when the “Debug Managed Memory” feature is operating.
This should give you a clearer idea where the memory problem is located in the program. With this data at hand, you can bring RevDeBug into the investigation, which we talk about in more detail in this blog.
Find out more about the benefits of reverse debugging.Back to list