DBX vs. Visual Studio and WinDbg: Part 2D, Conditional Breakpoints

This is where we are through the series:

• Calling a function
• Configuring breakpoints
  • Setting multiple breakpoints at once
  • Memory access breakpoints
  • Memory access breakpoints, revisited
  • Conditional breakpoints [this post]
• Tracing execution
• Execution control
• Displaying data, including STL collections
• Runtime application checking
• Miscellaneous commands

Today’s post is about configuring conditional breakpoints. Finally, this is one area where the Windows tools have feature parity with DBX, at least as far as the basic feature goes.

A conditional breakpoint is a breakpoint that is associated with a condition. If the condition is true, the debugger stops at the breakpoint; otherwise, it continues execution. The important question, then, is what kinds and shapes of conditional breakpoints are available, and how the expression evaluator copes with complex conditional expressions.

DBX
DBX makes it rather easy to specify a conditional breakpoint. Append –if at the end of any stop command and you have yourself a condition that applies to anything in the scope of the breakpoint. For example:

stopped in main at line 15 in file "stl.cc"
   15     global = 1;
(dbx) stop at 22 -if v.size() == 2
(7) stop at "stl.cc":22 -if v.size() == 2
(dbx) cont
stopped in main at line 22 in file "stl.cc"
   22     m[5] = v;
(dbx) status
(6) stop infunction main
*(7) stop at "stl.cc":22 -if v.size() == 2 

Visual Studio
Visual Studio has conditional breakpoint support—when a breakpoint is set, you can specify a condition that must be true for the debugger to stop. Unfortunately, these conditions are subject to even more stringent limitations than the expressions you can input in the Immediate Window. The trivial things, such as paramName > 13, still work, of course.

WinDbg
WinDbg circumvents the problem altogether by providing the ability to execute an arbitrary debugger command when a breakpoint is hit. Among the things that this debugger command may do is continue execution using the gc command; alternatively, it could display some output, stop, etc.

We have seen before an example of WinDbg’s conditional breakpoint support for implementing the stop inobject DBX command equivalent; I will not be repeating another example here.