xenia-rs/audit-runs/phase-c10-NtQueryFullAttributesFile/investigation.md

Phase C+10 — NtQueryFullAttributesFile — Investigation

Phase 1: Emitter extension (LANDED)

Problem

C+9 left the divergence with no resolved path string:

canary[6][102404] kernel.return NtQueryFullAttributesFile return_value=0
ours  [1][102404] kernel.return NtQueryFullAttributesFile return_value=0xC0000034

payload.args and payload.args_resolved were both empty objects. We had no way to identify WHICH file the engine was querying.

Shape of the fix

Schema v1 already declares args_resolved as a free-form object attached to kernel.call (schema-v1.md:108-117), and the existing example explicitly shows {"path":"..."}. The emitter just wasn't populating it. Extension is pure schema-v1 compliance, no version bump.

Ours-side (event_log.rs / path.rs / state.rs)

• Added event_log::emit_kernel_call_with_path(tid, cycle, name, Option<&str>) — same byte format as emit_kernel_call, but when path is Some(non_empty) emits args_resolved:{"path":"..."}. When None or empty, degrades to the existing args_resolved:{} form so unrelated exports' output is byte-identical to pre-extension.

• Added path::object_attributes_raw_name(mem, ptr) -> Option<String> — returns the RAW path string (trimmed of whitespace, NO prefix-strip / no case-fold) so the diff surfaces upstream prefix-form differences instead of masking them via normalization. Pre-existing object_attributes_to_vfs_path (which DOES normalize) is kept as-is for VFS lookup callers; emitter uses the new raw helper.

• state.rs::call_export, inside the phase_a_on guarded block: new match name resolves OBJECT_ATTRIBUTES* from the right gpr position. Argument positions verified against canary's xboxkrnl/xboxkrnl_io.cc signatures:

  • NtQueryFullAttributesFile → r3 = obj_attrs
  • NtOpenSymbolicLinkObject → r4 = obj_attrs
  • NtCreateFile, NtOpenFile → r5 = obj_attrs Then calls emit_kernel_call_with_path(..., resolved.as_deref()) instead of emit_kernel_call(...). All other exports fall through to None and the legacy form.

Canary-side (event_log.h / event_log.cc / util/shim_utils.h)

• event_log.h: declared EmitKernelCallWithPath(name, path).
• event_log.cc: implemented same as ours (degrades to legacy form for empty path).
• event_log.cc::phase_a_bridge::EmitImportAndCallWithCtx(module, ord, name, ppc_context) — new bridge function. PPCContext is passed as void* to keep the header transitive include footprint small (the bridge cc reinterprets to PPCContext* internally). Inside the bridge, helper ReadObjectAttributesRawName(ptr) reads the X_OBJECT_ATTRIBUTES.name_ptr, then the X_ANSI_STRING bytes directly out of guest memory (no util::TranslateAnsiPath normalization). Trims whitespace + trailing NULs to match ours's semantics byte-for-byte.
• util/shim_utils.h: both export trampolines (X::Trampoline / Y::Trampoline) switched the phase_a_bridge::EmitImportAndCall call to phase_a_bridge::EmitImportAndCallWithCtx, passing the existing ppc_context argument that's already in scope. The legacy EmitImportAndCall stays declared and defined for any future callers that don't have a PPCContext.

Verification

• Build both engines clean.
• Determinism 3x: digest md5 = b8fa0e0460359a4f660adb7605e053de (identical to C+9 baseline — extension is cvar-OFF zero-cost).
• Phase A emitter determinism 2x: det-fields md5 = 7489e90e… byte identical. (Different from C+9's 0b299c37… because the path field IS in the deterministic signature — but stable across runs.)

Phase 2: Re-run + capture path string

After the extension, both engines emit the path at kernel.call.args_resolved.path:

canary[6][102403] NtQueryFullAttributesFile  path = "cache:\d4ea4615\e\46ee8ca"
ours  [1][102403] NtQueryFullAttributesFile  path = "cache:\d4ea4615\e\46ee8ca"

Both engines query the same path. No upstream divergence — the ANSI_STRING content matches byte-for-byte.

Phase 3: Why does ours say NOT_FOUND?

Trace through ours's nt_query_full_attributes_file

exports.rs:1913-1990:

1. Read OBJECT_ATTRIBUTES → path = "cache:/d4ea4615/e/46ee8ca" (after normalize_path).
2. state.resolve_cache_path(&path) returns Some(<temp_dir>/xenia-rs-cache-<pid>-0/d4ea4615/e/46ee8ca).
3. std::fs::metadata(host_path) returns Err(NotFound).
4. Return STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034).

The host path doesn't exist because ours's init_cache_root (state.rs:499-510) clears the cache directory on every boot (AUDIT-038 line: per-process tmpdir + full wipe so two consecutive runs see byte-identical initial state).

Why does canary's NOT fail?

xenia-canary/src/xenia/kernel/xboxkrnl/xboxkrnl_io.cc:474-513:

