5fb4da4c43
v2 counts every KeWaitForSingleObject call per thread per second, tracks how many distinct objects it saw, and logs the last result. Its HEALTHY baseline is a result on its own: over a full 22-minute run the main thread cleared 500 calls/s in 224 separate windows, peaking at 1235 calls/s over up to THIRTEEN distinct objects, and the last result was X_STATUS_SUCCESS in all 314 windows. Not one timeout. So the game normally does hundreds of successful waits a second across many objects - exactly the blind spot v1 could not see, and the reason a timeout-streak counter reported the same single poller whether the game was frozen or healthy. Stated as a consequence rather than a triumph: 500/s is NOT self-selecting, since the main thread clears it constantly, so the freeze signal has to be a different shape - a thread far above 1235/s, a new thread, or a window whose result is not SUCCESS. That still needs a frozen sample; run 5 ended in GAME OVER at ~22 min without freezing. freeze_watch.sh now summarises the rate probe per thread when it captures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE