a65649598e
The canary branch already carries log_stuck_waits, written for this exact question: it names the object a guest thread keeps timing out on, and is silent on a healthy run because a wait that gets satisfied never builds a streak. Enabled it and ran to the freeze on the stock build. Not one stuck-wait line, alongside the usual AllocRange failure and guest throw. So no guest thread is parked on a kernel object that never gets signalled; combined with 389% CPU across running threads, the guest is spinning in its own code -- which is what the throw-that-returns predicts, since execution resumes after the throw and runs into code that assumed it would not. Operational note worth having: --log_stuck_waits=true on the command line is ACCEPTED but the config file value wins, and the first run silently logged "log_stuck_waits = false" while I thought it was on. The startup dump prints the effective value -- check the dump, not the flag. The flag is cheap and silent so it is now left enabled in the container config.