Visual Studio 2019 Preview 1 introduces an improved debugger for C++ that uses an external 64-bit process for hosting its memory-intensive components. If you’ve experienced memory-related issues while debugging C++ applications before, these issues should now be largely resolved with Visual Studio 2019.

Background

One of the areas of feedback for the debugger in Visual Studio has been around its high memory usage during debugging of large and complex C++ applications. Most of the memory consumption in this scenario is due to the large amounts of symbol information that the debugger needs to load to show program data in the debugger windows. Memory usage tends to increase over the course of a debugging session as the debugger stops in different parts of the application and encounters new symbols that need to be loaded. Eventually the Visual Studio process might crash due to running out of memory.

We’ve made significant optimizations in Visual Studio 2017 to mitigate this problem. For example, the 15.6 update introduced memory optimizations to /Debug:fastlink, which resulted in a 30% reduction in the debugger’s memory consumption. As we look to further avoid this issue in Visual Studio 2019, we have moved memory-intensive components to a separate 64-bit process.

Case study: Debugging Gears of War 4

We closely worked with internal and external partner teams to ensure the changes we were making to the debugger were validated on large native real-world applications. The following video shows a side-by-side comparison of the memory usage between Visual Studio 2017 and Visual Studio 2019 while debugging of Gears of War 4 developed by The Coalition. Visual Studio 2017 memory usage climbs up to 1.3 GB after a few minutes of stepping through the game code and inspecting variables. Visual Studio 2019 gives far better memory usage in the same scenario: its memory usage stays flat around 285 MB as the symbol data is kept in the debugger’s 64-bit worker process.

We’ve also tested the runtime performance and ensured there is no noticeable overhead due to calls between components that are now going over a process boundary.

Unsupported scenarios and known issues

Here are the unsupported scenarios and known issues with the updated debugger:

• The feature is not supported on 32-bit Windows.
• Symbols for C++/CLI modules are still being loaded in-process.
• Symbol data requested by the Disassembly Window will be loaded in-process. This will be fixed in Preview 2.
• Legacy C++ Expression Evaluator add-ins (here is an example) are not supported in this mode.
• Newer C++ EE add-ins (those written using the IDkmCustomVisualizer interface) will not work unless they are modified to support loading in the external process. If you own one of these extensions, more information can be found here.
• Finally, for compatibility, 3^rd party extensions can still request and get symbols in-process.

If you need to continue using the debugger in-process due to the known issues mentioned above, you can turn it off by going to the Debugging tab in Tools -> Options and unchecking the option “Load debug symbols in external process (native only)”.

Give us your feedback

Download Visual Studio 2019 Preview 1 today, and start using the improved debugger on your large native applications. If you run into any issues with it (e.g. stability, performance, incompatible extensions or EE add-ins) or if you have a suggestion for us, please let us know via the ‘Send Feedback’ button in the top right corner of Visual Studio or via Developer Community.