Start, Break, Step, Run through Code, and Stop Debugging in Visual Studio

Start debugging a VS project; attach to a process; break into code; step through code; run to the cursor; run to a function on the call stack; set next statement; step through Just My Code; Stop, restart debugging; detach from a debugged process.

When a solution is open is Visual Studio, you have three choices to start debugging:

Choose Debug, Start Debugging (keyboard: F5).

Your app starts and then runs until:

  • The debugger reaches a breakpoint.

  • You choose Stop Debugging on the Debug menu.

  • An exception is thrown.

  • The application exits.

Choose Debug, Step Into (keyboard: F11) or Debug, Step Over (Keyboard: F10).

Your app starts and then breaks on the first line.

In a source window, select a line of executable code and choose Run to Cursor on the context menu.

Your app starts and runs until it reaches a breakpoint or the cursor location, whichever comes first.

To visually trace your code’s execution on a code map while debugging, see Visualize and Debug Code Execution with Call Stacks in Visual Studio.

The debugger can also to attach to a program that is running in a process outside of Visual Studio. After you attach to a program, you can use debugger execution commands, inspect the program state, and so on. Your ability to inspect the program might be limited, depending on whether the program was built with debug information and whether you have access to the program's source code, and whether the common language runtime JIT compiler is tracking debug information.

To attach to a process that is running on your local machine

Choose Debug, Attach to Process. On the Attach to Process dialog box, select the process from the Available Processes list, and then choose Attach.

Attach to Process dialog box

See Attach to Running Processes with the Visual Studio Debugger for more information.

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 Breakpoints: Use Hit Counts, Call Stack Functions, and Conditions to Break When and Where You Want in the Visual Studio Debugger. 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 choose Breakpoint, Insert Breakpoint on the context menu (Keyboard: F9. The debugger breaks execution right before the line is executed.

Set a breakpoint

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).

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 Visualize and Debug Code Execution with Call Stacks in Visual Studio.

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. See Set breakpoints in the code in this topic.

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, 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 Visualize and Debug Code Execution with Call Stacks 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.

Caution noteCaution

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.

To enable or disable Just My Code debugging, choose Debug, Options and Settings. On the Debugging, General page, check or clear Enable Just My Code.

To distinguish user code from non-user code, Just My Code looks at symbol (PDB) files and program optimizations.

In a standard Debug build, optimization is turned off and debug symbols are created for all modules. When you run a debug build, those modules are considered to be user code. But a library function that is optimized and does not have debug symbols is not considered user code. Just My Code prevents execution from stopping at breakpoints in the library code, which is usually not code you are interested in debugging. In the Breakpoints window, those breakpoints will appear with the Disabled Breakpoint icon.

To see all code and stop at all breakpoints, you can turn off Just My Code debugging by using the Options dialog box.

Three attributes also affect what the debugger considers to be My Code: DebuggerNonUserCodeAttribute tells the debugger that the code it is applied to is not My Code. DebuggerHiddenAttribute hides the code from the debugger, even if Just My Code is turned off. DebuggerStepThroughAttribute tells the debugger to step through the code it is applied to, rather than step into the code.

When Just My Code is enabled, you can choose Break All on the Debug menu and stop execution at a location where there is no My Code to display. When that happens, no code is displayed. Additionally, if you choose a Step command, it will take you to the next line of My Code.

Programmatic break statements, such as Visual Basic Stop statements, are handled differently. The debugger always breaks on these statements, even when Just My Code is enabled. In this situation, non-user code is displayed rather than hidden, but stepping will still take you out of non-user code to the next line of 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 learn how to disable Just My Code, see Restrict stepping to Just My Code

To access Microsoft symbol files, see Using Windows and other Microsoft symbols 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

Stopping debugging means terminating the debugging session. Stopping execution means terminating the process you are debugging and ending the debugging session. It should not be confused with breaking execution, which temporarily halts execution of the process you are debugging but leaves the debugging session active. Detaching from a process stops debugging the process but leaves it running.

Choose Debug, Stop Debugging to terminates the process you are debugging when the program was launched from Visual Studio. If you attached to the process instead of launching it from Visual Studio, the process continues running.

When you exit an app that is being debugged, debugging stops automatically.

Choose Debug, Restart to stop the current debugging session and restart the startup project in the debugger.

Choose Debug, Detach All to stop debugging, but leave the debugged process or processes running.


See Attach to Running Processes with the Visual Studio Debugger and Debug One or More Processes in the Visual Studio Debugger to learn more about attaching to and controlling multiple processes with Visual Studio.