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:
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.
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 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:
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.
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.
Breakpoints in Visual Studio provide a rich set of additional functionality, such as conditional breakpoints and tracepoints. See Using Breakpoints.
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).
If you are debugging with the Just My Code option enabled, you break at the next line of code in your project. See Restrict stepping to Just My Code.
If you are debugging multiple programs, a breakpoint or Break All command affects all programs being debugged by default. See Configure the execution behavior of multiple processes.
If you break while executing code without corresponding source or symbol (.pdb) files), the debugger displays a Source Files Not Found or a Symbols Not Found page that can help you find the appropriate files. See Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger.
If you can't access the supporting files, you can still debug the assembly instructions in the Disassembly window.
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.
If the function is overloaded or is in multiple namespace, you can choose the functions that you want in the 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:
In managed code, you cannot move the next statement under the following conditions:
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:
Open the Modules window (keyboard: Ctrl+Alt+U).
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.
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