Breakpoints Overview

Article
11/16/2012

This topic applies to:

Edition	Visual Basic	C#	C++	Web Developer
Express
Standard
Pro and Team

Table legend:

	Applies
	Does not apply
	Command or commands hidden by default.

The following sections provide some basic information about breakpoints:

Breakpoint Glyphs
Basic Breakpoints
Advanced Breakpoints
Breakpoint Limitations

Breakpoint Glyphs

The source windows and Disassembly window show breakpoint locations by displaying symbols called glyphs in the left margin. The following table describes these glyphs.

If you rest the mouse on a breakpoint glyph, a breakpoint tip appears with more information. This information is especially useful for error and warning breakpoints.

Glyph	Description
	Normal breakpoint. The solid glyph indicates that the breakpoint is enabled. The hollow glyph indicates that it is disabled.
	Advanced breakpoint. Active/disabled. The + sign indicates that the breakpoint has at least one advanced feature, such as condition, hit count, or filter, attached to it.
	Mapped breakpoint. Active/disabled. The breakpoint is set in ASP/ASP.NET code and mapped to a breakpoint in the corresponding HTML page or set in a server-side script file and mapped to the corresponding client-side script file.
	Tracepoint. Active/disabled. Hitting this point performs a specified action but does not break program execution.
	Advanced tracepoint. Active/disabled. The + sign indicates that the tracepoint has at least one advanced feature, such as condition, hit count, or filter, attached to it.
	Mapped tracepoint. Active/disabled. The tracepoint is set in ASP/ASP.NET code and mapped to a tracepoint in the corresponding HTML page.
	Breakpoint or tracepoint error. The X indicates that the breakpoint or tracepoint could not be set because of an error condition.
	Breakpoint or tracepoint warning. The exclamation mark indicates that a breakpoint or tracepoint could not be set because of a temporary condition. Usually, this means the code at the breakpoint or tracepoint location has not been loaded. It can also be seen if you attach to a process and the symbols for the process are not loaded. When the code or symbols are loaded, the breakpoint will be enabled and the glyph will change.

Basic Breakpoints

The most basic breakpoints are those set on a line of source code or on a function. The following topics describe how to set and manipulate these basic breakpoints:

How to: Set a Simple Breakpoint

How to: Set a Function Breakpoint

How to: Delete a Breakpoint

How to: Enable or Disable a Breakpoint

How to: Edit a Breakpoint Location

How to: Set a Breakpoint on a Function Call from the Call Stack Window

Note

If you have more than 64,000 lines of code in one source file, breakpoints placed on lines after 64,000 will not be hit.

Multiple Breakpoints on a Line

Sometimes, a line of code contains more than one executable statement. In such cases, you can set more than one breakpoint on the line. A new feature in Visual Studio 2008 is a box that appears around the code statement containing the currently selected breakpoint. This box can be useful for distinguishing multiple breakpoints on the same line of code. You can select a breakpoint in the Breakpoints window or by clicking the statement that contains the breakpoint in the source window.

Advanced Breakpoints

If you have Visual C++ Express or Visual Studio, any edition, you can set more advanced breakpoints, create breakpoints with advanced features, and manipulate breakpoints in more powerful ways.

For some tasks, the default IDE settings that you chose when you set up Visual Studio might hide the required menu command. For more information, see How to: Restore Hidden Debugger Commands.

Breakpoints on Memory Addresses and Memory Changes

You can set a breakpoint on a memory address. For more information, see How to: Set an Address Breakpoint. In C/C++, you can set a breakpoint that is hit when memory changes. For more information, see How to: Set a Data Breakpoint (Native Only).

Filters, Hit Counts, and Conditions

Filters, hit counts, and conditions are advanced features that you can attach to any type of breakpoint, including tracepoints.

A filter causes a breakpoint to be set on specified machines, processes, and threads. Filters are very useful when you are debugging an application that runs on multiple processors. For more information, see How to: Specify a Breakpoint Filter.
A hit count keeps track of how many times a breakpoint is hit. By default, a breakpoint breaks execution every time it is hit. You can change this behavior so the breakpoint breaks only when the hit count equals or exceeds a specified value or when the hit count is the multiple of a given value. The specified hit count is retained only for the debugging session. For more information, see How to: Specify a Hit Count.
A condition is an expression that is evaluated to determine whether the breakpoint will break. For more information, see How to: Specify a Breakpoint Condition.

Advanced Breakpoints Interface

Power users can take advantage of advanced features in the following topics:

How to: Use the Breakpoints Window

How to: Disable All Breakpoints

How to: Delete All Breakpoints

Breakpoint Limitations

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 How to: Debug Mixed-Mode Applications.

The debugger does not automatically attach to an XML Web service unless you step into the call. This means that any breakpoints set in the XML Web service will not be hit unless you step into the call. If you try to run to the breakpoint by using Start Debugging or Continue, instead of using Step Into, the breakpoint will not be hit.

For information about limitations on mapped breakpoints in script files, see Limitations on Script Debugging.