One of the challenges with debugging applications with multiple threads in Visual Studio is that when you place a breakpoint you tend to interrupt the flow of the application. This can often mean that tracking down an issue is very time consuming. Let’s take a very simple example where we have a thread that performs a task then sleeps for 100 milliseconds.
private void ThreadWork()
{
for (int i = 0; i < 100000; i++)
{
DoWork();
System.Threading.Thread.Sleep(100);
}
}
Now say that something is going wrong on this thread, the first thing we can do is to place a normal breakpoint:
Here we can see a regular breakpoint that has been hit and notice that you can hover over variables to see what their current values are. But what happens if the error only happens after say 1000 iterations. We can use a breakpoint hit count to limit when the breakpoint is hit. Right clicking the line with the breakpoint you can set the Hit Count property via the Breakpoint –> Hit Count… menu item.
In this case we want the breakpoint to be hit after 1000 cycles:
Note that setting the Hit Count sets up a rule where by the breakpoint will be hit based on the number of times the line has been executed. If the loop was instead modified to the following the breakpoint would be hit after 1000 * 100 iterations of the for loop, rather than the 1000 iterations we wanted.
for (int i = 0; i < 100000; i++)
{
if (i % 100 == 0)
{
DoWork();
}
System.Threading.Thread.Sleep(100);
}
To get around this we can use a breakpoint Condition. Again this can be set using the Breakpoint –> Condition menu item from the right-click menu.
In this case every time the breakpoint line is reached the expression i>=1000 will be evaluated and the result used to determine if the breakpoint has been reached. Note that this expression can be as complex as you would like but it does add an overhead to execution. If timing is important then you should make this expression as simple as possible.
If you have specified either a Hit Count or a Condition you will see that the marking alongside your code has changed slightly. Instead of the normal red dot, you should now see a red dot with a white plus sign inside it.
One thing to be aware of is that Hit Count and Conditions are not mutually exclusive which means that you have have both of them set. As they use the same breakpoint marking it’s not that easy to see if they have both been set. However if you right-click the breakpoint line you will see that the menu actually indicates which items have been set.
Unfortunately the process of actually stopping the execution of your application at a breakpoint often has the side effect of hiding or obscuring the issue you are trying to track down. Luckily there is a way that you can write an output to the output window and continue execution. From the right-click menu select the Breakpoint –> When Hit… item.
This dialog allows you to either specify an output to be written to the output window or to run a macro. You can also toggle whether execution continues or breaks when the breakpoint is hit.
In this screen shot the output consists of a number of parts. Essentially the output is just a string literal that will be printed to the output window. However, $FUNCTION is a predefined value corresponding to the current function name which will be substituted into the output. The dialog points out that there are a number of other predefined values that can be used. Quite often you will want to put your own custom values in there – this is where the { <expression> } syntax is used. In this case we have chosen just to output the value of the variable i, but we could make this expression more complex so long as it can be converted to a string. Again the more complex this expression is the more it will affect your application.
Now when your breakpoint is encountered by your application it will no longer break, it will simply write a string to the output window. This can help you track down issues on background threads without affecting your application execution significantly.
