Sdílet prostřednictvím


Navigate through code by using the Visual Studio debugger

Applies to: yesVisual Studio noVisual Studio for Mac

Note

This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here

The Visual Studio debugger can help you navigate through code to inspect the state of an app and show its execution flow. You can use keyboard shortcuts, debug commands, breakpoints, and other features to quickly get to the code you want to examine. If you're familiar with debugger navigation commands and shortcuts, you can find and resolve app problems faster and more easily.

Note

If you're new to debugging code, you might want to read Debugging for absolute beginners and Debugging techniques and tools before you read this article.

Enter break mode

In break mode, app execution is suspended while functions, variables, and objects remain in memory. When the debugger is in break mode, you can navigate through your code. There are two common ways to quickly enter break mode:

  • Begin code stepping by selecting F10 or F11. Doing so allows you to quickly find the entry point of your app. You can then continue to press step commands to navigate through the code.

  • Run to a specific location or function, for example, by setting a breakpoint and starting your app.

    For example, in the code editor in Visual Studio, you can use the Run To Cursor command to start the app, debugger attached, and enter break mode, and then select F11 to navigate through the code:

When you're in break mode, you can use various commands to navigate through your code. You can examine the values of variables to look for violations or bugs. For some project types, you can also make adjustments to the app when you're in break mode.

Most debugger windows, like the Modules and Watch windows, are available only when the debugger is attached to your app. Some debugger features, like viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only when the debugger is paused (that is, in break mode).

Note

If you break into code that doesn't have source or symbol (.pdb) files loaded, the debugger displays a Source Files Not Found or Symbols Not Found page that can help you find and load the files. See Specify symbol (.pdb) and source files. If you can't load the symbol or source files, you can still debug the assembly instructions in the Disassembly window.

Step through code

The debugger step commands help you inspect your app state or find out more about its execution flow.

Step into code line by line

To stop on each statement when you're debugging, use Debug > Step Into, or select F11.

The debugger steps through code statements, not physical lines. For example, an if clause can be written on one line:

int x = 42;
string s = "Not answered";
if( int x == 42) s = "Answered!";
Dim x As Integer = 42
Dim s As String = "Not answered"
If x = 42 Then s = "Answered!"

But when you step into this line, the debugger treats the condition as one step and the consequence as another. In the preceding example, the condition is true.

On a nested function call, Step Into steps into the most deeply nested function. For example, if you use Step Into on a call like Func1(Func2()), the debugger steps into the function Func2.

Tip

As you run each line of code, you can hover over variables to see their values, or use the Locals and Watch windows to watch the values change. You can also visually trace the call stack while you step into functions. (For Visual Studio Enterprise only, see Map methods on the call stack while debugging.)

Step through code and skip some functions

You might not care about a function when you're debugging. Or might you know some code works, like well-tested library code. You can use the following commands to skip code when you're code stepping. The functions still run, but the debugger skips over them.

Keyboard command Debug menu command Description
F10 Step Over If the current line contains a function call, Step Over runs the code and then suspends execution at the first line of code after the called function returns.
Shift+F11 Step Out Step Out continues running code and suspends execution when the current function returns. The debugger skips through the current function.

Run to a specific location or function

You might prefer to run directly to a specific location or function when you know exactly what code you want to inspect or if you know where you want to start debugging.

Run to a breakpoint in code

To set a simple breakpoint in your code, select the far-left margin next to the line of code where you want to suspend execution. You can also select the line and then select F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert Breakpoint. The breakpoint appears as a red dot in the left margin next to the line of code. The debugger suspends execution just before the line runs.

Breakpoints in Visual Studio provide a rich set of functionality, like conditional breakpoints and tracepoints. For details, see Using breakpoints.

Run to a function breakpoint

You can set the debugger to run until it reaches a specified function. You can specify the function by name, or you can choose it from the call stack.

