Analyze memory usage of Store apps (VB, C#, C++)

In Visual Studio 2013 Update 2, you can use the Memory Usage tool in the Performance and Diagnostics hub to analyze the memory use of Windows Runtime apps written in C#, Visual Basic, or C++ and XAML. In particular, you can:

  • Monitor your app's memory use right in Visual Studio while you are developing a scenario. You don't have to use system and third-party tools.

  • Create detailed snapshots of the state of your app’s memory in a single click.

  • Compare snapshots to find the root cause of subtle or complex memory issues.

Note Note

This topic describes how use the Memory Usage tool to analyze C# and Visual Basic apps.

The Performance and Diagnostic hub offers you many options to run and manage a diagnostics session. For example, you can run the CPU Usage tool on Windows Phone apps or Windows Store apps, or run the diagnostic session on the Visual Studio computer, on a Windows Phone or a Windows Store device, or in one of the Visual Studio emulators or simulators. See Run analysis tools from the Performance and Diagnostic page.

If you want to analyze memory use in Windows Store apps that use JavaScript and HTML, see Analyze memory usage (JavaScript).

For more information about the Memory Usage tool, including how to analyze C++ and C++/Cx apps, see Diagnosing memory issues with the new Memory Usage Tool in Visual Studio on the Microsoft Application Lifecycle Management blog.

  1. Open your project in Visual Studio.

  2. On the menu bar, choose Debug, Performance and Diagnostics.

  3. On the Performance and Diagnostic hub page, select Memory Usage and then choose the Start button.

    Start a Memory Usage diagnostic session

You might be testing a native component along with the managed app that is the startup project. Or, perhaps the managed app is just a test harness and you’re only interested in the native memory. Or you might want to know the relationship between your managed app and the Windows Runtime. In situations like these, choose Settings and then select the language or languages to target.

Choose programming languages

Although you can use the Memory Usage tool to generate detailed reports that you can use to find and fix issues, you can also use it to study the real-time memory effects of a scenario you're actively developing.

When you start a diagnostic session, your app starts and the Performance and Diagnostics page displays a timeline graph of your app’s memory use.

Monitor memory use

As your app runs, you can try new functionality or study scenarios where you might have a problem. The Memory Usage timeline graph shows fluctuations in your app's memory as it runs.

Spikes in the graph usually indicate that a routine in the app is collecting or creating data and then discarding it when the processing is done. Large spikes indicate methods that you might be able to optimize. Of more concern is a rise in memory consumption that's not returned because it may indicate inefficient memory use or even a memory leak.

Stop collection

To stop a monitoring session without creating a report, just close the diagnostic window. To generate a report when you have taken memory snapshots, choose Stop.

If you discover a memory issue that you want to investigate, you can take snapshots during the diagnostic session to capture objects of memory at particular moments. Because an app uses a large number of many types of objects, you might want to concentrate your analysis on one scenario. It’s also a good idea to get a baseline snapshot of the app before a memory issue appears, another snapshot after the first occurrence of the problem, and one or more additional snapshots if you can repeat the scenario.

To collect snapshots, start a new diagnostic session. Choose Take Snapshot when you want to capture the memory data. To generate a report, choose Stop.

After you stop data collection, the Memory Usage tool stops the app and displays the overview report.

Memory Usage overview page

You use snapshot views to open detailed reports in new Visual Studio windows. There are two kinds of snapshot views:

Snapshot view links

The numbered items in the picture of the snapshot view are links that open Memory Usage report views.

Step 1

The link text shows the total number of bytes in memory when the snapshot was taken.

Choose this link to display a snapshot details report that's sorted by the total size of the type instances.

Step 2

The link text shows the total number of objects in memory when the snapshot was taken.

Choose this link to display a snapshot details report that's sorted by the count of instances of the types.

Step 3

The link text shows the difference between the total size of objects in memory at the moment of this snapshot and the total size of the previous snapshot.

The link text is a positive number when the memory size of this snapshot is larger than the previous one, and a negative number when the size is smaller. The link text Baseline indicates that this snapshot is the first in the diagnostic session; No Difference indicates that the difference is zero.

Choose this link to display a snapshot diff report that's sorted by the difference in the total size of instances of the types.

Step 4

The link text shows the difference between the total number of memory objects in this snapshot and the number of objects in the previous snapshot.

Choose this link to display a snapshot diff report that's sorted by the difference in the total count of instances of the types.

Memory Usage snapshot report

The managed heap tree Managed Heap tree (Snapshot details) and the Managed Heap tree (Snapshot diff) show the types and instances in the report. Selecting a type or instance displays the Paths to Root and Referenced Objects trees for the selected item.

The Paths to Root tree (Snapshot details) and the Paths to Root tree (Snapshot diff) show the chain of objects that reference the type or instance. The .NET Framework garbage collector cleans up the memory for an object only when all references to it have been released.

The Referenced Objects tree (Snapshot details) and the Referenced Objects tree (Snapshot diff) show the objects that the selected type or instance references.

When an Object Type entry has child entries, you can choose the arrow icon to display them. If the color of the Object Type text is blue, you can choose it to navigate to the object in its source code file. The source file is opened in a separate window.

Instance names are unique IDs that are generated by the Memory Usage tool.

Tip Tip

If you notice a type that you can’t easily identify or if you don’t know how it’s involved in your code, don’t worry about it. It's probably an object from the Framework, operating system, or compiler that the Memory Usage tool displays because it's involved in the ownership chains of your objects.

Most apps contain a surprisingly large number of types, most of which are not very interesting to the app developer. The Memory Usage tool defines two filters that you can use to hide most of these types in the Managed Heap and Paths to Root trees. You can also filter a tree by type name.

Sort and filter options

Enter a string in the Filter box to restrict the tree displays to types that contain the specified text. The filter is not case-sensitive, and it recognizes the specified string in any part of the type names.

When this filter is applied, types whose Size (Bytes) is less than 0.5 percent of the total size of the snapshot memory are hidden in the Managed Heap list.

The Just My Code filter hides most instances that are generated by external code. External types are owned by the operating system or by Framework components, or are generated by the compiler.

You use a snapshot details report to focus on one snapshot from a diagnostic session. To open a details report, choose one of the links in a snapshot view, as shown in the following picture. Both links open the same report; the only difference is the starting sort order of the Managed Heap tree in the report. In both cases, you can change the sort order after the report opens.

Links to snapshot report in a snapshot view
  • The MB link sorts the report by the Inclusive Size (Bytes) column.

  • The objects link sorts the report by the Count column.

The Managed Heap tree lists the types of objects that are held in memory. You can expand a type name to view the ten largest instances of the type, sorted by size. Selecting a type or instance displays the Paths to Root and Referenced Objects trees for the selected item.

Managed Heap tree

Object Type

The name of the type or object instance.

Count

The number of object instances of the type. The number is always 1 for an instance.

Size (Bytes)

For a type, the size of all instances of the type in the memory snapshot, excluding the size of objects contained in the instances.

For an instance, type, the size of the object excluding the size of objects contained in the instance. instances.

Inclusive Size (Bytes)

The size of the instances of the type or the size of a single instance, including the size of contained objects.

The Paths to Root tree shows the chain of objects that reference the type or instance. The .NET Framework garbage collector cleans up the memory for an object only when all references to it have been released.

Paths to Root tree for Types

When you view a type in the Paths to Root tree, the number of objects of the types that hold references to that type is displayed in the Reference Count column. The column does not appear when you analyze an instance.

The Referenced Objects tree shows the objects that the selected type or instance references.

Referenced Objjects tree for instances

Object Type / Instance

The name of the type or object instance.

Size (Bytes)

For a type, the size of all instances of the type, excluding the size of objects contained in the type.

For an instance, the size of the object, excluding the size of objects contained in the object.

Inclusive Size (Bytes)

The total size of the instances of the type or the size of the instance, including the size of contained objects.

A snapshot difference (diff) report shows the changes between a primary snapshot and the snapshot that was taken immediately before it. To open a diff report, choose one of the links in a snapshot view, as shown in the following picture. Both links open the same report; the only difference is the starting sort order of the Managed Heap tree in the report. You can change the sort order after the report opens.

Links to difference report in a snapshot view
  • The MB link sorts the report by the Inclusive Size (Bytes) column.

  • The objects link sorts the report by the Count column.

The Managed Heap tree lists the types of objects that are held in memory. You can expand a type name to view the ten largest instances of the type, sorted by size. Selecting a type or instance displays the Paths to Root and Referenced Objects trees for the selected item.

Managed Heap tree for a type in difference report

Notice that the Count, Size (Bytes), and Inclusive Size (Bytes) columns have been collapsed in the picture.

Object Type

The name of the type or object instance.

Count

The number of instances of a type in the primary snapshot. Count is always 1 for an instance.

Count Diff

For a type, the difference in the number of instances of the type between the primary snapshot and the previous snapshot. The field is blank for an instance.

Size (Bytes)

The size of the objects in the primary snapshot, excluding the size of objects contained in the objects. For a type, Size (Bytes) and Inclusive Size (Bytes) are the totals of the sizes of the type instances.

Total Size Diff (Bytes)

For a type, the difference in the total size of instances of the type between the primary snapshot and the previous snapshot, excluding the size of objects contained in the instances. The field is blank for an instance.

Inclusive Size (Bytes)

The size of the objects in the primary snapshot, including the size of objects contained in the objects.

Inclusive Size Diff (Bytes)

For a type, the difference in the size of all instances of the type between the primary snapshot and the previous snapshot, including the size of objects contained in the objects. The field is blank for an instance.

The Paths to Root tree shows the chain of objects that reference the type or instance. The .NET Framework garbage collector cleans up the memory for an object only when all references to it have been released.

Paths To Root tree for instances in a diff view

The Referenced Objects tree shows the objects that the primary type or instance references.

Referenced Objjects tree for instances

Object Type / Instance

The name of the type or object instance.

Size (Bytes)

For an instance, the size of the object in the primary snapshot, excluding the size of objects contained in the instance.

For a type, the total size of the instances of the type in the primary snapshot, excluding the size of objects contained in the instance.

Inclusive Size (Bytes)

The size of the objects in the primary snapshot, including the size of objects contained in the objects.

Show:
© 2014 Microsoft