- \n
- Breakpoints and control flow<\/a><\/li>\n
- Data inspection and visualization<\/a><\/li>\n
- Diagnostic tools and performance profiling<\/a><\/li>\n
- Debugging processes and devices<\/a><\/li>\n
- Multi-threaded debugging<\/a><\/li>\n
- Edit and continue<\/a><\/li>\n
- Other resources<\/a><\/li>\n<\/ul>\n
Breakpoints and control flow<\/h2>\n
After you have built your application in Visual Studio, you can start the debugger simply by pressing F5.\u00a0 When you start debugging, there are several commands that can help you to navigate the breakpoints in your application so that you can control the state of the program and the current context of the debugger.\u00a0 These commands give you flexible control over the debugger\u2019s scope and what lines and functions of code you want to investigate.<\/p>\n
- \n
- Continue with [F5]: <\/strong>Run to the next break point.<\/li>\n
- Step over [F10]: <\/strong>Run the next line of code and then break.<\/li>\n
- Step into [F11]: <\/strong>Step into the function called on the current line of code.<\/li>\n
- Step out [Shift+F11]: <\/strong>Step out of the current function and break at the next executable line after the function call.<\/li>\n<\/ul>\n
When hovering over a breakpoint in your code, you will see two icons appear.\u00a0 The icon on the right with two circles allows you to quickly toggle the current breakpoint on or off without losing the breakpoint marker at this line of code:<\/p>\n
![\"breakpoint\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/breakpoint.png\")
<\/a><\/p>\nThe icon on the left will launch the list of breakpoint options. Here you can add conditions or actions to a breakpoint.<\/p>\n
![\"bpmenu\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/bpmenu.png\")
<\/p>\nSometimes you want a breakpoint to be hit only when a certain condition is satisfied, like x<=5 is true where x is a variable in the debugger scope.\u00a0 Conditional breakpoints<\/strong> can easily be set in Visual Studio using the inline breakpoint settings window, which allows you to conveniently add conditional breakpoints to your code directly in the source viewer without requiring a modal window.\u00a0 Notice that conditional breakpoints contain a “+” sign to indicate at least one condition has been added to the breakpoint.<\/p>\n
![\"inlinebp\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/inlinebp.png\")
<\/a><\/p>\nThere is also a set of breakpoint actions <\/strong>that can be performed at a breakpoint, like printing the process ID or the call stack. Visual Studio also refers to these as breakpoint actions as “tracepoints”.\u00a0 The inline breakpoint settings window allows you to set a variety of breakpoint actions such as printing the call stack or PID.\u00a0 Notice that when at least one action is assigned to a breakpoint, the breakpoint appears as a diamond shape.\u00a0 In the example below, we have added both a condition and an action to the breakpoint; this makes it appear as a diamond with a “+” sign inside.<\/p>\n
![\"inlinebp2\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/inlinebp2.png\")
<\/p>\nFunction breakpoints (watch points)<\/strong> will activate when a specified function is encountered by the debugger.\u00a0 Use the Debug<\/strong> menu and select New breakpoint<\/strong> to add a function breakpoint.<\/p>\n
![\"functionbp\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/functionbp.png\")
<\/p>\nData breakpoints <\/strong>will stop the debugger when a specific address is hit during debugging.\u00a0 Use the Debug<\/strong> menu and select New breakpoint<\/strong> to add a function breakpoint.<\/p>\n
Data inspection and visualization<\/h2>\n
When you are stopped at a breakpoint, the debugger has access to the variable names and values that are currently stored in memory. <\/strong>\u00a0There are several windows that allow you to view the contents of these objects.<\/p>\n
- \n
- Locals<\/strong>: The locals window lists all variables currently within the debugger scope, which typically includes all static and dynamic allocations made so far in the current function.<\/li>\n
- Autos: <\/strong>This window provides a list of the variables in memory that originate from:\n
- \n
- The current line at which the breakpoint is set.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- \n
- Note that in the example below, line 79 has yet to execute. The variable is not yet initialized and there is no value for the Autos window to display.<\/li>\n<\/ul>\n<\/ul>\n<\/ul>\n
- \n
- The previous 3 lines of code. As you can see below, when we are at the breakpoint on line 79, the previous three lines are shown, and the current line awaiting execution has been detected, but the value is not yet available until this line executes.<\/li>\n<\/ul>\n
![\"code1\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/code1.png\")
<\/a><\/p>\n![\"autos\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/autos.png\")
<\/p>\n- \n
- Watch: <\/strong>These windows allows you to track variables of interest as you debug your application. Values are only available when the listed variables are in the scope of the debugger.<\/li>\n
- Quick Watch<\/strong> is designed for viewing the variable contents without storing it in the Watch window for later viewing. Since the dialog is modal, it is not the best choice for tracking a variable over the entire debugging session: for cases like this the Watch window is preferable.<\/li>\n<\/ul>\n
![\"quickwatch\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/quickwatch.png\")
<\/p>\n- \n
- Memory windows: <\/strong>These provide a more direct view of system memory and are not restricted to what is currently shown in the debugger. They provide the ability to arrange values by bit count, for example 16, 32, and 64. This window is intended primarily for viewing raw unformatted memory contents. Viewing custom data types is not supported here.<\/li>\n<\/ul>\n
![\"memorywindow\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/memorywindow.png\")
<\/a><\/p>\nCustom Views of Memory<\/strong><\/p>\n
Visual Studio provides the Natvis framework, which enables you to customize the way in which non-primitive native data types are displayed in the variable windows (Locals, Autos, Watches).\u00a0 We ship Natvis visualizers for our libraries, including the Visual C++ STL, ATL, and MFC.\u00a0 It is also easy to create your own Natvis visualizer to customize the way a variable\u2019s contents are displayed in the debugger windows mentioned above.<\/p>\n
Creating a Natvis File<\/strong><\/p>\n
You can add natvis files to a project or as a top-level solution item for .exe projects.\u00a0 The debugger consumes natvis files that are in a project\/solution.\u00a0 We provide a built-in template under Visual C++ –><\/em>\u00a0Utility<\/em> folder for creating a .natvis file.<\/p>\n
![\"newnatvis\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/newnatvis.png\")
<\/a><\/p>\nThis will add the visualizer to your project for easier tracking and storage via source control.<\/p>\n
![\"solnexp\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/solnexp.png\")
<\/a><\/p>\nFor more information on how to write .natvis visualizers, consult the Natvis documentation<\/a><\/a>.<\/p>\n
Modifying Natvis Visualizers While Debugging<\/strong><\/p>\n
The following animation shows how editing a natvis for the Volcano<\/em> type will change the debugger display \u00a0inthe variable windows.\u00a0 The top-level display string for the object is changed the to show the m_nativeName<\/em> instead of the m_EnglishName<\/em>.\u00a0 Notice how the changes to the .natvis file are immediately picked up by the debugger and the difference is shown in\u00a0red\u00a0text.\u00a0
![\"natvisedit\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/natvisedit.gif\")
<\/a><\/p>\nDiagnostic tools and performance profiling<\/h2>\n
Most profiling tools run in a special mode that is separate from the debugger itself.\u00a0 In Visual Studio, we have added a set of performance and diagnostics tools that can run during <\/em>debugging and provide more insight into the performance and state of your apps. You can control the flow of the application to get to a problem area and then activate more powerful tools as you drill down into the problem. \u00a0Instead of waiting around for the problem to happen, you are able to have full control of the program and decide what information you want to analyze, whether it\u2019s how much time a function spends on the CPU, or viewing the memory usage of each allocation by type. The live CPU and memory usage of your application are displayed in the graph and debugger event are indicated along the timeline. There is a tab for using each of the included diagnostic tools: CPU Usage and Memory Usage.<\/p>\n
![\"dtwindow\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/dtwindow.png\")
<\/p>\nCPU Usage<\/strong><\/p>\n
This tool allows you to view the CPU usage for each function called in a selected time range on the CPU graph.\u00a0 You must enable the tools by clicking the “CPU Profiling” button on the left of this tab in order to select a time range for analysis.<\/p>\n
![\"cpuusage\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/cpuusage.png\")
<\/p>\nMemory Usage<\/strong><\/p>\n
This tool enables you to use the memory profiler, which for native profiling must be enabled using the Heap Profiling<\/strong> button so that you can capture heap snapshots.\u00a0 The button on the left takes a snapshot and you can view the contents of each snapshot by clicking the blue links in the snapshot table.<\/p>\n
![\"snapshotreel\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/snapshotreel.png\")
<\/p>\nThe Types View <\/strong>shows the types that were resolved from the memory snapshot including the count and total memory footprint.\u00a0 You can navigate to the Instances View<\/strong> by double-clicking a line in this view.<\/p>\n
![\"typesview\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/typesview-1024x298.png\")
<\/p>\nThe Instances View <\/strong>shows the types that were resolved from the memory snapshot including the count and total memory footprint.\u00a0 You can navigate to the Instances View<\/strong> by double-clicking a line in this view.\u00a0 You can navigate back to the types view using the back arrow to the left of the type name.<\/p>\n
![\"instancesview\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/instancesview-1024x193.png\")
<\/p>\nThe Stacks View <\/strong>shows the call stack for your program and allows you to navigate through the call path of each captured allocation.\u00a0 You can navigate to the stacks view <\/em>from the types view by selecting Stacks View<\/strong> in the View Mode<\/strong> dropdown.\u00a0 The top section of this page shows the full execution call stack and can be sorted by callee or caller (in-order or reverse) with the control at the top right called Aggregate call stack by<\/strong>.\u00a0 The lower section will list all allocation attributable to the selected part of the call stack.\u00a0 Expanding these allocations will show their allocation call stack.<\/p>\n
![\"stacksview\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/stacksview-1024x662.png\")
<\/p>\nDebugging processes and devices<\/h2>\n
Attaching to Process<\/strong><\/p>\n
Any process running on your Windows machine can be debugged using Visual Studio.\u00a0 If you want to view the variable types, make sure to have the debug symbols loaded for the process that you are attaching to.<\/p>\n
![\"attach\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/attach.png\")
<\/p>\nRemote Debugging<\/strong><\/p>\n
To remotely debug into another machine that you can connect to via your network, enable the remote debugger via the debugger dropdown.\u00a0 This allows you to debug into a machine no matter how far away it is, as long as you can connect to it over a network.\u00a0 You can also easily debug applications running on external devices such as a Surface tablet.<\/p>\n
![\"debugselector\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/debugselector.png\")
<\/p>\nThe IP address and connection details can be managed in the debugger property page, accessed using either Alt+Enter or right-clicking the project in the Solution Explorer.<\/p>\n
![\"debugpp\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/debugpp.png\")
<\/p>\nMulti-threaded debugging<\/h2>\n
Visual Studio provides several powerful windows to help debugging multi-threaded applications.\u00a0 The\u00a0Parallel Stacks<\/strong>\u00a0window is useful when you are debugging multithreaded applications. Its\u00a0Threads View<\/strong>\u00a0shows call stack information for all the threads in your application. It lets you navigate between threads and stack frames on those threads. In native code, the\u00a0Tasks View<\/strong>\u00a0shows call stacks of\u00a0task groups<\/a>,\u00a0parallel algorithms<\/a>,\u00a0asynchronous agents<\/a>, and\u00a0lightweight tasks<\/a>.<\/p>\n
![\"parallelstacks\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/parallelstacks.png\")
<\/p>\nThere is also a Parallel Watch<\/strong> window designed specifically for tracking variables across different threads, showing each thread as a row and each watch (object) as a column.\u00a0 You can also evaluate boolean expressions on the data and export the data to spreadsheet (.csv or Excel) for further analysis.<\/p>\n
![\"parallelthreads\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/parallelthreads.png\")
<\/p>\nEdit and continue<\/h2>\n
Edit and continue<\/strong> allows you to edit some sections of your code during a debugging session without rebuilding, potentially saving a lot of development time.\u00a0 This is enabled by default, and can be toggled or customized using the Debugging options, accessible via the Debug<\/strong> menu and selecting Options<\/strong>.<\/p>\n
![\"enc\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/enc.png\")
<\/a><\/p>\nOther resources<\/h2>\n
If you are interested in some more content and videos about debugging in Visual Studio, check out these links:<\/p>\n
Blog posts<\/strong><\/p>\n
- \n
- Native memory diagnostics<\/u><\/li>\n
- Natvis and debugger visualizers<\/a><\/li>\n
- Edit and Continue Blog Post<\/a><\/li>\n<\/ul>\n
Related documentation<\/strong><\/p>\n
- \n
- Debugging Native Code<\/a><\/li>\n
- Creating custom views of objects with Natvis<\/a><\/li>\n
- Edit and Continue for C++<\/a><\/li>\n<\/ul>\n
Videos<\/strong><\/p>\n
- \n
- Debugging 101 in Visual Studio<\/a><\/li>\n
- C++ Debugging Tips and Tricks<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Debugging is one of the cornerstones of software development, and it can consume a significant portion of a developer\u2019s day.\u00a0 The Visual Studio native debugger provides a powerful and feature-rich experience for finding and fixing problems that arise in your applications, no matter the type of problem or how difficult it is to solve.\u00a0 In […]<\/p>\n","protected":false},"author":295,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-13845","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"
Debugging is one of the cornerstones of software development, and it can consume a significant portion of a developer\u2019s day.\u00a0 The Visual Studio native debugger provides a powerful and feature-rich experience for finding and fixing problems that arise in your applications, no matter the type of problem or how difficult it is to solve.\u00a0 In […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/13845","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/295"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=13845"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/13845\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=13845"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=13845"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=13845"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- C++ Debugging Tips and Tricks<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
- Creating custom views of objects with Natvis<\/a><\/li>\n
- Natvis and debugger visualizers<\/a><\/li>\n
- Native memory diagnostics<\/u><\/li>\n
- Quick Watch<\/strong> is designed for viewing the variable contents without storing it in the Watch window for later viewing. Since the dialog is modal, it is not the best choice for tracking a variable over the entire debugging session: for cases like this the Watch window is preferable.<\/li>\n<\/ul>\n
- Watch: <\/strong>These windows allows you to track variables of interest as you debug your application. Values are only available when the listed variables are in the scope of the debugger.<\/li>\n
- The previous 3 lines of code. As you can see below, when we are at the breakpoint on line 79, the previous three lines are shown, and the current line awaiting execution has been detected, but the value is not yet available until this line executes.<\/li>\n<\/ul>\n
- \n
- \n
- Note that in the example below, line 79 has yet to execute. The variable is not yet initialized and there is no value for the Autos window to display.<\/li>\n<\/ul>\n<\/ul>\n<\/ul>\n
- Autos: <\/strong>This window provides a list of the variables in memory that originate from:\n
- Step over [F10]: <\/strong>Run the next line of code and then break.<\/li>\n
- Data inspection and visualization<\/a><\/li>\n