xenia-rs/audit-runs/audit-006/canary_export_queue.md

# Canary-Only Export Fix Queue (audit-006)

- Status: **PARTIAL CASCADE (2026-05-04, post-KRNBUG-IO-003). 7 → 3 canary-only exports.** `NtDeviceIoControlFile` real impl landed; the priv-11 query (`XexCheckExecutablePrivilege(0xB)`) and `XamTaskSchedule` now fire. **Reclassified (now firing on our side):** `KeResetEvent`, `ObCreateSymbolicLink`, `XamTaskCloseHandle`, `XamTaskSchedule`. **Bonus pickups:** `XeCryptSha`, `XeKeysConsolePrivateKeySign` (both 0→1 — were not on the canary-only list because they were already in `ours_exports` but unreached). **Still canary-only:** `ExTerminateThread`, `KeReleaseSemaphore`, `XamUserReadProfileSettings`. Worker thread spawn count unchanged at 19; handle 0x100c remains UNCREATED. See KRNBUG-IO-003 in `audit-findings.md` and `project_xenia_rs_io_003_ioctl_2026_05_04.md`.

- Prior status (now superseded): **SUPERSEDED by AUDIT-007 (2026-05-04). Real gate identified: `NtDeviceIoControlFile` (FsCtlCode=0x74004) is `stub_success` at `crates/xenia-kernel/src/exports.rs:90`. Game-side `sub_824ABD88:0x824abea8-ac` reads `[out_buf+8]` of the IOCTL response, finds zero (stub doesn't write OUT), assigns hardcoded `0xC0000034` (STATUS_OBJECT_NAME_NOT_FOUND); caller `sub_824A9710` exits at `0x824a9944` before priv-11. Tier 4 entries remain parked, classification unchanged (still REAL_BUT_UNREACHED), awaiting KRNBUG-IO-003. See `project_xenia_rs_audit_007_branch_probe_2026_05_04.md` for the runtime trace + decisive proof.**

- Prior status: **PARTIAL — KRNBUG-IO-002 landed, but predicted cascade did NOT fire (7 → 7). Tier 0 marked superseded; Tier 4 entries STILL parked. Re-audit needed to find the real upstream gate.**
- Pre-state: master HEAD `556a8c3`, exports diff captured 2026-05-04
- Post-IO-002 state: branch `xboxkrnl-vol-allocunit/p0-65536-cluster`, fresh 500 M trace at `audit-runs/post-IO-002/`. Canary-only kernel exports remain identical: `{ExTerminateThread, KeReleaseSemaphore, KeResetEvent, ObCreateSymbolicLink, XamTaskCloseHandle, XamTaskSchedule, XamUserReadProfileSettings}`.
- Inputs:
  - `canary.log` (348720 B, identical to audit-005 oracle, canary build `9467c77f0`)
  - `ours.log` (692 MB, 5.6 M trace lines, run at 17:20–17:21 today, post-IO-001)
- Tooling: `diff.py` + plain `comm -23` set-difference on extracted call names

## Headline finding

**7/7 canary-only entries classify as REAL_BUT_UNREACHED or STUB_BUT_UNREACHED.**
Per the audit-006 spec stop condition ("if two-thirds of entries are
REAL_BUT_UNREACHED, the problem isn't stubs — it's an upstream gate"),
the next session should **NOT** pull a Tier-1 entry from this queue.
Instead, it should fix the gate.

The gate is **KRNBUG-IO-002**: our `nt_query_volume_information_file`
class-3 (FileFsSizeInformation) returns alloc_unit = 1 × 2048 = 2048,
but Sylpheed's `main(1, 0x10000, 0xFF000)` expects alloc_unit = 65536
(see `project_xenia_rs_io_nullfile_2026_05_04.md`).
Sylpheed's verifier `sub_824ABA98` rejects 2048, propagates failure to
`sub_824A9710`, which exits early before its `XexCheckExecutablePrivilege(0xB)`
call site. Canary fires the priv-11 query *and* the entire downstream
cluster (`XamTaskSchedule` → Cache0 callback thread → 0x100c worker spawn
→ display-init pump → profile-settings cascade); we fire none of it.

Direct evidence (telemetry):
- Our `XexCheckExecutablePrivilege` count = **1** (priv=0xA only).
  Canary count = **2** (priv=0xA + priv=0xB).
- All 7 canary-only entries have ours-side count = **0** at -n 500M.
- Our trace ends with main thread (hw=0) parked on `XNotifyGetNext +
  NtWaitForSingleObjectEx(0x10f4, lr=0x824ac578)` and hw=1 parked on
  `NtWaitForMultipleObjectsEx(lr=0x824ab214) + cs=0x828f3e70` —
  classic post-cache-recreate spin.
- The 44 `NtWriteFile` calls in ours.log (cache zero-fill) are followed by
  more NtClose / NtCreateFile cycles, but `XexCheckExecutablePrivilege(0xB)`
  never fires → priv-11 site in `sub_824A9710` is unreached.
- Memory's predicted `0xC000014F` does not yet appear in ours.log; first
  cache-related error is `0xC0000034` (OBJECT_NAME_NOT_FOUND) from
  `lr=0x824a97e4`. This still fits the gate hypothesis: the recreate path
  is reached, completes its writes, re-opens, queries volume info, and
  the *game-side* verifier rejects our reply silently (no kernel error).

---

## Tier 0 — upstream gate (SUPERSEDED 2026-05-04 — fix landed but cascade did NOT fire)

### KRNBUG-IO-002 — `nt_query_volume_information_file` block size — **LANDED, gate hypothesis FALSIFIED**

**Outcome:** the block-size literals at `exports.rs:1255-1256` were corrected
to canary's NullDevice values (`sectors_per_unit=0x80, bytes_per_sector=0x200`,
product `0x10000`). 591 → 592 tests, lockstep `instructions=100000010, swaps=2,
draws=0` deterministic across two reruns (`audit-runs/post-IO-002/lock_n100m_run{1,2}.json`).
sylpheed_n50m oracle still matches its existing golden (no observable change at -n 50M).

**However, the predicted cascade DID NOT fire.** Set-difference on a fresh
500 M trace (`audit-runs/post-IO-002/ours.log`) produces the **identical**
seven-entry canary-only set audit-006 captured pre-fix:

```
ExTerminateThread, KeReleaseSemaphore, KeResetEvent,
ObCreateSymbolicLink, XamTaskCloseHandle, XamTaskSchedule,
XamUserReadProfileSettings
```

`XexCheckExecutablePrivilege` count remains **1** (priv=0xA only, priv=0xB
unreached). `XamTaskSchedule` count remains **0**. Worker thread spawns
fell from 19 → 18 (within noise — single thread variance per call-site
breakdown: `lr=0x824ac5f0×15 + 0x824cd984×1 + 0x824d2e68×2`). The 16
NtQueryVolumeInformationFile call sites in `ours.log` all originate from
a single LR `0x82611f38` — meaning the `audit-006` premise that
`sub_824ABA98`/`sub_824A9710` consume the volume-info reply at the
priv-11 gate may be **incorrect**, or the gate consumes a *different*
information class entirely.

**Stop-condition triggered.** Per the IO-002 task brief, this session does
not pivot to a second fix. The fix is correct (it makes our reply
byte-identical to canary's NullDevice and survives every test we have);
it is just not load-bearing for the priv-11 gate. The branch landed as a
strict no-op at our current boot horizon — kept because it's correct and
unblocks no regression.

**Next-session next gate hypothesis (untested):**
- The audit-005 disasm of `sub_824ABA98` may have mis-attributed the consumer
  of bytes_per_sector. The IO-001 trace decisively located the failure at
  the `NtReadFile` inside `sub_824A9710`, not at any volume-info site.
  Re-read the `sub_824A9710` disasm with that in mind.
- Volume-info LR `0x82611f38` is far downstream of the priv-10/priv-11
  cluster (the calls *complete* successfully — they don't gate anything
  visible). The actual gate may be `nt_query_information_file`,
  `nt_query_full_attributes_file`, an FsCtl IOCTL, or a different
  alloc-unit query path.
- Per AUDIT-005 instrumentation, the priv-11 site at `sub_824A9710` PC
  cluster has **never fired** in any session. Probe `sub_824A9710` entry
  with `--pc-probe` and trace which conditional exits the function before
  the priv-11 query — that's the real gate.

---

### KRNBUG-IO-002 — `nt_query_volume_information_file` block size (original spec, kept for archaeology)

- **Where in our code:** `crates/xenia-kernel/src/exports.rs:1241-1269` (function
  `nt_query_volume_information_file`).
- **Classification:** `REAL_BUT_BUGGY`. Registered at exports.rs:100, called
  16× in ours.log (16× in canary.log too — call counts match), returns
  `STATUS_SUCCESS`, but the FileFsSizeInformation payload is wrong.
- **Bug:** class=3 branch writes `(total=0x100000, free=0,
  sectors_per_unit=1, bytes_per_sector=2048)`. Product = 2048 bytes per
  cluster.
- **Canary reference:**
  - Entry function `NtQueryVolumeInformationFile_entry` at
    `xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_io_info.cc:323` (case
    `XFileFsSizeInformation` at lines 355–365). Canary delegates to per-device
    methods on `file->device()`.
  - `NullDevice` (the device backing `\Device\Harddisk0\Cache0`) returns
    `sectors_per_allocation_unit() = 0x80` and `bytes_per_sector() = 0x200`
    at `xenia-canary/src/xenia/vfs/devices/null_device.h:38-46`. Product =
    65536, matching Sylpheed's expectation.
  - Other device backings (HostPath, DiscImage, DiscZArchive) all return
    `(1, 0x200)` = 512. Sylpheed's first volume query at this site is
    against Cache0 (NullDevice), so the relevant value is 65536.
- **Fix sketch (minimum):** in the class=3 branch, change the two writes to
  `mem.write_u32(info+16, 128); mem.write_u32(info+20, 512);` (and reduce
  TotalAllocationUnits accordingly so the disk size remains plausible —
  e.g. 0x10 units × 128 sectors × 512 bytes ≈ 1 MB, matching NullDevice).
  Total diff ≤ 4 lines.
- **Fix sketch (proper, deferred until the cluster fires reliably):**
  introduce a per-handle device-info lookup so HostPath / DiscImage paths
  return their canary-correct values too. Skipped for now because Sylpheed
  only queries Cache0 at this gate.
- **Expected observable post-fix:**
  - `XexCheckExecutablePrivilege` count: 1 → 2.
  - `XamTaskSchedule` count: 0 → 1 (callback=0x824A93C8, message=0x828A28F0).
  - `kernel.calls{XamTaskSchedule}` finally non-zero — closes the
    APUBUG-PRODUCER-001 / XAMBUG-PRODUCER-001 producer hunt that
    falsified XAudio + XamTaskSchedule producer hypotheses.
  - Spawn of the Cache0 callback thread (XThread::Execute thid 7 in
    canary, our equivalent to come).
  - Inside that thread: `StfsCreateDevice` (still undefined extern in
    canary too — does not block) + `ObCreateSymbolicLink` +
    `ExRegisterTitleTerminateNotification`.
  - Back on main: `KeResetEvent(0x8287094C)`, `NtCreateEvent`,
    `ExCreateThread(entry=0x82181830, ctx=0x828F3D08)` — and `0x82181830`
    is the worker entry for **dispatcher 0x100c**, one of the four
    parked-handle producers (per
    `project_xenia_rs_producer_stack_trace_2026_05_03.md`). Spawning
    that worker should advance handle 0x100c's `signal_attempts`
    counter off zero.
  - Eventually (further into the boot): `XamUserGetXUID`,
    `XamUserReadProfileSettings`, `XamContentCreateEnumerator`,
    `KeReleaseSemaphore` display-pump (268+ calls in canary at this
    horizon).
- **Risk:** low. Two-line value change. NullDevice is the only device
  Sylpheed asks about at this gate; other devices are not yet hit.
- **Effort:** trivial.
- **Dependencies:** none. Land directly.
- **Verification chain:** `cargo test -p xenia-kernel`,
  then `cargo run --release -p xenia-app -- exec sylpheed.iso -n 500_000_000`
  with kernel-call tracing on, then re-run audit-006's set-difference;
  expect canary-only count to drop from 7 toward 0 as the cluster fires.

---

## Tier 4 — REAL_BUT_UNREACHED / STUB_BUT_UNREACHED — do not fix yet

These are downstream of Tier 0. Reachability is blocked on KRNBUG-IO-002
landing. After IO-002 lands, re-derive this list — most entries should
have moved off, and any survivors will be classifiable on real evidence.

| # | Export | Ordinal | Library | Our state | Canary impl | Canary calls (at horizon) | Cascade rank |
|---|--------|---------|---------|-----------|-------------|---------------------------|--------------|
| 1 | `XamTaskSchedule` | 0x01AF | xam | REAL_BUT_UNREACHED (`xam_task_schedule`, xam.rs:213) | `xam_task.cc:43-80` | 1 (gate-pivot call) | upstream-of-cluster — fires the entire post-IO-002 cascade |
| 2 | `XamTaskCloseHandle` | 0x01B1 | xam | STUB_BUT_UNREACHED (`stub_success`, xam.rs:33) | `xam_task.cc:83-93` (one-liner: `NtClose` + last-error) | 1 | low (cleanup after #1) |
| 3 | `KeResetEvent` | 0x8F | xboxkrnl | REAL_BUT_UNREACHED (`ke_reset_event`, exports.rs:3172) | `xboxkrnl_threading.cc:566` | 1 | medium — clears 0x8287094C right before ExCreateThread(0x82181830) on main |
| 4 | `ObCreateSymbolicLink` | 0x0103 | xboxkrnl | STUB_BUT_UNREACHED (`stub_success`, exports.rs:121) | `xboxkrnl_ob.cc:351` | 1 | low — Cache0-symlink registration; cosmetic for Sylpheed boot |
| 5 | `KeReleaseSemaphore` | 0x88 | xboxkrnl | REAL_BUT_UNREACHED (`ke_release_semaphore`, exports.rs:3280) | `xboxkrnl_threading.cc:724` | 268 | high (in volume) — display-init pump on the post-cluster main loop |
| 6 | `ExTerminateThread` | 0x19 | xboxkrnl | REAL_BUT_UNREACHED (`ex_terminate_thread`, exports.rs:312) | `xboxkrnl_threading.cc:173` | 2 | low — thread cleanup on Cache0 / profile threads |
| 7 | `XamUserReadProfileSettings` | 0x0219 | xam | REAL_BUT_UNREACHED (`xam_user_read_profile_settings`, xam.rs:327) | `xam_user.cc:329` | 2 | medium — gates the `XamUserGetXUID → profile load` flow far downstream |

**Why every entry above is Tier 4 (not Tier 1):**

- Each entry's first call in `canary.log` falls **after** line 1210
  (`XamTaskSchedule(824A93C8, ...)`), which is the gate-pivot call.
- Our trace contains zero of any of the seven, despite running 500 M
  instructions and reaching the post-cache-recreate horizon.
- Six of the seven are already real implementations. The two stubs
  (`XamTaskCloseHandle`, `ObCreateSymbolicLink`) are minor cleanups; even
  upgrading them would not move boot progress until #1 (`XamTaskSchedule`)
  fires.
- Therefore: fixing any of these in isolation is wasted effort. They
  should be re-classified after KRNBUG-IO-002 lands and the priv-11 /
  Cache0 callback chain runs.

---

## Tier 1 / 2 / 3 — empty for this audit

No entry qualifies as Tier 1 or Tier 2 in the current state. The single
high-cascade fix worth pulling next is the Tier-0 gate (KRNBUG-IO-002),
which is **not itself a canary-only export** — it's a wrong-value bug in
an export both sides call, so the diff.py based set-difference doesn't
surface it. That is exactly why audit-006 was scoped this way: to confirm
the gate hypothesis from `project_xenia_rs_io_nullfile_2026_05_04.md`
before another implementation session is started.

---

## Cross-check vs IO-001 snapshot

IO-001 memory recorded these 7 still-canary-only exports:
> ExTerminateThread, KeReleaseSemaphore, KeResetEvent, ObCreateSymbolicLink,
> XamTaskCloseHandle, XamTaskSchedule, XamUserReadProfileSettings.

Audit-006 set-difference produces the **identical** 7, in 1:1
correspondence. No new canary-only export has appeared since IO-001
landed; no entry has moved off. Cascade is still parked at the same gate.

The `XeCryptSha`, `XeKeysConsolePrivateKeySign`, and `NtDeviceIoControlFile`
entries that IO-001 was credited with unblocking are confirmed: ours
calls them 1, 1, 2 times respectively (canary calls them 1, 1, 2 — exact
match). They are correctly off the canary-only list.

---

## Methodology notes

1. **"Cascade rank" definition:** estimated by where the export's first
   canary call falls in the boot sequence and how many downstream code
   paths depend on it. "high" = upstream-of-cluster (XamTaskSchedule).
   "medium" = intermediate (KeResetEvent, profile cascade).
   "low" = leaf cleanup or cosmetic (XamTaskCloseHandle, ObCreateSymbolicLink).
   Rank only matters once Tier 0 is landed; until then everything is parked.
2. **Reachability oracle:** binary `grep -c "call=NAME"` against ours.log
   at -n 500M. Zero counts are conclusive for "unreached" because tracing
   is unconditional.
3. **Canary log freshness:** the log is from 17:34 (3 h before this
   audit) but is byte-identical to audit-005's input — canary's behavior
   is deterministic given the same ROM and the canary build header
   (`canary_experimental@9467c77f0 on May 2 2026`) hasn't changed.
   Re-running through Lutris is unnecessary.
4. **Gate confirmation:** memory predicted block-size mismatch as the
   IO-002 blocker; this audit confirmed it by eliminating the alternative
   (no Tier-1-eligible canary-only export exists in the current 7-entry
   list). The 0xC000014F status memory predicted is not yet visible in
   ours.log because the recreate path completes the writes — the
   verifier inside `sub_824ABA98` rejects the volume-info reply at the
   game level (no kernel error logged).
5. **What this queue is *not*:** a list of fixes to land. The audit-006
   discipline was scoping; the discipline of subsequent sessions is to
   re-run audit-006's diff after IO-002, then either close audit-006 (if
   the cluster fires through and all 7 entries drop) or open audit-007
   on whatever new canary-only set surfaces.

---

## Recommended next session

**KRNBUG-IO-002 (block-size fix), one-shot.** Two-line edit at
`crates/xenia-kernel/src/exports.rs:1255-1256`. Verify the cluster fires
by re-running audit-006's set-difference; expect 7 → 0 (or close to 0)
canary-only entries. If new entries surface in either direction, that's
audit-007's input.

**Do not** open this queue's Tier 4 entries before IO-002 closes. Their
classification is pending; their fix sketches will look very different
once they're observably called and their actual return values can be
compared to canary.