Searching for Breakpoints in Microsoft Visual Studio 2010

by Paul Kimmel

Microsoft Visual Studio has extensive support for setting breakpoints with extra conditions, including code, and then searching for and managing those breakpoints. Read more to see how to put beakpoints to work for you.


I wrote my first BASIC code in 1978. I first got paid for writing a little code in 1987. This is a fact. In this business that means I have some perspective, some experience, and know a lot of things that aren't that useful anymore. Just like everyone else in this business I have to keep learning.

The perspective part reminds me that there was a time when breakpoints could be added by inserting a call to interrupt 3, a low level system service. Perspective reminds me that we haven't always had integrated development environments, and we had to use make files and command line compilers. Perspective also reminds me that debugging used to require a lot of extra code, print statements, and meticulously reading and auditing code manually. Old school debugging was a big, expensive, time consuming, pain in the butt. Then, we had integrated development environments, IDEs. The first IDE I used was for Turbo Pascal from Borland. (Remember Borland?) The next two languages and products I used routinely included an IDE for C++ and a very early version of Visual Basic for DOS. Programming environments progressively make software development easier.

Microsoft Visual Studio 2010 permits setting all manner of breakpoints with subsidiary settings. In large projects you can end up with a large number of breakpoints, finding and managing them can be a chore if you manually search through breakpoints. In this article I will quickly review several of the kinds of breakpoints and subsidiary settings you can make in Microsoft Visual Studio 2010 and then explore the features that support managing those breakpoints effectively.

Editing Breakpoints

The quickest way to set a breakpoint is to place the cursor in the Microsoft Visual Studio editor window and press F9 (or choose the Debug|Toggle Breakpoint menu item). A lot of the time just having a breakpoint at a certain location helps me find a bug. It is when things are going seriously wrong that a simple breakpoint might not be enough.

To review, when you set a breakpoint a red graphical dot is placed in the margin adjacent to the line where the breakpoint has been sent. If you right-click on the graphical red dot a breakpoint context menu is displayed. The easiest way to access advanced breakpoint options is through this context menu.

Setting Hit Count

One of the techniques I used to use is to add the keyword Stop where I needed a breakpoint. Stop was an earlier version of the breakpoint. If a break was needed based on a condition then some conditional code was manually added and the Stop was called when the condition was met. With Stop the Stop traveled with the code, but you had to manually manage Stop statements by commenting them out or removing them when you were finished. Further Stops cannot be set on a function or a memory address, making Stop a weak choice. Avoid using the Stop statement in general.

Suppose you have an iterative call or loop statement and you are getting an error. You don't want to manually step through every iteration or call manually, especially if you suspect the error is occurring later in the iteration process. By using the Hit Count option you can set a breakpoint to break when a specific number of iterations have happened. The code in Listing 1 demonstrates a simple for loop with a breakpoint set when the hit count is 25 (see Figure 1).

  Private Sub HitCount()
    For i As Integer = 1 To 50
      Console.WriteLine("{0}: Break on 25", i)
  End Sub
Listing 1: A simple for loop with 50 iterations.

Figure 1: Adjust a breakpoint to break when that line of code is hit a certain number of times

To set the hit count breakpoint place the cursor on the line you'd like to break on. Right-click the breakpoint icon, click Hit Count, and select the desired option when the breakpoint is hit. You can choose from the following options: "break always", "break when the hit count is equal to", "break when the hit count is a multiple of", or select "break when the hit count is greater than or equal to". In the edit field enter the numeric value for the hit count option, and click OK. If you want to reset the current hit count click Reset before you close the dialog.

When you close the dialog the red graphical image will be replaced with a red graphical image with a + symbol in the center of the icon. The plus sign represents that the breakpoint has additional information associated with it.

If you want to see (or manage) all of the breakpoints in your project select Debug|Windows|Breakpoints to open the Breakpoints window. In Figure 2 you can see the break just set--it's the first one--with the Condition and Hit Count information visible in the window.

Figure 2: The hit count breakpoint shows up in the breakpoints window, including the information relevant to the breakpoint

Defining a Breakpoint Condition

Going forward let's agree that you can right-click on a breakpoint and access breakpoint options.

To set a condition just as you would use conditional code, click the Condition context menu item and write the condition--see Figure 3. In the code in Listing 2 File.Exists is used as a conditional test and Not File.Exists is used in the Breakpoint condition dialog to break only when the file doesn't exist.

Figure 3: A breakpoint condition breaks when the condition is met or the condition has changed based on which radio option you select

  Private Sub BreakpointCondition()
    If File.Exists("dummy.txt") Then
      Dim info As FileInfo = New FileInfo("dummy.txt")
    End If
  End Sub
Listing 2: Code that contains a conditional check for the existence of a file.

Defining a Breakpoint Filter

A neat feature is setting a breakpoint filter based on a specific process, thread or machine. I don't use this feature that often because, but if you are using threads heavily or switching between machines then a filter may come in handy. To set a filter based on a specific machine name, open the Breakpoint Filter dialog and type in the filter as illustrated in Figure 4.

Figure 4: The breakpoint associated with this filter will break only if we are debugging on the computer named Caspar

