Navigating through Code with the Debugger

Navigating through Code with the Debugger


There are many ways to move through your code in the debugger: you can step into or over methods, run to a breakpoint or a specified location, and specify whether you want to restrict debugging to your own code or include symbols to debug external code.

One of the most common debugging procedures is stepping. Stepping is executing code one line at a time. When you have halted execution, such as running the debugger to a breakpoint, you can use three Debug menu commands to step through code:

Menu Command

Keyboard Shortcut


Step Into


If the line contains a function call, Step Into executes only the call itself, then halts at the first line of code inside the function. Otherwise, Step Into executes the next statement.

Step Over


If the line contains a function call, Step Over executes the called function, then halts at the first line of code inside the calling function. Otherwise, Step Into executes the next statement.

Step Out


Step Out resumes execution of your code until the function returns, then breaks at the return point in the calling function.

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

  • The debugger actually steps through code statements rather than 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!";

    When you step into this line, the debugger treats the condition as one step and the consequence as another (In this example, the condition is true).

To visually trace the call stack while stepping into functions, see Map methods on the call stack while debugging in Visual Studio.

When you are debugging an application with the VS debugger, your application is either running (executing) or it is in break mode.

The debugger breaks execution of the app when execution reaches a breakpoint or when an exception occurs. You also can break execution manually at any time.

A breakpoint is a signal that tells the debugger to temporarily suspend execution of your app at a certain point. When execution is suspended at a breakpoint, your program is said to be in break mode. Entering break mode does not stop or end the execution of your program; execution can be resumed at any time.

Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only in break mode. All the elements of your app remain (functions, variables, and objects remain in memory, for example), but their movements and activities are suspended. During break mode, you can examine the elements' positions and states to look for violations or bugs. You can also make adjustments to the app while in break mode

You can configure breakpoints to suspend execution based on a number of conditions. See Using Breakpoints. This section describes two basic ways to break into code.

  1. Set breakpoints in the code

    To set a simple breakpoint in your code, open the source file in the Visual Studio editor. Set the cursor at the line of code that you want to break at, and then right-click in the code window to see the context menu and choose Breakpoint / Insert Breakpoint (or press F9). The debugger breaks execution right before the line is executed.

    Set a breakpoint

    Breakpoints in Visual Studio provide a rich set of additional functionality, such as conditional breakpoints and tracepoints. See Using Breakpoints.

  2. Manually break into code

    To break into the next available line of code in an executing app, choose Debug, Break All (keyboard: Ctrl+Alt+Break).

Sometimes you will want to execute to a certain point in code, and then halt execution. If you have a breakpoint set at the location where you want to break, choose Debug, Start Debugging if you have not started debugging, or Debug, Continue. (In both cases F5 is the shortcut key). The debugger stops at the next breakpoint in the execution of the code. Choose Debug, Continue until you reach the breakpoint that you want.

You can also run to where you have placed the cursor in the code editor, or run to specified function.

Run to the cursor location

To run to the cursor location, place the cursor on an executable line of code in a source window. On the editor's context menu (right-click in the editor), choose Run to Cursor.

Run to a function on the call stack

In the Call Stack window, select the function, and choose Run to Cursor from the context menu. To visually trace the call stack, see Map methods on the call stack while debugging in Visual Studio.

Run to a function specified by name

You can command the debugger to run your application 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 by name, choose Debug, New Breakpoint, Break at Function, then enter the name of the function and other identifying information.

New Breakpoint dialog box

If the function is overloaded or is in multiple namespace, you can choose the functions that you want in the Choose Breakpoints dialog box.

Choose Breakpoints dialog box

After you break into the debugger, you can move the execution point to set the next statement of code to be executed. A yellow arrowhead in the margin of a source or Disassembly window marks the location of the next statement to be executed. By moving this arrowhead, you can skip over a portion of code or return to a line previously executed. You can use this for situations such as skipping a section of code that contains a known bug.


To set the next statement to execute, use one of these procedures:

  • In a source window, drag the yellow arrowhead to a location where you want to set the next statement in the same source file

  • In a source window, set the cursor on the line that you want to execute next and choose Set Next Statement on the context menu.

  • In the Disassembly window, set the cursor on the assembly instruction that you want to execute next and choose Set Next Statement on the context menu.


Setting the next statement causes the program counter to jump directly to the new location. Use this command with caution:

  • Instructions between the old and new execution points are not executed.

  • If you move the execution point backwards, intervening instructions are not undone.

  • Moving the next statement to another function or scope usually results in call-stack corruption, causing a run-time error or exception. If you try moving the next statement to another scope, the debugger opens a dialog box with a warning and gives you a chance to cancel the operation. In Visual Basic, you cannot move the next statement to another scope or function.

  • In native C++, if you have run-time checks enabled, setting the next statement can cause an exception to be thrown when execution reaches the end of the method.

  • When Edit and Continue is enabled, Set Next Statement fails if you have made edits that Edit and Continue cannot remap immediately. This can occur, for example, if you have edited code inside a catch block. When this happens, you’ll see an error message that tells you that the operation is not supported.


In managed code, you cannot move the next statement under the following conditions:

  • The next statement is in a different method than the current statement.

  • Debugging was started by using Just-In-Time debugging.

  • A callstack unwind is in progress.

  • A System.StackOverflowException or System.Threading.ThreadAbortException exception has been thrown.

You cannot set the next statement while your application is actively running. To set the next statement, the debugger must be in break mode.

Sometimes, while you are debugging, you might want to look at only the code you have written and ignore other code, such as system calls. You can do this with Just My Code debugging. Just My Code hides non-user code so that it does not appear in the debugger windows. When you step, the debugger steps through any non-user code but does not stop in it. See Just My Code


Just My Code is not supported for device projects.

If you have loaded debugging symbols for the system code and Just My Code is not enabled, you can step into a system call just as you can any other call.

To access Microsoft symbol files, see Use symbol servers to find symbol files not on your local machine in the Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger topic.

To load symbols for a specific system component while you are debugging:

  1. Open the Modules window (keyboard: Ctrl+Alt+U).

  2. Select the module that you want to load symbols for.

    You can tell which modules have symbols loaded by looking at the Symbol Status column.

  3. Choose Load Symbols on the context menu.

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

© 2016 Microsoft