Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The Memory Usage tool monitors your app's memory use. You can use the tool to study the real-time memory effects of scenarios you're actively developing in Visual Studio. You can take detailed snapshots of the app's memory states, and compare snapshots to find the root causes of memory issues. The Memory Usage tool is supported on .NET, ASP.NET, C++, or mixed mode (.NET and native) apps.
The Memory Usage tool can run on release or debug builds. In this article, we show how to use the Memory Usage tool in the Visual Studio Performance Profiler, which is recommended for release builds. For information on choosing the best memory analysis tool for your needs, see Choose a memory analysis tool.
For the best experience with this documentation, choose your preferred development language or runtime from the list at the top of the article.
Memory Usage diagnostic sessions
To start a Memory Usage diagnostic session:
Open a project in Visual Studio.
The Memory Usage tool supports .NET, ASP.NET, C++, or mixed mode (.NET and native) apps.
In the Debug menu, set the solution configuration to Release and select the deployment target.
On the menu bar, select Debug > Performance Profiler.
Under Available Tools, select Memory Usage, and then select Start.
![NOTE] For some project types, such as CMake, you must set the startup target to Executable. For more information, see Which tools are supported for my project?.
Monitor memory use
When you start a diagnostic session, your app starts, and the Diagnostic Tools window displays a timeline graph of your app's memory use.
The timeline graph shows memory fluctuations as the app runs. Spikes in the graph usually indicate that some code is collecting or creating data, and then discarding it when the processing is done. Large spikes indicate areas that you can optimize. Main concern is a rise in memory consumption that's not returned. This may indicate inefficient memory use or even a memory leak.
Take snapshots of app memory states
An app uses a large number of objects, and you might want to concentrate your analysis on one scenario. Or, you may find memory issues to investigate. You can take snapshots during a diagnostic session to capture memory usage at particular moments. It's good to get a baseline snapshot of an app before a memory issue appears. You can take another snapshot after the first occurrence of the problem, and additional snapshots if you can repeat the scenario.
To collect snapshots, select Take snapshot when you want to capture the memory data.
Close the diagnostic session
To stop a monitoring session without creating a report, just close the diagnostic window. To generate a report when you're done collecting or have taken snapshots, select Stop Collection.
If you have trouble collecting or displaying data, see Troubleshoot profiling errors and fix issues.
Memory Usage reports
After you stop data collection, the Memory Usage tool stops the app and displays the Memory Usage overview page.
Memory Usage snapshots
The numbers in the Snapshot panes show the objects and bytes in memory when each snapshot was taken, and the difference between the snapshot and the previous one.
The numbers are links that open detailed Memory Usage report views in new Visual Studio windows. A snapshot details report shows the types and instances in one snapshot. A snapshot difference (diff) report compares the types and instances in two snapshots.
Managed types reports
Choose the current link of an Objects (Diff) cell in the Memory Usage summary table.
Report tree filters
Many types in apps aren't required for app developers to investigate memory issues. The snapshot report filters can hide most of these types in the Managed Memory and Paths to Root trees.
To filter a tree by type name, enter the name in the Filter box. The filter isn't case-sensitive, and it recognizes the specified string in any part of the type name.
Select Show Just My Code in the Filter dropdown to hide most instances that are generated by external code. External types belong to the operating system or framework components, or are generated by the compiler.
Select Collapse Small Objects in the Filter dropdown to hide types whose Size (Bytes) is less than 0.5 percent of the total memory.
Native types reports
Choose the current link of an Allocations (Diff) or Heap Size (Diff) cell in the Memory Usage summary table of the Diagnostic Tools window.
The Types View displays the number and size of the types in the snapshot.
Change (Diff) reports
Choose the change link in a cell of the Snapshot pane in the Memory Usage overview page.
Choose a snapshot in the Compare To list of a managed or native report.
The change report adds columns (marked with (Diff)) to the base report that show the difference between the base snapshot value and the comparison snapshot. Here's how a Native Type View diff report might look:
The top pane shows the count and size of the types in the snapshot, including the size of all objects that are referenced by the type (Inclusive Size).