Export (0) Print
Expand All

Analyze .NET Framework memory issues

Visual Studio 2013

Find memory leaks and inefficient memory use in .NET Framework code by using the Visual Studio managed memory analyzer. The minimun .NET Framework version of the target code is .NET Framework 4.5.

The memory analysis tool analyzes information in dump files with heap data that a copy of the objects in an app's memory. You can collect dump (.dmp) files from the Visual Studio IDE or by using other system tools.

  • You can analyze a single snapshot to understand the relative impact of the object types on memory use, and to find code in your app that uses memory inefficiently.

  • You can also compare (diff) two snapshots of an app to find areas in your code that cause the memory use to increase over time.

For a walkthrough of the managed memory analyzer, see Using Visual Studio 2013 to Diagnose .NET Memory Issues in Production on the Visual Studio ALM + Team Foundation Server blog .

The .NET Framework is a garbage-collected runtime, so that in most apps, memory use is not a problem. But in long-running applications like web services and applications, and in devices that have a limited amount of memory, the accumulation of objects in memory can impact the performance of the app and the device that it runs on. Excessive memory use can starve the application and the machine of resources if the garbage collector is running too often, or if the operating system is forced to move memory between RAM and disk. In the worst case, an app can crash with an "Out of memory" exception.

The .NET managed heap is a region of virtual memory where reference objects created by an app are stored. The lifetime of objects are managed by the garbage collector (GC). The garbage collector uses references to keep track of objects that occupy blocks of memory. A reference is created when an object is created and assigned to a variable. A single object can have multiple references. For example, additional references to an object can be created by adding the object to a class, collection, or other data structure, or by assigning the object to a second variable. A less obvious way of creating a reference is by one object adding a handler to another object's event. In this case, the second object holds the reference to the first object until the handler is explicitly removed or the second object is destroyed.

For each application, the GC maintains a tree of references that tracks the objects referenced by the application. The reference tree has a set of roots, which includes global and static objects, as well as associated thread stacks and dynamically instantiated objects. An object is rooted if the object has at least one parent object that holds a reference to it. The GC can reclaim the memory of an object only when no other object or variable in the application has a reference to it.

Back to top Contents

The most visible symptom of memory issues is the performance of your app, especially if the performance degrades over time. Degradation of the performance of other apps while your app is running might also indicate a memory issue. If you suspect a memory issue, use a tool like Task Manager or Windows Performance Monitor to investigate further. For example, look for growth in the total size of memory that you cannot explain as a possible source of memory leaks:

Consistent memory growth in Resource Monitor

You might also notice memory spikes that are larger than your knowledge of the code would suggest, which might point to inefficient memory use in a procedure:

Memory spikes in Resource Manager

The memory analysis tool analyzes information in dump files that contain heap information. You can create dump files in Visual Studio, or you can use a tool like ProcDump from Windows Sysinternals. See What is a dump, and how do I create one? on the Visual Studio Debugger Team blog.

Note Note

Most tools can collect dump information with or without complete heap memory data. The Visual Studio memory analyzer requires full heap information.

To collect a dump from Visual Studio

  1. You can create a dump file for a process that was started from a Visual Studio project, or you can attach the debugger to a running process. See Attach to Running Processes with the Visual Studio Debugger.

  2. Stop execution. The debugger stops when you choose Break All on the Debug menu, or at an exception or at a breakpoint

  3. On the Debug menu, choose Save Dump As. In the Save Dump As dialog box, specify a location and make sure that Minidump with Heap (the default) is selected in the Save as type list.

To compare two memory snapshots

To analyze the growth in memory use of an app, collect two dump files from a single instance of the app.

Back to top Contents

Filter the list of objects | Analyze memory data in from a single snapshot | Compare two memory snapshots

To analyze a dump file for memory use issues:

  1. In Visual Studio, choose File, Open and specify the dump file.

  2. On the Minidump File Summary page, choose Debug Managed Memory.

    Dump file summary page

The memory analyzer starts a debug session to analyze the file and displays the results in the Heap View page:

Back to top Contents

By default, the memory analyzer filters the list of objects in a memory snapshot to show only the types and instances that are user code, and to show only those types whose total inclusive size exceed a threshold percentage of the total heap size. You can change these options in the View Settings list:

Enable Just My Code

Just My Code hides most common system objects, so that only the types that you create are displayed in the list.

You can also set the Just My Code option in the Visual Studio Options dialog box. On the Debug menu, choose Options and Settings. In the Debugging/General tab, choose or clear Just My Code.

Collapse Small Objects

Collapse Small Objects hides all types whose total inclusive size is less than 0.5 percent of the total heap size.

You can also filter the type list by entering a string in the Search box. The list displays only those types whose names contain the string.

Back to top Contents

Visual Studio starts a new debugging session to analyze the file.

Managed memory analysis heap view page

The top table lists the types of objects that are held in memory. You can expand a type name to view a sorted list of the ten instances of the type with the greatest size. By default, types and instances are sorted by Inclusive Size (Bytes). Choose a column header in the list to change the sort order.

Size (Bytes) is the size of the objects in memory, excluding the size of objects it holds references to. The Inclusive Size (Bytes) includes the sizes of referenced objects.

For a selected object type, the Paths to Root table shows the unique type hierarchies that lead to root objects for all objects of the type, along with the number of references to the type that is above it in the hierarchy. For an instance of the type, Paths to Root shows a graph of the actual objects that hold a reference to the instance.

For a selected object type node, the References tab shows the size and number of referenced types held by all objects of the selected type. For an instance of the type, References shows the instances of the referenced types that are held by the selected instance.

Circular references

An object can reference a second object that directly or indirectly holds a reference to the first object. When the memory analyzer encounters this situation, it stops expanding the reference path and adds a [Cycle Detected] annotation to the listing of the first object and stops.

Root types

The memory analyzer adds annotations to root objects that describe the kind of reference that is being held:

Annotation

Description

Static variable VariableName

A static variable. VariableName is the name of the variable.

Finalization Handle

A reference from the finalizer queue

Local Variable

A local variable.

Strong Handle

A handle to a strong reference from the object handle table.

Async. Pinned Handle

An asynchronous pinned object from the object handle table.

Dependent Handle

A dependent object from the object handle table.

Pinned Handle

A pinned strong reference from the object handle table.

RefCount Handle

A reference-counted object from the object handle table.

SizedRef Handle

A strong handle that keeps an approximate size of the collective closure of all objects and object roots at garbage collection time.

Pinned local variable

A pinned local variable.

Back to top Contents

You can compare two dump files of a process to find objects that might be the cause of memory leaks. The interval between the collection of the first (earlier) and second (later) file should be large enough that the growth of the number of leaked objects is easily apparent. To compare the two files:

  1. Open the second dump file, and then choose Debug Managed Memory on the Minidump File Summary page.

  2. On the memory analysis report page, open the Select baseline list, and then choose Browse to specify the first dump file.

The analyzer adds columns to the top pane of the report that display the difference between the Count, Size, and Inclusive Size of the types to those values in the earlier snapshot.

Diff columns in the type list

A Reference Count Diff column is also added to the Paths to Root table.

Back to top Contents

Show:
© 2014 Microsoft