3ecb3432f1
The fourth run froze 9 seconds into the watcher's window, in flight, and the probe built for that moment showed the healthy-run baseline and nothing else: one pair, the same poller on the same object VA as every healthy run, only the thread handle differing. No new (thread, object) pair appeared. So the hypothesis the probe was built to catch is refuted - the freeze is not a guest thread looping on KeWaitForSingleObject timeouts against ONE object - while the CPU signature is unchanged from the gdb run: 1255 ticks over 10 s, 401 in the TimerQueue thread and 292/280 in two guest threads. What survives is stated as two specific blind spots of the instrument rather than a shrug: the waits may cycle over DIFFERENT objects, which resets the streak and makes them invisible to a same-object counter; or they may SUCCEED rather than time out, which leaves a timeout counter nothing to count and would fit the kernel-log evidence of a self-suspending worker cycling thousands of times successfully. Next is a v2 that counts calls per thread per second regardless of object or result. The freeze lottery paid out on the first attempt this time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE