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.

Contents

Start debugging a VS project; attach to a process

Break into code, step or run through code, set the next statement to execute

Stop, restart debugging; detach from the debugged process

Start debugging a VS project; attach to a process

• Start debugging a VS project • Attach to a process

Start debugging a VS project

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

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.

Start debugging a VS project; attach to a process

Contents

Attach to a process

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.

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

Start debugging a VS project; attach to a process

Contents

Break into code, step or run through code, set the next statement to execute

• Break into code by using breakpoints or Break All • Step into, over, or out of the code • Run to a specified location or function • Set the next statement to execute • Restrict stepping to Just My Code • Step into system calls • Step into properties and operators in managed code

Break into code by using breakpoints or Break All

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.

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 Change the break behavior of multiple processes in this topic.

• If you break while executing code without corresponding source or symbol (.pdf) 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.

Break into code, step or run through code, set the next statement to execute

Contents

Step into, over, or out of the 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:

• 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!";
  

  Dim x As Integet = 42
  Dim s As String = "Not answered"
  If x = 42 Then 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.

Break into code, step or run through code, set the next statement to execute

Contents

Run to a specified location or function

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.

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

Break into code, step or run through code, set the next statement to execute

Contents

Set the next statement to execute

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.

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

Break into code, step or run through code, set the next statement to execute

Contents

Restrict stepping to Just My Code

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.

Break into code, step or run through code, set the next statement to execute

Contents

Step into system calls

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.

Break into code, step or run through code, set the next statement to execute

Contents

Step into properties and operators in managed code

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

Break into code, step or run through code, set the next statement to execute

Contents

Stop, restart debugging; detach from the debugged process

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.

• Stop debugging from VS • Close the app that is being debugged • Restart debugging • Detach from the debugged app

Stop debugging from VS

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.

Stop, restart debugging; detach from the debugged process

Contents

Close the app that is being debugged

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

Restart debugging

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

Stop, restart debugging; detach from the debugged process

Contents

Detach from the debugged app

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

Stop, restart debugging; detach from the debugged process

Contents