ab8a0d9e6d
The crash PC from the previous iteration resolves, and it names itself: sub_823070B0 references the string 'invalid map/set<T> iterator', builds it with the string helpers and throws it — which is the guest C++ exception (E06D7363) Xenia reports one line earlier. Its node offsets are MSVC's red-black tree node exactly (_Left 0, _Parent 4, _Right 8, _Color 24, _Isnil 25), so this is a std::map/set erase, and the fault is the first dereference after the iterator check. That matters beyond this blocker. The canary handoff's Ready-Room crash is the same shape — a guest STL exception in a cache/save path — and its bisection plan is priced at "one build plus one Ready-Room run" per suspect. If it is the same defect, each suspect now costs 40 seconds, and suspect #1 is already measured: --mem_watch=false removes it. Stated as unresolved rather than guessed: the fault address 0x1_0000000C is a 32-bit value with bit 32 set, which fits BOTH a corrupt guest tree and a stale high word on the emulator side. The measurement that separates them (read the node from guest memory at the throw) is written down rather than assumed. The second, unreproduced crash PC is identified too: an unrolled 4x16-bit copy loop faulting on the STORE, i.e. a bad destination — a different failure.