Filter Breakpoints

Filter Breakpoints

  • Comments 2

This blog post is part of a series on breakpoints in the Visual Studio debugger.  The code used in the examples below is available to download.

Filter breakpoints can be extremely helpful when your application is running the same method many times in parallel. Consider the example where we are calling FindPrime() 4 times in parallel. You’ll notice that FindPrime() calls IsPrime() several times. To illustrate this problem, let’s see what happens when we set a conventional breakpoint in IsPrime(). At first we hit the breakpoint in this function as expected.

clip_image001

But that as we start to step through the function, we notice some strange behavior.

clip_image001[1]

clip_image002

clip_image003

clip_image004

clip_image005

clip_image006

We seem to just be jumping around. This is because different threads are hitting the same breakpoint while you are stepping. Then the debugger is also stopping when each step is completing. The order of these events is not deterministic so it will likely be different the next time you debug.

Using a filter breakpoint, you can instead just focus on a single thread. To create the filter breakpoint, right-click on the breakpoint and select Filter.

clip_image007

This will bring up the Breakpoint Filter dialog. You’ll notice in this dialog that there are 5 different ways to filter the breakpoint: MachineName, ProcessId, ProcessName, ThreadId, and ThreadName.

clip_image008

Since we want to focus on a single thread that is running through IsPrime(), we will filter on ThreadId. If you had code running in parallel across different processes or machines, you could use this same technique using those filters as well.

First we must figure out which thread we want to stop on. To do this, we will set a conventional breakpoint on FindPrime(). When we stop at this breakpoint, we can use the Threads window to see the ID of our thread is 11816.

clip_image010

Now we can go back to our breakpoint on IsPrime and setup the filter.

clip_image011

And then we can see that stepping through the function behaves as we would expect.

clip_image012

clip_image013

clip_image014

clip_image015

One disadvantage to this approach is that you need to find the Thread ID each time you run the application. To avoid this, you can instead name your threads.

clip_image016

And then apply the filter to the name instead as this will not change between debug sessions.

clip_image017

The caveat here is that this may not work if you are using tasks or thread pool threads as threads can only be named once.

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Would be great there was a short cut to scope this breakpoint to current thread, and that would last only for the current debugging session.

  • @Stephen – Thanks for the great suggestion, I completely agree.  Please feel free to add a suggestion on the Visual Studio UserVoice site at visualstudio.uservoice.com

Page 1 of 1 (2 items)