Data Breakpoints

The VS debugger allows two types of breakpoints. There are location breakpoints and data breakpoints.  Each has lots of bells and whistles.  However, sometimes people confuse a Location bp with a condition, for a data bp.  That's unfortunate because a data bp solves a different problem.

A data breakpoint involves telling the debugger to stop when the value at an address changes.  Use a data bp when you know some data is getting changed and you want to know where in the instruction stream that is happening.

A location breakpoint with a condition triggers a stop when the instruction pointer reaches the proper address.  After the stop we then evaluate the condition to determine if we should continue automatically or notify you that the breakpoint hit.  Use a condition when the underlying breakpoint gets hit too often and you want to constrain it to certain circumstances.

Data bps are implemented with a hardware register on the cpu.  In VS Whidbey, we allow Data bps for native code.  We restrict the number of them to the number of available hardware registers that support data bps.  Though the hardware supports read based data bps, in VS we only implement stopping when the value is written.   Managed code does not have Data Bps.  Mike Stall has a blog topic asking for votes on potential feature requests.  Data breakpoints are on that list.

In Whidbey, to set a data bp, open the breakpoint window (Debug/Windows/Breakpoints).  Hit the 'New' menu button, and pick 'New Data Breakpoint'.  The dialog has specific suggestions on what to enter.  I suggest entering it as a hex address.  Regardless of what you enter, the line in the Breakpoints window will show a hex address. Make sure it points to the data you are interested in.  If you try to create more than four data bps you will get a dialog saying the maximum number of data breakpoints have already been set.

This UI metaphor is primitive compared to what we had in the past.  Why did it change to something that seems inferior?  In past versions you could enter an arbitrary expression.  We would figure out what needed to be watched and stop when the value of that expression changed.  This is awesome except in the vast majority of cases where it would trigger something called 'Emulation'.  Someone using data bps would find it difficult to figure out when emulation would get triggered, and believe me it was something to avoid.  Emulation is where we cannot provide the Data bp using a register.  Instead we single step and check the value at the end of each step.  This is slow.  Not just slow, incredibly slow.  Go walk the dog, get a cup of coffee, read the newspaper slow.   There are a few tricks we could have done to keep the old UI and avoid emulation, but they fall down in certain cases.  We didn't want to have data bps, and 'sort of data bps'.  Instead, we made a decision to expose what really works in a simpler manner.  That avoids the trap of accidentally falling into 'emulation'.

At the beginning I mentioned that people sometimes confuse the bells and whistles with the type of breakpoint.  The bells and whistles apply to both kinds of underlying bps.  Each of those bells and whistles is (10 cent word warning) Orthogonal.  You can add a condition to a data bp, or add a hit count, or make a data bp into a data bp tracepoint with 'When hit'.  All of these are accessible via a right click in the breakpoint window.  Composing those bells and whistles can provide powerful debugging techniques.  Just make sure you are using the right kind of underlying bp.