To specify a function breakpoint by name

  1. Select Debug > New Breakpoint > Function Breakpoint.

  2. In the New Function Breakpoint dialog, enter the name of the function and select its language:

  3. Select OK.

If the function is overloaded or in more than one namespace, you can choose the one you want in the Breakpoints window:

To select a function breakpoint from the call stack

  1. While debugging, open the Call Stack window by selecting Debug > Windows > Call Stack.

  2. In the Call Stack window, right-click a function and select Run To Cursor, or select Ctrl+F10.

For information about visually tracing the call stack, see Map methods on the call stack while debugging.

Run to a cursor location

To run to the cursor location, in source code or the Call Stack window, select the line you want to break at, and then right-click and select Run To Cursor, or select Ctrl+F10. Selecting Run To Cursor is like setting a temporary breakpoint.

Run to Click

While the debugger is paused, you can hover over a statement in source code or the Disassembly window and select the Run execution to here green arrow. If you use Run to Click, you don't need to set a temporary breakpoint.

Screenshot that shows Run to Click and the green arrow.

Note

Run to Click is available starting in Visual Studio 2017.

Manually break into code

To break into the next available line of code in a running app, select Debug > Break All, or select Ctrl+Alt+Break.

Move the pointer to change the execution flow

When the debugger is paused, a yellow arrow in the margin of the source code or Disassembly window marks the location of the statement that will run next. You can change the next statement that will run by moving this arrow. You can skip over code or return to a previous line. Moving the pointer is useful for situations like skipping code that contains a known bug.

If you want to change the next statement that will run, the debugger must be in break mode. In the source code or Disassembly window, drag the yellow arrow to a different line, or right-click the line you want to run next and select Set Next Statement.

The program counter jumps directly to the new location. Instructions between the old and new execution points aren't run. But if you move the execution point backwards, the intervening instructions aren't undone.

Caution

  • Moving the next statement to another function or scope usually causes call-stack corruption, which causes a runtime error or exception. If you try to move the next statement to another scope, the debugger gives you a warning and a chance to cancel the operation.
  • In Visual Basic, you can't move the next statement to another scope or function.
  • In native C++, if you have runtime checks enabled, setting the next statement can cause an exception when execution reaches the end of the method.
  • When Edit and Continue is enabled, Set Next Statement fails if you've made edits that Edit and Continue can't remap immediately. This situation can occur, for example, if you've edited code in a catch block. When this happens, an error message tells you that the operation isn't supported.
  • In managed code, you can't move the next statement if:
    • The next statement is in a different method than the current statement.
    • Debugging was started by Just-In-Time debugging.
    • A call stack unwind is in progress.
    • A System.StackOverflowException or System.Threading.ThreadAbortException exception has been thrown.

Debug non-user code

By default, the debugger tries to debug only your app code by enabling a setting called Just My Code. For details about how this feature works for various project types and languages, and how you can customize it, see Just My Code.

To look at framework code, third-party library code, or system calls while debugging, you can disable Just My Code. In Tools (or Debug) > Options > Debugging, clear the Enable Just My Code checkbox. When Just My Code is disabled, non-user code appears in the debugger windows, and the debugger can step into the non-user code.

Note

Just My Code isn't supported for device projects.

Debug system code

If you've loaded debugging symbols for Microsoft system code and disabled Just My Code, you can step into a system call just as you can any other call.

To learn about loading Microsoft symbols, see Configure location of symbol files and loading options.

To load symbols for a specific system component

  1. While you're debugging, open the Modules window by selecting Debug > Windows > Modules or by pressing Ctrl+Alt+U.

  2. In the Modules window, you can tell which modules have symbols loaded in the Symbol Status column. Right-click the module that you want to load symbols for and then select Load Symbols.

Step into properties and operators in managed code

The debugger steps over properties and operators in managed code by default. In most cases, this behavior provides a better debugging experience. To disable stepping into properties or operators, select Debug > Options. On the Debugging > General page, clear the Step over properties and operators (Managed only) checkbox.

See also