Compartilhar via

Data Breakpoints

  • Artigo

Usually, people put breakpoints on an instruction. These breakpoints are set by replacing the first byte of an instruction with the ‘int 3’ instruction (0xcc). When the processor executes the ‘int 3’ instruction, it causes the OS to generate STATUS_BREAKPOINT exception, and your program stops.

There is another type of breakpoint that the debugger can also set for you – a data breakpoint. Data breakpoints fire when data is changed. To set one, go to Debug->New Breakpoint, then switch to the ‘Data’ tab.

There are really two types of data breakpoints that the native debugger supports – hardware data breakpoints, and emulated data breakpoints. Hardware data breakpoints are the useful ones. They are implemented with the debug registers of the processor. Unlike emulated breakpoints, these are fast and reliable. On the downside, the processor doesn’t have many of them. Also, all data breakpoints (including hardware breakpoints) won’t fire when the memory is written from kernel mode. With emulated breakpoints, the debugger uses instruction breakpoints to try and break when a variable is changed. However, this is a very challenging operation, and doesn’t always work. This also slows down the execution of your program, sometimes dramatically. Because of the problems with emulated breakpoints, this feature is likely going to be removed in a future product. One thing we would like to do is expose all the breakpoint register features of the processor. This would let you set a breakpoint on data read, write and execute instead of just write.

Now that you know the difference between a hardware and emulated breakpoint, here is how you set a hardware breakpoint:

  1. Determine what address you want to watch
  2. Open the new breakpoint dialog, and switch to the data tab
  3. Enter the address that you want to watch in the variable column
  4. The context is ignored. You can clear this if you want.
  5. Set the item count. If you are using an address, this should be the number of bytes (example: 4 for a DWORD)

One downside to data breakpoints are that they are only supported for native debugging. Maybe sometime they will work for managed. In some ways, this is a much harder feature for managed because the GC moves objects around in memory. I think data breakpoints are probably far less important for managed code since there is no heap corruption, and properties allow setting a breakpoint on the set function instead.

Comments

  • Anonymous
    April 30, 2004
    The comment has been removed

  • Anonymous
    April 30, 2004
    I'll throw my voice in (and I know a lot of other MVPs agree) on that data breakpoints would be extremely useful for managed code. That was one feature I looked for when I got Whibey.

  • Anonymous
    April 30, 2004
    The comment has been removed

  • Anonymous
    April 30, 2004
    On my web site, at http://www.morearty.com/code/breakpoint">http://www.morearty.com/code/breakpoint , I have a helper class, CBreakpoint, that makes it easier to deal with hardware breakpoints. It gives you access, at compile time, to the Intel CPU's hardware breakpoint registers.

    The way it works is, after your code sets breakpoint, if you happen to hit that breakpoint, Visual Studio will stop. Visual Studio might actually be a little puzzled at this point -- it got an EXCEPTION_SINGLE_STEP from the OS, but isn't sure why -- but nonetheless it does the right thing, luckily.

    The nice things about this approach are:

    1. It avoids the issues with Visual Studio's emulated breakpoints. In Visual Studio, if you try to set a hardware breakpoint on a local variable, you're probably going to get an emulated one. With this class, it's easy to get the real thing.

    2. Your breakpoint will automatically be removed when your instance of CBreakpoint goes out of scope. (If you want it to stick around, make your CBreakpoint instance a global, or a static local.)

    3. Makes it easier to specify exactly what you want your hardware breakpoint to be watching. In Visual Studio it can sometimes be a little hard to tell if you're setting it at the right place. E.g. if you have "char* p", and you set a hardware breakpoint on "p", are you setting it on the address of p, or the address of the char to which it points? Hard to tell. Also, it can be hard to tell how many bytes you are watching (in the above example, are you watching four bytes or one byte?).

    See http://www.morearty.com/code/breakpoint">http://www.morearty.com/code/breakpoint for source.

    P.S. I worked as a developer on the Visual Studio debugger in the early-to-mid 90s. Hello up there!

  • Anonymous
    August 05, 2004
    I wouldn't say that cdb/ntsd is a better tool for debugging much of anything. If you need a data breakpoint on an address, there is nothing stopping you from using Visual Studio to native-only debug your managed or mixed code.

  • Anonymous
    March 19, 2008
    PingBack from http://desktopcomputerreviewsblog.info/greggms-weblog-data-breakpoints/

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/676255-visual-c-2005-how-can