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.
7.3 KiB
Getting past the title screen in the container — three traps and one blocker
Status: ✅ CONFIRMED for the three traps (each reproduced, and two of them
fixed in the toolkit). 🔴 blocked on reaching the main menu: the guest reads
Ⓐ at the title, and the step behind Ⓐ either crashes it or stalls it.
Written down because each of these presents as "the pad is dead" or "the game ignores input", and each has a completely different cause.
1. F10 opens the emulator's menu bar, and that swallows every guest keystroke
F10 is the RE hotkey (ship capture, and now log_ui_draws). It is also the
toolkit key that opens the application menu bar, and it does both. With that menu
open, XamState::IsUIActive() is true, so XamInputGetKeystrokeEx returns
X_ERROR_SUCCESS with a zeroed keystroke before the driver is ever asked
(xam_input.cc). The guest polls, gets an empty event, and does nothing —
forever, and with no error anywhere.
This cost most of an iteration. Symptom: a run presses F10 to arm a capture,
then every later Ⓐ does nothing; the title sits there while the pad log happily
prints [file-pad] keystroke vk=5800 down. Screenshot
captures/title-with-emulator-menu-open.png
shows the giveaway — Open… / Open Recent / Install Content… / Exit over the
title art. It is easy to miss because the menu is at the far left of the window
and the game is still animating behind it.
Fix: after any F10, click once on the game surface to dismiss the menu.
Escape does not close it. ui_draw_capture.sh now does this.
2. The pad is fine — the driver was never the problem
Worth stating because the file-pad's own history (--hid=file, GetKeystroke
implemented specifically so "PRESS Ⓐ BUTTON" would work) makes it the natural
suspect. It delivers: the log shows vk=5800 down/up per tap, and Ⓐ during a
movie skips the movie, every time. When the title ignores Ⓐ, the pad is not why.
3. Ⓐ at the title needs a signed-in profile — and this container cannot type one in
With no profile, Ⓐ is handled: the guest calls XamShowSigninUI and Xenia
pops its Sign In dialog (captures/title-signin-dialog.png),
ProfileManager: Found 0 Profiles. That dialog is the proof the guest reads the
button.
The dialog cannot be completed from here: "Create Profile" opens an ImGui text
field for a gamertag, and synthetic X key events do not reach it. Tried, all
with the window focused (xdotool getwindowfocus = the game window):
xdotool type --window, xdotool type via XTEST, single xdotool key presses,
clicking the field first. The field stays empty; Create with an empty gamertag
is refused. Mouse clicks do work (they opened the dialog and the sub-panel), so
it is text entry specifically.
Xenia's own Profile ▸ Show Profile Menu panel does have a working Create Profile button, and mouse clicks reach it — but the gamertag it then asks for is
the same ImGui field, so the UI route dead-ends in the same place.
Fix, landed in Canary (auto/re-ui-draw-order): a --create_profile_if_none=<gamertag>
cvar that calls ProfileManager::CreateProfile(tag, autologin, default_xuid) at
startup when no profile exists. default_xuid is fixed at B13EBABEBABEBABE, so
a script can then pass --logged_profile_slot_0_xuid=B13EBABEBABEBABE and be
deterministic. Verified: ProfileManager: RE bootstrap profile 'SylphRE' -> created, then on the next boot Found 1 Profiles / Loaded SylphRE (GUID: B13EBABEBABEBABE) to slot 0, and the Profiles Menu panel shows the user
(captures/xenia-profile-panel-signed-in.png).
The profile persists on disk, so later runs need only
--logged_profile_slot_0_xuid=B13EBABEBABEBABE.
The blocker: what happens after Ⓐ
With the profile created and signed in — Xenia's own Profile ▸ Show Profile
Menu confirms it, User: SylphRE / XUID: B13EBABEBABEBABE / Assigned to slot: 1
(the panel counts from 1; the log says slot 0) — Ⓐ at the title still does not
advance the screen. Measured across four boots, including one that was allowed
to play the whole intro untouched, with holds of 10 s and bursts of five taps.
What is not the explanation, each checked:
- the emulator menu bar being open (trap 1) — the grabs are clean;
- the pad (trap 2) — Ⓐ skips movies in the same runs;
- the profile being absent (trap 3) — it is present, signed in, and the Sign In dialog no longer appears;
- an ImGui window being open — but note this generalises trap 1: any Xenia UI
window makes
IsUIActive()true, the Profiles Menu included, so a panel left open silently disables the guest's input for as long as it is up.
One observation that did not reproduce, recorded rather than dropped. In the
run where the Profiles Menu had just been closed, a single Ⓐ crashed the
guest — PC 0x824578A0, guest thread 6, distinct from the boot-path crash
below. Two later attempts to reproduce it (open the panel, close it, press Ⓐ)
produced neither a crash nor a transition. So it is one data point that Ⓐ can
reach code the title does not otherwise run, and nothing more.
The reproducible crash is the boot-time content path. With the default
--mem_watch=true, in two independent runs, the guest dies with an access
violation reading 0x00000001_0000000C at PC 0x82307128 on guest thread 9,
right after HostPathDevice::ResolvePath(\aab216c3\5\c10eae6) and a
RtlRaiseException(E06D7363) (a C++ throw). Xenia pauses itself and stacks up
crash dialogs — 991 in one run. With --mem_watch=false that crash does not
happen at all.
That pairing — crash with the memory-probe thread on, none with it off, both in a
save/content path — matches the suspect ranked #1 in
xenia-canary/HANDOFF-crash-oracle-2026-07-16.md, whose crash was also a guest
C++ exception in a cache/save path. This is a second, far cheaper reproduction of
it: at the title screen, ~40 s from a cold boot, instead of in the Ready Room
after a mission.
The first of those next steps is done, and it moves the crash out of this
entry into its own: 0x82307128 is inside an MSVC std::map/set erase —
the function carries the string 'invalid map/set<T> iterator' and the node
offsets to prove it — which makes this a 40-second reproduction of the crash the
Canary handoff blames on the mem_watch probe. See
title-crash-stl-tree.md.
Next step, for whoever picks this up. What is left:
- dump the tree nodes from guest memory at the throw, to separate "the guest's
tree is corrupt" from "the emulator left a stale high word in a register" —
the fault address
0x1_0000000Cis consistent with either; - the content exports this title imports —
XamContentCreateEnumerator,XamContentGetDeviceState,XamUserReadProfileSettings— logged around the press, to see whether the guest is handed a bad enumerator or a device state it does not accept.\aab216c3\5\…is the content directory in question.
What this blocks: every dynamic experiment past the title — a second UI screen's paint order, the main menu, mission captures. Everything up to and including the title screen is unaffected, which is why the paint-order result above could still be measured.