402ee1dce4
The backlog has said a second capital-ship capture needs the 0x82307128 crash dealt with first, because the run died at SELECT DATA before any mission existed. That is no longer where it stops. With the Canary threading fix making the menu dependable, tutorial_launch.sh drives boot -> title -> menu -> TUTORIAL and the mission LOADS AND RENDERS: flight HUD, "Go to the box on your screen", warship counters, controller diagram. It then freezes. 13243 crash dumps, every one at PC 0x82307128, guest thread 9, Access Violation read at 0x10000000C, preceded by exactly ONE RtlRaiseException(E06D7363) right after a HostPathDevice::ResolvePath() with empty arguments - the cache-flush shape. Two screenshots 6s apart are identical (RMSE 0), no new dumps accumulate, and the process still burns 400% CPU. So: reachable, renders, unusable for a capture. The blocker moved rather than lifted, which is worth recording precisely because the entry's stated reason is now wrong. One new lead, deliberately not claimed as a cause: the resume-refused diagnostic added with the threading fix fires 1671 times on this path and 1663 of them are the SAME thread, F80001D8, with 152 before the first crash - against about 7 on the menu path. Resuming a non-suspended thread legitimately returns false and "Resume to kick a worker" would produce exactly this, so it is a lead, not a bug. It is cheap to settle: check whether that thread makes kernel calls between refusals. Cheapest next test named: this page already shows a COMPLETE on-disc cache produces no throw at all, and the cache is 40MB with .partial/.cold-rebuilt leftovers beside it. One boot to warm, one to re-test.