f9e6209308
The 1663 refused resumes on thread F80001D8 looked like a second lost resume of the kind fixed earlier today. They are not. That thread DID execute - the log carries its XThread::Execute line, guest entry 82FFE6C0 - and then 137000 lines of silence. The silence proves nothing: KeWaitForSingleObject and NtWaitForSingleObjectEx are declared kBlocking, kHighFrequency, and PrintKernelCall skips every kHighFrequency export unless --log_high_frequency_kernel_calls=true, which defaults to false. A thread parked in a wait is invisible in these logs. So the boring reading is the right one: the guest kicks a worker that is blocked ON AN OBJECT, and Resume returns false because the thread is not SUSPENDED. That is what a refused resume means, exactly as suspected before the count made it look interesting. Method note kept in the doc, because it is the reason one conclusion survives and the other does not: the title-loader finding rested on 00:00:00 host CPU time from ps -L and on the fix changing behaviour 5/5 against 1/5 - not on log silence. In this codebase log silence alone is never sufficient evidence that a thread is idle. Also records a grep error of mine that briefly produced "zero kernel calls, ever": the pattern ^[dikwF!]> missed the K> kernel prefix. Caught before it was written down, and it changed the conclusion.