Trace Writes

Read the breakpoint log:

probe_breakpoint_log id=<bp_id>

Each hit gives you a full register snapshot: RIP (the instruction that accessed the address), RAX-R15, RSP, RFLAGS.

If the breakpoint doesn't fire

• The value might be written by a different thread — hardware BPs work across all threads, so this is unlikely. More likely the value is written once during initialization and you missed it.
• The value might be computed, not stored — the address might be read from somewhere else and cached. Try watching the source address instead.
• The write might happen via DMA or kernel mode — hardware breakpoints only catch usermode access. If you suspect kernel writes, this approach won't work.
• Try polling instead: probe_watch address=<addr> size=4 interval_ms=100 to catch when the value changes, then narrow down the timing.

Common patterns you'll see

Direct field write:

mov [rcx+0x354], eax    ; rcx = object pointer, 0x354 = field offset, eax = new value

This tells you: the function receives the object in RCX, and offset 0x354 is the field.

Indirect write via pointer chain:

mov rax, [rcx+0x30]     ; load sub-object pointer
mov [rax+0x10], edx     ; write to sub-object field

This tells you: the struct has a pointer at +0x30 to a sub-struct, and the actual field is at +0x10 in the sub-struct.

Atomic/interlocked write:

lock xchg [rcx+0x40], eax   ; thread-safe write

This means the field is accessed from multiple threads — important to know for reading it safely.