Good ol’ Daniel LeCheminant has a solid answer on what a data breakpoint does, so i’ll toss in some anecdotes that highlight useful uses:
Any scenario where you know what will change, but have little or no idea where the code changing it lives (since otherwise you could simply use a conditional breakpoint). Specifically,
“Impossible” scenarios – program is crashing, because variable X is NULL, when variable X should never be NULL because no code anywhere ever sets variable X to NULL. Put a normal breakpoint in the code that initializes X, and when it is hit, set up a data breakpoint to watch for the change to NULL. Somewhat more common is the case where memory is released too early, and there are still pointers to it hanging around: use data breakpoints to find out who’s releasing the memory.
Tedious scenarios – a 3rd-party library is doing bad, nasty, horrible things to your data structures. You know it’s happening, because someone is trashing your data and obviously your code is perfect. But you don’t know where, or when. Sure, you could single-step through a megabyte of disassembled DLL… but why bother, when you can set a data breakpoint on your data, sit back, and wait for it to get trashed!
Heisenbugs – similar to the impossible scenario, but they go away when you watch too closely, such that normal breakpoints – even conditional breakpoints – are useless. Timing and user-input sensitive logic is particularly vulnerable to this sort of thing. Since data breakpoints don’t require the debugger to actually break at all until the time is right, assuming you can come up with a memory location that will only change when that elusive bug actually occurs you can use data breakpoints to set a trap for the Heisenbug and catch it in flagrante delicto.
Spaghetti scenarios – common in old, rotten code bases where global data is accessed everywhere. Yeah, you could use plain ol’ conditional breakpoints… but you’d need hundreds of them. Data breakpoints make it easy.