Using Breakpoints and Tracepoints

Article
02/04/2013

This topic applies to:

Edition	Visual Basic	C#	F#	C++	Web Developer
Express
Pro, Premium, and Ultimate

This topic provides some basic information about breakpoints:

Breakpoint Glyphs
Basic Breakpoints
Multiple Breakpoints on a Line
Advanced Breakpoints
Breakpoint Limitations

Breakpoint Glyphs

The source windows and the 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 that 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 that 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 work with these basic breakpoints:

How to: Set a Simple Breakpoint

How to: Set a Function Breakpoint

How to: Delete Breakpoints

How to: Enable or Disable Breakpoints

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 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 box appears around the code statement that contains 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 work with 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 kind of breakpoint, including tracepoints.

A filter causes a breakpoint to be set on specified computers, 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 that 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 described in the following topics:

How to: Use the Breakpoints Window

How to: Delete Breakpoints

How to: Enable or Disable 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 Debugging 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 more information about limitations on mapped breakpoints in script files, see Limitations on Script Debugging.