Tip: If you go to the trouble of setting a breakpoint with conditions, hit counts, or filters and want to move the breakpoint open the File Breakpoint window by clicking the Location context menu item and changing the Line number; it is a lot easier than deleting and re-working all of the subsidiary breakpoint information-see Figure 5.

Figure 5: To move a breakpoint change the Line number from the Location option (which displays the File Breakpoint window)

Using the When Breakpoint Is Hit Feature

The "When Breakpoint Is Hit" feature can perform a variety of actions including printing information about where the break occurred or running a macro. The sky is pretty much the limit if you select Run a macro. Because macros can tap into the IDE and the extensibility features of Microsoft Visual Studio and run code, you can have complex behaviors associated with a macro. There are already tons of pre-canned macros to select from and you can of course add your own. (For more information about writing and using your own macros see my earlier article "Running Custom Tracepoint Macros in Visual Studio".

Figure 6 shows the "When Breakpoint Is Hit" window. Based on the settings shown the Function, Thread ID, and Thread Name will be sent to the Immediate Window, a macro will be run, and execution will continue. The macro selected is Macros.Samples.VSEditor.OneFunctionView; this macro collapses all of the code except the function that contains this breakpoint. When the code is hit the text editor (for my sample program) will look like Figure 7.

Figure 6: As configured when the breakpoint is hit a message will be printed and the OneFunctionView macro will be run

Figure 7: The OneFunctionView macro collapses all of your code except the function in which the macro was invoked (by the When Breakpoint Is Hit feature)

Searching for Breakpoints

All you need is a few breakpoints to begin exploring the features in Microsoft Visual Studio 2010 that support searching for and managing breakpoints. In Figure 2 you can see that the project I am working on has four breakpoints using a variety of breakpoint features. This will be sufficient to demonstrate breakpoint search features.

To begin open the Breakpoints window from Debug|Windows|Breakpoints menu option in Microsoft Visual Studio 2010. Whatever breakpoints your project has will be displayed in in the Breakpoints window. Using Figure 8 as a guide let's walk through the Breakpoints windows features.

Figure 8: Use this figure as a visual guide to when we explore the Breakpoints window

Starting from top left and working across the Breakpoints window toolbar the features of the toolbar are described as follows:

  • The New button creates a new function breakpoint
  • The Delete button deletes selected breakpoints
  • The next button deletes all breakpoints matching the current search criteria
  • The fourth button enables or disables all breakpoints matching the search criteria
  • The fifth button from the left exports all breakpoints matching the search criteria to an XML file
  • The sixth button imports breakpoints from a file
  • The seventh button moves the focus to the place in code represented by the selected breakpoint
  • The Columns dropdown determines which columns show up in the Breakpoints window; for example, if you wanted to see breakpoint filter information then click the dropdown and the Filter item
  • The Search dropdown lets you enter search criteria and stores previous search criteria
  • The In Column dropdown determines which columns the search is performed in; by default all columns are searched
  • The final [X] button resets all search criteria so that all breakpoints are shown

Suppose you wanted to find breakpoints that include the search term 'File' in the Condition column. Click the In Column button and select Condition, and then enter the word File in the Search dropdown/edit box-see Figure 9. To reset the search criteria and show all breakpoints click the right-most button.

Figure 9: Shows the search settings set to look for the word 'File' in the Condition column

Importing and Exporting Breakpoints That Match Search Criteria

If you want to save your breakpoints to a separate XML file then click the fifth button from the left. (The toolbar button has a red round icon with a small floppy disk image.) You can create breakpoints by importing a saved breakpoints file. I don't use this feature that often, but if you save your breakpoints to an external file then you can freely experiment with alternatives and add and remove breakpoints knowing that you can always restore them if you are unhappy with the alternatives.

If you perform a search on breakpoints with the word File and export the results-at least in my project-the exported XML file will contain the content shown in Listing 3.

  <?xml version="1.0" encoding="utf-8"?>
  <BreakpointCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <ConditionText>Not File.Exists("dummy.txt")</ConditionText>
            <Bytes />
        <Labels />
Listing 3: The exported returned breakpoints information.

Enabling and Disabling Breakpoints That Match Search Criteria

If you want to enable or disable a single breakpoint then check the box next to the breakpoint or uncheck the box as the case may be. If you click the enable/disable toolbar button then breakpoints that match the search criteria will be disabled or enabled. This button acts as a toggle. If the Search edit field is blank then the enable/disable button will enable or disable all breakpoints.

Deleting Breakpoints That Match Search Criteria

Finally, if you want to remove a block of breakpoints then perform a search to limit the breakpoints in the window and click the delete button, second from the left. A reasonable strategy is to treat the export button as a backup tool and save all of your breakpoints before performing multiple deletes.


You have to set breakpoints to search for them, and you have to search for breakpoints before managing them. Microsoft Visual Studio has extensive support for breakpoints and subsidiary information associated with those breakpoints. You no longer have to write a lot of conditional debug code and use stops to perform complex debugging operations. Simply take advantage of the basic breakpoint and the context menu for breakpoints and use hit counts, conditions, filters, or whatever when you need more than a basic breakpoint.

As your project grows you can leave your breakpoints in place confident that you can search for the ones you are interested in, save and restore them, add and remove them, and modify or update your breakpoints with impunity.

This article was originally published on Tuesday Aug 17th 2010
Mobile Site | Full Site