A breakpoint tells the debugger that an application should break (pause execution) at a certain point or when a certain condition occurs. When a break occurs, your program and the debugger are said to be in break mode. For more information, see Breaking Execution.
The Visual Studio debugger has four types of breakpoints:
- A function breakpoint causes the program to break when execution reaches a specified location within a specified function.
- A file breakpoint causes the program to break when execution reaches a specified location within a specified file.
- An address breakpoint causes the program to break when execution reaches a specified memory address.
- A data breakpoint causes the program to break when the value of a variable changes. You can set a data breakpoint on a global variable or a local variable in the top-most scope of a function. (C++ only)
To provide greater power and flexibility, you can modify the behavior of a breakpoint by adding these properties:
- A Hit Count property, which determines how many times a breakpoint must be hit before execution breaks. (By default, execution breaks every time a breakpoint is hit.) For more information, see Hit Count.
- A Condition, which is an expression that determines whether the breakpoint is hit or skipped. For more information, see Condition.
You can set, enable, disable, edit, or delete breakpoints in source windows, the Breakpoints window, or the Disassembly window.
The Breakpoints Window
The Breakpoints window lists all breakpoints currently set in your program and displays their properties. In the Breakpoints window, you can set (create) new breakpoints, delete breakpoints, enable or disable breakpoints, edit a breakpoint's properties, or go to the source or disassembly code corresponding to a breakpoint. For more information, see Using the Breakpoints Window.
The source windows and Disassembly window show the location of a breakpoint by coloring the text where the breakpoint is located and displaying a symbol or glyph in the left margin.
|Enabled||A normal or active breakpoint. This is where execution will break if the breakpoint condition and hit count settings are met.|
|Disabled||A breakpoint that will be ignored by the debugger. It does not affect execution until re-enabled.|
|Error||A breakpoint cannot be set because the location or condition is not valid.|
|Warning||A breakpoint cannot be set because the code at this location is not loaded. If the code is loaded in the future (for example, when a class or DLL is loaded), the breakpoint becomes an enabled breakpoint.|
|Mapped||A breakpoint is set in ASP code, and a corresponding breakpoint is set in the generated html page.|
The Debug Menu
No matter which window you are using, you can insert a new breakpoint of any type from the Debug menu. For more information, see Inserting a New Breakpoint from the Debug Menu.
You can also remove all breakpoints from the Debug menu. For more information see, Removing All Breakpoints.
Limitations and Changes
Avoid setting breakpoints on system components when you are debugging mixed-mode (native and managed) code. Setting a breakpoint on a system component during mixed-mode debugging can cause the common language runtime to break and the debugger to stop responding. For more information, see Mixed-Mode Debugging.
In the Visual C++ 6.0 debugger, you needed to specify the names of the DLLs you wanted to debug (in the Additional DLLs dialog box). In the Visual Studio .NET debugger, you can set a breakpoint on a DLL that is not yet loaded. The Additional DLLs dialog box no longer exists.
You can automate many debugger features by using the Visual Studio extensibility model. For more information, see the Visual Studio Debugger Model.