When you ask the debugger to set a read or write breakpoint, the breakpoint fires only if the address is read from or written to by the address you specify. If the memory is mapped to another address and modified at that other address, then your breakpoint won’t see it.

For example, if you have multiple views on the same data, then modifications to that data via alternate addresses will not trigger the breakpoint.

The hardware breakpoint status is part of the processor context, which is maintained on a per-thread basis. Each thread maintains its own virtualized hardware breakpoint status. You don’t notice this in practice because debuggers are kind enough to replicate the breakpoint state across all threads in a process so that the breakpoint fires regardless of which thread triggers it. But that replication typically doesn’t extend beyond the process you’re debugging; the debugger doesn’t bother replicating your breakpoints into other processes! This means that if you set a write breakpoint on a block of shared memory, and the write occurs in some other process, your breakpoint won’t fire since it’s not your process that wrote to it.

When you call into kernel mode, there is another context switch, this time between user mode and kernel mode, and the kernel mode context of course doesn’t have your data breakpoint. Which is a good thing, because if that data breakpoint fired in kernel mode, how is your user-mode debugger expected to be able to make any sense of it? The breakpoint fired when executing code that user mode doesn’t have permission to access, and it may have fired while the kernel mode code owned an important critical section or spinlock, a critical section the debugger itself may very well need. Imagine if the memory were accessed by the keyboard driver. Oops, now your keyboard processing has been suspended. Even worse, what if the memory were accessed by a hardware interrupt handler? Hardware interrupt handlers can’t even access paged memory, much less allow user-mode code to run.

This “program being debugged takes a lock that the debugger itself needs” issue isn’t usually a problem when a user-mode debugger debugs a user-mode process, because the locks held by a user-mode process typically affect only that process. If a process takes a critical section, sure that may deadlock the process, but the debugger is not part of the process, so it doesn’t care.

Of course, the “debugger is its own world” principle falls apart if the debugger is foolish enough to require a lock that the program being debugged also uses. Debugger authors therefore must be careful to avoid these sorts of cross-process dependencies. (News flash: Writing a debugger is hard.) You can still run into trouble if the program being debugged has done something with global consequences like create a fullscreen topmost window (thereby covering the debugger) or installed a global keyboard hook (thereby interfering with typing). If you’ve tried debugging a system service, you may have run into this sort of cross-process deadlock. For example, if you debug the service that is responsible for the networking client, and the debugger tries to access the network (for example, to load symbols), you’ve created a deadlock since the debugger needs to access the network, which it can’t do because the networking service is stopped in the debugger.

Hardware debugging breakpoints are a very convenient tool for chasing down bugs, but you have to understand their limitations.

Additional reading: Data breakpoint oddities.