370cb2d535
The control this file never had: a run with the Kernel channel on, analysed WHILE STILL FLYING, has 2738 refused resumes on one pair - more than the frozen run's 1171. The target's own lines show why. The game runs a self-suspending worker (NtSuspendThread on itself, a manager thread resumes it, thousands of times), and a self-suspended thread is not host-suspended, so the host Resume legitimately returns false EVERY cycle: 3115 refusals against 3115 resumes. The error is named rather than buried: the warning's commit says "~7 times in a normal boot" and this file generalised that from boot to gameplay, where the number is thousands. The 150x anomaly was an artefact of the baseline. The zero-CPU threads go with it - the healthy run has four of those too. What the instrumented reproduction DOES establish is sharper than the lead was. The last kernel event in 690000 lines is "Thread F8000204 self-suspending", with self-suspends 3116 against resumes 3115 - but the resumer never issues another NtResumeThread at all, so nothing was dropped in flight; every thread stopped together. And the guest is SPINNING, not deadlocked: over 10 s while frozen the main thread is in state R gaining 409 ticks and guest threads gain ~680 in total while making not one kernel call. So it is guest code waiting on something in guest memory, and the next question is which guest PC. Two corrections fall out: "the log stopped growing" is not a freeze detector (it goes quiet for 25 s in normal flight), and 0xbdb59668 held the counter again - 4 of 6 runs now. freeze_report.py makes the analysis repeatable, and refuses to answer "did this thread ever run" when the Kernel channel was off rather than reporting a false NO. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
3.7 KiB
Executable File
3.7 KiB
Executable File