# 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`](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`](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`](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 cache flush, and it is not what it looked like.**
With the default `--mem_watch=true`, in two runs, the guest died with an access
violation at PC `0x82307128` right after `RtlRaiseException(E06D7363)`. Chasing
that produced a correction and a cheap trigger, both in
[`title-crash-stl-tree.md`](title-crash-stl-tree.md):

* the access violation is a **consequence** of the guest's own `throw` returning
  (this build does not unwind guest EH), so the event to study is the throw;
* the throw is `std::out_of_range` from the game's **cache-manager flush**, and
  an **incomplete on-disc cache** triggers it ~100 s into a boot;
* the observation that started this — "crash with `--mem_watch=true`, none with
  `--mem_watch=false`" — was **confounded** by cache warmth, and is withdrawn:
  cold cache with the probe off throws just the same.

**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`](title-crash-stl-tree.md).

**Next step, for whoever picks this up.** What is left:

1. 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_0000000C` is consistent with either;
2. 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.