{"id":123,"date":"2014-11-21T11:19:00","date_gmt":"2014-11-21T11:19:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2014\/11\/21\/native-memory-diagnostics-in-vs2015-preview\/"},"modified":"2021-09-27T17:12:53","modified_gmt":"2021-09-27T17:12:53","slug":"native-memory-diagnostics-in-vs2015-preview","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/native-memory-diagnostics-in-vs2015-preview\/","title":{"rendered":"Native Memory Diagnostics in VS2015 Preview"},"content":{"rendered":"

In Visual Studio 2013 Update 2 and also in the earlier CTP releases of Visual Studio 2015, we <\/span>released a memory diagnostic tool<\/a> that allowed developers to take heap snapshots of their application and then examine the heap contents upon terminating their application.\u00a0 The initial release supported viewing managed and native objects in the heap, and an <\/span>update in the first Visual Studio 2015 CTP<\/a> added support for native type derivation and value inspection.\u00a0<\/span><\/p>\n

\"Image<\/a><\/p>\n

While this tool was a good start in providing Visual Studio developers with an in-box memory profiler, it lacked the ability to easily examine heap contents at a specific program state since the entire program had to be shut down in order to drill deeper into the data.<\/p>\n

 <\/p>\n

Improved Memory Profiler for Preview<\/h2>\n

Now there is a new and improved memory profiler available in Preview that allows developers to leverage the debugger\u2019s powerful control of program flow and examine their app\u2019s heap contents at any break state.\u00a0 Here is a great overview of the new memory profiling experience<\/a> with an in-depth feature summary complete instructions on activating the feature<\/a> (Where do I find it?<\/em> section).\u00a0 Upon following these instructions to activate the tool for the first time, simply pressing F5 will launch the new profiler during the debug session.\u00a0 There is now no longer a need to terminate the app to view the heap snapshots!<\/p>\n

\"Image<\/a><\/p>\n

The rest of this post will focus primarily on using the new tool with native applications and details the specifics of the tool\u2019s workflow.<\/p>\n

Walkthrough: Profiling a Native MFC App<\/h2>\n

To show off the new memory profiler, an MFC open-source chip-tune sequencer called FamiTracker<\/a> has been loaded into Visual Studio and modified slightly to build with the new compiler.\u00a0 After enabling the memory profiler via the reg key and starting a debug session on the app with F5, the tool loads and soon the live memory usage is shown and the heap snapshot reel appears below it:<\/p>\n

\"Image<\/a><\/p>\n

Snapshots can be taken at different points in time to capture the heap state.\u00a0 Instance values are only viewable for the most recent shot and when in a break state.<\/span>\u00a0\u00a0<\/span><\/p>\n

In this walkthrough, the initial program state for FamiTracker is the initialized sequencer UI:<\/p>\n

\"Image<\/a><\/p>\n

\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0FamiTracker Initial Sequencer UI<\/em><\/p>\n

\u00a0<\/em><\/p>\n

Another dialog called the instrument editor can be launched to edit the properties of each instrument:<\/p>\n

\"Image<\/a><\/p>\n

\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/em>\u00a0 \u00a0 \u00a0 \u00a0FamiTracker Instrument Editor Dialog<\/em><\/p>\n

\u00a0<\/em><\/p>\n

Using the new memory profiler, we will take heap snapshots across these two program states to better understand the runtime memory consumption of this app.<\/p>\n

First we take a baseline snapshot to store the initial heap contents.\u00a0<\/span><\/p>\n

\"Image<\/a><\/p>\n

The instrument editor dialog is opened, which triggers a breakpoint in the code and begins a change in program state. \u00a0This function initializes the instrument editor dialog and calls a few other helper functions that will help create the instrument editor UI.<\/p>\n

\"Image<\/a><\/p>\n

By taking a snapshot at the breakpoint above at the beginning of OnInitDialog()<\/em>, we can see the heap contents of the app just before the instrument editor dialog starts allocating objects.\u00a0 A snapshot will list the object types, counts, and memory footprint.<\/p>\n

\"Image<\/a><\/p>\n

Since we are at in a break state, the instance of each type can be viewed by double-clicking a row, or the \"Image<\/a>\u00a0 icon:<\/p>\n

\"Image<\/a><\/p>\n

Selecting a type will present a list of all of the allocations of that type, complete with values and allocation call stacks for each instance.\u00a0 Below are all of the instances of CCHannelHandlerN163[]<\/em>:<\/p>\n

\"Image<\/a><\/p>\n

 <\/p>\n

After continuing through some breakpoints, the instrument editor dialog finally pops up and a second snapshot is taken.\u00a0 Upon taking a second snapshot, we can see the total amount of memory consumed during the entire invocation of the instrument dialog, in this case a little over 50 KB.<\/p>\n

\"Image<\/a><\/p>\n

\"Image<\/a><\/p>\n

The +51,227 bytes and +405 allocations reveal the total additional memory consumed by launching the instrument editor dialog relative to the baseline snapshot #1, and the top two numbers reveal the total heap contents.\u00a0 Clicking either of these will launch the diff snapshot and list count and type of the additional objects that have exist since the previous snapshot.\u00a0 To see all object in the heap snapshot, simply click one of the two top details in the snapshot that tells the total consumption.\u00a0 Shown below is the second snapshot diffed to the first:<\/p>\n

\"Image<\/a><\/p>\n

We can even examine the memory overhead more precisely by putting breakpoints at the beginning and the end of a particular function, and taking two snapshots for comparison.\u00a0 The InsertPane<\/em> function is called twice during the instrument dialog invocation, so it would be nice to see the specific impact it has on the overall execution.\u00a0 Two breakpoints have been set to encapsulate the InsertPane<\/em> function, and a snapshot is taken at each break.\u00a0 In the snapshot details of the second snapshot below, we are able to clearly see that this function is consuming about 12 KB within its 20 lines of code.<\/p>\n

\"Image<\/a><\/p>\n

The snapshot diff technique allows any region of your code to be analyzed for memory footprint and provides a powerful tool for exposing memory leaks that may occur between states of execution.\u00a0 Once two snapshots are taken, the latest snapshot will automatically show the diff to the previous one.\u00a0 To diff non-sequential snapshots, simply click the top right corner of a snapshot and select a snapshot to diff against.<\/p>\n

\"Image<\/a><\/p>\n

This can also be done by clicking the Compare to<\/em> combo-box at the top right of an opened snapshot select the desired snapshot.<\/p>\n

\"Image<\/a><\/p>\n

 <\/p>\n

“Hide Undetermined Types” View Setting<\/h2>\n

Due to the nature\u00a0of the tool\u2019s type derivation from PDBs, some types cannot be determined due to lack of symbols, or due to the use of custom allocators. We plan to expose the extensibility model for custom allocators in a future blog post. Since it is important to not hinder the workflow for examining user defined types with available symbols, we have chosen to hide these object by default.\u00a0<\/span><\/p>\n

These undetermined objects can easily be seen by selecting the View Settings pull-down at the top of the heap view and unchecking the option.<\/span><\/p>\n

\"Image<\/a><\/pre>\n
This will list the \u201cUndetermined\u201d type entry in the heap table and in turn will reveal all the instances in memory, complete with the allocation call stack.\u00a0 Below, the object instance at address <0x1E1148> is shown:<\/p>\n
\"Image<\/a><\/pre>\n
In the case that there are not any determined types and the default hide setting is enabled, the heap table will show a watermark with the following string:<\/p>\n
\"Image<\/a><\/p>\n
Known Issues<\/h2>\n
As mentioned in Charles\u2019s blog post<\/a>, the currently supported native application types are Win32, MFC and Windows Store apps. All C++ projects must be built with the new Visual Studio 2015 (v140) compiler to work properly with this tool. The following scenarios are not supported:<\/p>\n