1. Read OBJECT_ATTRIBUTES → target_path via TranslateAnsiPath.
2. kernel_state()->file_system()->ResolvePath(target_path).
3. If entry found, populate file_info, return X_STATUS_SUCCESS.
4. Else return X_STATUS_NO_SUCH_FILE (0xC0000035).

Canary returns 0 → entry was found. Canary's cache mount is at /home/fabi/.local/share/Xenia/cache/ (a persistent host directory populated over prior boots).

Verification of canary's cache state

$ ls /home/fabi/.local/share/Xenia/cache/d4ea4615/e/
-rw-rw-r-- 1 fabi fabi 400 May 11 21:01 46ee8ca

Single 400-byte file. Total cache: 23 files, ~5 MB across 16 distinct top-level hash directories.

Sibling-cache observations

ours.jsonl shows the SAME NtQueryFullAttributesFile fires for multiple cache paths within the 50M window — all returning 0xC0000034. Example: idx 103810 queries cache:\69d8e45c\8\3421153. So the divergence is not a single missing file but a class of 16+ missing hashes.

Phase 4: Classification + scope decision

Per the plan, the classes are:

• (A) Missing file — a single plant fixes it (small).
• (B) Path-normalization bug — string operation (small).
• (C) VFS mount missing — add the mount (small-medium).
• (D) Subsystem-required — STFS or similar — ESCALATE.
• (E) Upstream divergence — walk back.

This is NOT (B) — both engines normalize identically (verified by matching args_resolved.path).

This is NOT (E) — upstream is bit-identical for 102,403 events.

This is NOT (A) for any single file — the game queries 16+ distinct cache hashes; planting one only postpones the divergence.

This is closest to a hybrid (C+D):

• (C)-ish: canary's cache MOUNT resolves to a populated host dir; ours's mount resolves to a wiped tmp dir.
• (D)-ish: canary's cache is populated because it ran the game before and the game built the cache. To match canary's state on a fresh boot, we either:
  • implement the game's cache-build logic (subsystem),
  • copy canary's pre-built cache (oracle state — AUDIT-038 violation),
  • or accept that ours runs cold and the divergence is a fundamental cold-vs-warm asymmetry.

AUDIT-053 cross-check (warm-start regression risk)

Per AUDIT-053 memo:

Phase 2 permanent fix REVERTED — warm-start regression from VFS layout aliasing: open_cache_file treats all NtCreateFile as files, but cache:\d4ea4615 disp=CREATE is meant as a DIRECTORY.

AUDIT-054 fixed that specific aliasing (FILE_DIRECTORY_FILE bit threading). But there's still the AUDIT-053 secondary concern: Sylpheed's cache:\<hash>.tmp journal-style writes append on each boot — making naive persistence self-inconsistent across boots.

Whether AUDIT-054's fix fully unblocks persistence is NOT RE-VERIFIED in this session. Re-testing the AUDIT-053 regression under AUDIT-054's fix-in-tree is itself a follow-up.

Scope per user direction

User said:

If the fix requires major VFS work, STFS subsystem implementation, or cache-population infrastructure: ESCALATE.

Choices 2-4 from escalation.md all qualify as "cache-population infrastructure":

• Choice 1 (single file plant) won't solve the problem (16+ hashes).
• Choice 2 (seed from canary) is oracle state + warm-start regression risk per AUDIT-053.
• Choice 3 (synthesize cache reads) is multi-export semantic-change.
• Choice 4 (build cache from scratch) is a full subsystem.

ESCALATION declared. Phase 1 emitter extension landed as the session's permanent infrastructure contribution.

Discipline check

• Reading-error #28 (canary source-of-truth): verified canary's actual NtQueryFullAttributesFile_entry body (xboxkrnl_io.cc:474-513), did not assume.
• Reading-error #23 (downstream regression): no fix landed, so no regression risk. Emitter extension is cvar-OFF zero-cost.
• Escalation discipline: triggered cleanly; explicit memo; contributing infrastructure (emitter path resolution) kept.
• Path encoding: ANSI_STRING raw bytes captured; both engines agree byte-for-byte; no Unicode issues for the queried path.
• AUDIT-054 deferred-item: not re-touched. Cache persistence remains opt-in via XENIA_CACHE_PERSIST=1. Default keeps the AUDIT-038 wipe behavior.
• --mute=true: every canary run.
• Renamed binaries: xrs-c10 / xc-c10.exe.

Confidence

• Phase 1 emitter extension: HIGH — schema-compliant, additive, cvar-OFF zero-cost verified via determinism.
• Phase 4 classification: HIGH — three independent observations agree (canary cache populated, ours cache wiped, multiple hashes).
• Cascade prediction at 102,404: cache fix lands only the FIRST in a series — next cache hash will be the next divergence. Likely net delta of several hundred to a few thousand matched events per cache slot resolved, until a non-cache divergence appears.