Visual Studio behaves strangely while debugging with breakpoint conditions

A method I work with that is called tens of thousands of times started throwing exceptions recently. In most debugging circumstances I would set a breakpoint at the top of this method and run through until I reach the call I'm interested in with a parameter value that triggers the exception. In this case that would be impractical, so I tried setting a breakpoint with a condition that will only break when that parameter value appears. I created a breakpoint at the position indicated below and gave it a condition str == "OffendingValue".

class Foo
{
    // Bar() is called many, many times
    void Bar(string str)
    {
     try
     {
      // Breakpoint inserted here
      ...
     }
     catch (Exception ex)
     {
      ...
     }
    }
}

To my surprise, doing this caused Visual Studio and my application to stop functioning in Debug mode. My application started and output some simple logging messages but then stopped responding entirely. Thinking Visual Studio might just be performing a little slower due to the extra work it has to do to monitor the breakpoint condition, I stepped away from my desk for 15 mintues to give it some time to run. When I returned there was no change. I can reproduce the condition by deleting the breakpoint and recreating it with the same condition. Strangest of all, the Break All debugging command, which will usually break program execution on the statement that's currently execting whether it's a breakpoint or not, does nothing at all when I have this problematic breakpoint enabled.

Has anyone encountered similar behavior with Visual Studio breakpoint conditions? I am able to use Hit Count conditions without problem.

From stackoverflow

• I wonder if you are getting a stack overflow. Does VS track all the values for str or anything to do with each state of Bar? If so, the thousands of copies might add up.

  I wonder if you could eliminate the problem monitoring the value via a global variable instead, rather than one within the function.

• If you know what the offending value is, can you not just write a unit test for that method and debug it that way?

  If not, if you know the exception, you could set up your debugger to break when that exception is thrown. Go to Debug | Exceptions and check Thrown for the exception in question.

  Chris Stevens : This method comes way down the call stack in a long series of operations. I hadn't though of writing a unit test for this method in isolation but perhaps that's a good approach. A working conditional breakpoint would be easiest approach, which is why I'm so curious about why VS isn't working.

  Rob Prouse : I have also found problems with some of VS's debugging functions when they get hit too many times. I think that VS just gets behind doing the evaluations. Thus the workarounds ;)

• Anytime that I have tried to use conditional breakpoints in Visual Studio I've had the same problem. The debugger runs so slowly that it becomes useless. Instead I end up temporarily adding an if statement to the code and adding my breakpoint inside of that. This isn't as convenient, but the code executes at a normal pace and it does get the job done.

  class Foo
  {
      // Bar() is called many, many times
      void Bar(string str)
      {
          try
          {
  
        if(str == "condition")
        {
         int i = 0;   // Breakpoint inserted here
              }
              ...
          }
          catch (Exception ex)
          {
                  ...
          }
      }
  }
  

  Chris Stevens : This is a pretty good hack!