As mentioned in an earlier post, we will be writing about all of the different breakpoint functionality available in Visual Studio.  In this first part, we discuss the hit count breakpoint.  If you wish to follow along, the code samples below are available for download.

## Sample Problem

Consider the following method that applies a basic shift cipher to a string. A shift cipher (or Caesar cipher) simply shift the letters of a message by a fixed amount.

We have a breakpoint set on the return statement of the method. Now let’s see what happens when we run the following code:

When we are stopped at the breakpoint, we inspect shiftArray and see that we have a problem.

While the rest of the encoded message does not make it obvious that there is a problem, we can see that we have ‘{‘ in the 35th position, which is obviously wrong. We suspect that the problem is in the loop that is encoding each letter, but we really want to examine the 36th iteration of the loop. If we just set a breakpoint in the loop, we would have to sit there and continue it 35 times before we can really get down to debugging. This is where using hit count breakpoints comes in handy.

## Creating the Hit Count Breakpoint

To create the hit count breakpoint, first start by simply creating a regular breakpoint in the loop you want to examine.

Then right click on the breakpoint to bring up the context menu.

And click on “Hit Count…” to bring up the Hit Count configuration dialog.

Now change the setting in the dropdown from “break always” to “break when the hit count is equal to” and then enter 36 as the hit value.

After you click “OK” you’ll notice that the breakpoint now has a ‘+’ inside indicating that this is an advanced breakpoint.

Now when I start the application under the debugger, I stop right where the code is changing the value of shiftArray[35].

And as I step through, I can see the problem. First the letter is shifted off the end of the alphabet.

But then when I step again, I can see that it skips the code that is supposed to push the letter back into the alphabet range.

Now I have found my problem. The condition should be shiftArray[i] >= 123 instead of shiftArray[i] > 123. And I found this more quickly than I would otherwise by using a hit count breakpoint.

Hit Count breakpoints can also be used when you need to skip ahead in the execution of your code, but you don’t quite know exactly how far ahead you want to go.

Consider the following recursive function that calculated the greatest common divisor (GCD) of two numbers.

As a developer, you may want to debug through this function in order to see the intermediate values during the GCD calculation. Given two large numbers, you know that this function is likely to run for a long time, but you don’t know quite how long. In this case you can use hit count breakpoints to save you some time.

As before, you can bring up the hit count dialog by right-clicking on the breakpoint and selecting “Hit Count…”

This time, select the “break when the hit count is greater than or equal to option” and enter a value of 10.

This will allow you to skip through the first 10 calls to the function to get closer. Now consider calling the function with the following two integers,

Running to the breakpoint gets me down to small numbers for x and y so that I can follow the rest of the calculation.

And if I continue the application, the application will continue to stop at the breakpoint each subsequent time it hits it.

If I bring up the breakpoint hit count dialog again, you can see that I can view the current hit count for the breakpoint.

I can even click the reset button to avoid stopping on the breakpoint for another 10 iterations.

## Counting Iterations

Finally, hit count breakpoints can also be used simply to count the number of times the breakpoint is hit. Let’s say we wanted to count the number of iterations in our GCD example. As a before, you want to create a hit count breakpoint and select the option “break when the hit count is greater than or equal to”. This time, instead of choosing a number to break on, instead choose an arbitrarily large number like 99999.

With a number this large, the breakpoint will never be hit. Now set another breakpoint somewhere after all of the iterations of GCD will already be complete. When you stop at this breakpoint, you can see the hit count in the Breakpoints window (available from the Debug -> Windows menu).

So you know that the program went through the GCD function 14 times.