Learn Visual Studio debugger productivity tips and tricks
Learn Visual Studio debugger productivity tips and tricks
Read this topic to learn some productivity tips and tricks for the Visual Studio debugger. For more information on the basic features of the debugger, see Introduction to the debugger. This topic covers some areas that are not included in the feature tour.
Data pinning tips
If you frequently hover over a data tip while debugging, you can pin the data tip for a variable for quick access. Variables remain fixed after restart. To pin a data tip, hover over the pin icon and click. You can pin multiple variables.
Continue debugging while editing code (C #, VB, C ++)
In most languages supported by Visual Studio, you can edit code and continue debugging during a debugging session. To use this feature, while paused in the debugger, use your cursor to click the code, make edits, and press F5, F10, or F11 to continue debugging.
Edit XAML code and continue debugging
To modify XAML code during a debugging session, see Write and Code XAML Code to Debug Using XAML Hot Reload.
Debug problems that are difficult to reproduce
Consider using conditional breakpoints if your app's specific state is difficult to reproduce or takes a long time. You can use conditional breakpoints and filter breakpoints to ensure that your app code doesn't break until your app is in the required state (for example, a variable stores invalid data). Conditions can be set using expressions, filters, hit counts, and more.
To create a conditional breakpoint
Right-click the breakpoint icon (red ball) and select Condition.
Enter an expression in the Breakpoint Settings window.
Configuring data to display in the debugger
For C #, Visual Basic, and C ++ (C ++ / CLI code only), you can use the DebuggerDisplay attribute to tell the debugger what information to display. For C ++ code, you can do the same thing using Natvis visualization.
Change execution flow
With the debugger paused on the line of code, use your mouse to grab the yellow arrow pointer to the left. Move the yellow arrow pointer to another point in the code execution path. Then use the F5 key or step command to continue running the app.
Track out-of-scope objects (C #, Visual Basic)
You can easily view variables using a debugger window, such as a watch window. However, variables outside the scope of the Watch window may be grayed out. In some application scenarios, variable values can change even when the variables are out of range, so you may need to watch closely (for example, variables may be garbage collected). You can track variables by creating an object ID for them in the Watch window.
To create an object ID
Set breakpoints near the variables you want to track.
Start the debugger (F5) and stop at the breakpoint.
Find the variable in the Region pane (Debug> Windows> Region), right-click the variable and select Object ID.
Close the local window to the $ window. This variable is the object ID.
Right-click the object ID variable and select Add Watch.
For more information, see Create an object ID.
View the return value of a function
To see the return value of the function, check the function displayed in the auto window while stepping through the code. To see the return value of a function, make sure that the function of interest has already been executed (press F10 if it is stopped in the current function call). When the window is closed, use Debug> Windows> Auto to open the auto window.
String checking in Visualizer
When working with strings, it can be helpful to see the entire formatted string. To view plain text, XML, HTML, or JSON strings, hover over the variable containing the string value and click the magnifying glass icon VisualizerIcon.
The String Visualizer can help you determine whether a string is malformed depending on the string format. For example, an empty value field indicates that the visualizer type does not recognize the string. For more information, see String Visualizer Dialog Box.
Abort code on handled exception
The debugger breaks the code on unhandled exceptions. However, handled exceptions (such as those that occur within a try / catch block) may be the source of the bug, so you may need to investigate when it occurred. You can configure the debugger to break code even on handled exceptions by configuring options in the Exception Settings dialog box. Select Debug> Windows> Set exceptions to open this dialog.
You can use the Exception Settings dialog box to instruct the debugger to break the code on a specific exception. In the figure below, whenever the System.NullReferenceException is thrown, the debugger breaks the code. For more information, see Exception Management.
Debug deadlocks and races
If you need to debug the types of problems common to multithreaded apps, it is often helpful to check the location of the threads while debugging. You can easily do this using the Show Thread button in the source.
To show threads in source code
While debugging, on the Debug toolbar, click Show Threads From Source button Show Threads From Source.
Check the margins on the left side of the window. This line shows a thread marker icon with a double-stranded thread marker. The thread marker indicates that the thread has stopped at this location.
Thread markers can be partially obscured by breakpoints.
Place the pointer over the thread marker. DataTips appears. The DataTip gives you the name and thread ID number of each thread you stopped.
You can also see the thread location in the parallel stack window.
