GetThreadContext can fail on a target that was just suspended. A raise
used to throw "cannot read the target thread context" at the first
failure; it now resumes the target and tries again, within the existing
1 s retry limit, before throwing. SONIC SUPERSTARS hit the throw once in
three runs. guest_raise_in_host_code prints the longest single raise.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
GetModuleHandleExW and GetModuleFileNameW take loader locks the suspended
target may hold. While the target is suspended only VirtualQuery and a
lock-free cache of image bases are consulted; an image not yet cached is
classified after the target is resumed, and the target is sampled again.
The statics the checks use are initialized before the first suspend. The
host-code wait is recorded in the libkernel debt file, and the test raises
100 times so it fails on every run without the change.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On Windows, sceKernelRaiseException suspends the target and redirects it to
the guest handler wherever it stopped, except inside NtContinue or
winpthreads. A target stopped inside host code (a C runtime call, a host
library) can hold a host lock there; a handler that then waits, as a
collector's thread-stop handler does, keeps it held, and every host thread
that needs the lock stops with it. SONIC SUPERSTARS stopped at frame 65 this
way: its "UDS" thread was redirected inside the stderr write of a trophy
message and parked in sceKernelWaitEventFlag holding the stream lock, and the
driver's logging threads blocked on it.
A target running code of a module other than the executable or a guest
module is now resumed and suspended again until it is back in guest code,
for up to the existing retry limit; a target blocked in an ntdll wait is
still redirected there, as before.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
