xenia-rs/audit-runs/phase-c6half-xam-audit/hallucination-audit.md

Phase 0–2 — XAM hallucination audit (Phase C+6½ XAM)

Method

For every xam.xex ord ours registers in crates/xenia-kernel/src/xam.rs::register_exports(), cross-reference against canary's xam_table.inc (1736 entries; authoritative Xbox 360 ord→name mapping). Three classes of mismatch are possible:

1. MATCH — ours's name == canary's name. Most exports.
2. HALLUCINATION — ours's name ≠ canary's name at the same ord. The hallucinated name may be a real NT/Xam function that exists at a different ord on Xbox 360, making it look plausible.
3. GHOST ORD — ours registers an ord canary's table doesn't have.

For each HALLUCINATION, additional severity classification (per C+6½ taxonomy):

• CRITICAL — ours's stub body performs different semantics than canary's named function. Game gets wrong data on every call.
• HIGH — ours's stub body is harmless (e.g. stub_success) but registered under wrong name (Phase A name divergence; no behavior risk at runtime).
• LOW — ours's stub body has correct semantics but name is wrong (rename-only fix).

Headline

count	category
52	total xam ords ours registers
52	MATCH (name agrees with canary table)
0	HALLUCINATION
0	GHOST ORD (no ord registered in ours that canary's table lacks)

Outcome: clean. The XAM table has zero name mismatches.

This is in contrast to the xboxkrnl table audited in C+6½, which had 2 CRITICAL hallucinations (ord 0x82 KeQueryIdealProcessor → KeQueryInterruptTime; ord 0x98 KeSetIdealProcessor → KeSetBackgroundProcessors). Whoever populated ours's XAM registrations evidently used canary's xam_table.inc as the authoritative source from the start.

XamTaskCloseHandle (Phase C+7 target) — explicit verification

Phase C+7's pending main-chain first divergence at idx 102158 is XamTaskCloseHandle return_value=1 vs 0. Audit confirms:

• Ord 0x000001B1 in ours's xam.rs:33 ↔ canary's xam_table.inc:230 are BOTH XamTaskCloseHandle.
• NOT a name hallucination. Both engines call the same function by name.
• The divergence is a body-semantic issue:
  • canary's XamTaskCloseHandle_entry (xam_task.cc:83-93) calls NtClose(obj_handle), returns true (= 1) on success.
  • ours registers stub_success (xam.rs:33) which returns 0.
• The fix is therefore in xam_task body semantics, NOT in this hallucination-audit scope. Deferred to a dedicated C+7 session per directive "don't widen scope to fix non-hallucinated XAM functions".

Class-E sister-sweep candidate (Phase 1 — applied)

While auditing 52 ours-registered XAM ords, cross-referenced which have NO DECLARE_XAM_EXPORT shim in canary (analogous to C+6½'s class-E sister sweep on xboxkrnl).

Canary's XAM DECLARE_XAM_EXPORT* count: 331 shims declared across all src/xenia/kernel/xam/*.cc files.

Of ours's 52 ords, exactly one has a matching name but NO shim in canary, and is currently registered via the noisy register_export path:

ord	canary name	ours kind (pre)	canary has shim?
0x02D5	XamShowGamerCardUIForXUID	register_export → stub_success	NO (table-only)

Wait, isn't XamShowDirtyDiscErrorUI also class-E? It IS class-E in canary (table-only), but the audit reviewed and it's already correctly named and the directive constrains us to bug-class-aware scope: the 1 candidate flagged is the only one ours is currently registering through the loud (event-emitting) path under a class-E name that we have evidence (from C+6 / C+6½) would alter Phase A matched-prefix if hit.

(Note: ALL other ours register_export(..., stub_*) entries with no canary DECLARE_XAM_EXPORT shim were spot-checked. None are currently live in the 50M Phase A window — confirmed by grep of the C+6½ ours.jsonl. So even if any others are technically class-E, they're inert at the current matched-prefix horizon. Per directive "don't widen scope", only the 1 flagged candidate is touched.)

Phase 1 action: rewire ord 0x02D5 to register_unimplemented_export. Mirrors C+6½'s StfsCreateDevice/DbgPrint/etc rewires.

No CRITICAL/HIGH/LOW hallucinations to fix

Per the audit headline. The session's primary deliverable (hallucination fixes) is empty by construction — the XAM table in ours was already clean.

Files

• canary-xam-table.csv — 1736 raw entries from xam_table.inc.
• canary-xam-table-classified.csv — same, with has_shim column (yes/no per DECLARE_XAM_EXPORT* grep).
• canary-xam-declared-shims.txt — 331 names.
• ours-vs-canary.csv — 52-row cross-check with verdict per ord.