xenia-rs/audit-runs/phase-nonmatch-investigation/result.md

Phase Non-match Investigation — Results

Date: 2026-05-19 Source: xenia-canary/build-cross/bin/Windows/Debug/canary-jitter-1.jsonl (4.4 GB, 18.7M events, 28 tids) Companion ours data: audit-runs/phase-w-wedge-reattack/ours-postfix.jsonl (121,569 events, 13 tids) Outcome: (A) — AUDIT-058/063/067 framing CONFIRMED end-to-end using new Phase A thread.create events.

TL;DR

Per Phase A thread.create events (wired in C+15-α), canary spawns 23 threads; the final 4 fire at host_ns ≈ 10.38 s and have entry PCs 0x82506528 / 0x82506558 / 0x82506588 / 0x825065B8 with shared context 0xBCE251C0 and stack 65,536 — these are exactly the 4 worker entries documented in the sub_825070F0 dossier. The historical AUDIT-058/063 framing is correct: sub_825070F0 is the one-shot 4-worker fan-out that ours never reaches.

Three of those four canary workers go on to dominate the trace: tid=28 (3.26M events, sub_82506528), tid=27 (36k events, sub_82506558), tid=29 (91k events, sub_82506588) — the fourth (0x825065B8) was never resumed in this 90s window.

Ours emits 10 thread.create events vs canary's 23, stops after spawn #10 (0x821748F0 at 1.727s), and never produces another thread.create for the rest of the run. The 13 subsequent canary spawns including the critical sub_825070F0 batch are entirely missing.

What canary's heavy workers DO

tid	events	role	entry_pc
14	6.15 M	XAudio voice-mask poll (26,126× XAudioGetVoiceCategoryVolumeChangeMask)	0x824D2878 (aff=16)
15	4.78 M	XAudio sister (KeWaitForSingleObject + heavy IRQL spinlock cycle)	0x824D2940 (aff=32)
28	3.26 M	sub_825070F0 worker 0 (1.07 M × RtlEnterCS, 530× NtReadFile)	0x82506528 (ctx 0xBCE251C0)
16	1.80 M	XMA decoder (XMACreateContext, RtlEnterCS heavy)	0x82178950
21	1.00 M	NtWaitForMultipleObjectsEx worker	0x824563E0
13	594 k	Renderer (12,092× VdSwap, VdGetSystemCommandBuffer; 1,805× Ke/NtSetEvent; 475× wait.begin)	0x822F1EE0

The biggest workers (tid=14, tid=15) are NOT sub_825070F0 workers — they are spawned much earlier (1.726/1.727s) via sub_824D2878 / sub_824D2940 and run forever as XAudio render/voice threads. Ours spawns these two suspended (1.626s) but they never receive the resume call that would activate them — ours produces 0 XAudio* events on these tids (verifiable from ours's tid event counts: ours has only 13 tids total, none with the 6M-event signature).

Spawn-chain summary (full table in canary-tid-profiles.md)

Three distinct fan-out clusters in canary, all from tid=6 (guest main):

1. 1.42–1.94 s — main init burst: 10 spawns (tids 8–17). Ours matches this 1:1 in spawn count and entries.
2. 1.94–2.15 s — secondary burst (XAM/XCONFIG helpers, tids 18–25): 8 additional spawns. Ours emits 0.
3. 10.08–10.38 s — XAudio worker fan-out: 5 spawns (tids 26, 27, 28, 29, +1 unresumed). The last 4 are the sub_825070F0 workers. Ours emits 0.

sub_825070F0 spawn-chain confirmation (static + runtime)

• sylpheed.db confirms sub_825070F0 lives in vtable 0x8200A208 slot 1 and 0x8200A928 slot 1 (anonymous class ANON_Class_713383D7, 7 slots each).
• Zero vptr_writes / zero xrefs / zero indirect_dispatch_candidates reach either vtable. AUDIT-067's host-side install hypothesis is confirmed by static-analysis exhaustion.
• Function body contains the 4 sequential addi rN, r0, 0x8250652X + bl sub_824AA388 (= ExCreateThread wrapper) blocks at PCs 0x825071F8 / 0x82507244 / 0x82507290 / 0x825072DC.
• The 4 worker entry thunks (0x82506528 / 0x82506558 / 0x82506588 / 0x825065B8) are uniform vtable-slot callers: each loads r3->vtable->[140|144|148|152] and dispatches via CTR (offsets 35/36/37/38).
• Runtime ctx 0xBCE251C0 is referenced 4× in canary jsonl (the 4 spawn events) and 0× in ours-postfix.jsonl. Ours never allocates the dispatcher object that holds the 0x8200A208 vtable.

Wake/signal chain to wedge (partial)

• Phase W: ours's wedge handle 0x12d0 (Event/Auto waited at sub_821CB030+0x1B0 on tid=13 the renderer); main tid=1 join-waits on Thread(id=13) at sub_82173990+0x2D4.
• Canary tid=13 (renderer) creates 10 handles, calls Ke/NtSetEvent 1,805×, calls wait.begin 475× — it is alive and signaling. Earliest tid=13 handle.create at 2.396 s; explosion at 10.7 s once the sub_825070F0 workers come online.
• Canary tid=13's signals correlate with the sub_825070F0 worker batch coming up at 10.7 s (tid=27/28/29 first-events are all 10.705 s). Without those workers, ours's renderer has no producer to wake the event it waits on, and main joins-on-renderer → full deadlock.
• Full SID-level mapping of "which canary worker fires the NtSetEvent that wakes the renderer's wait" was not attempted (handle IDs and SIDs don't cross-correlate run-to-run; would require source-level read of sub_821CB030). The class of producer (sub_825070F0 workers) is identified.

Reading-error / methodology notes

• #16 EH-handler caution: the sub_824AA388 spawn helper is reached via bl (direct call, not via EH unwind) — no risk of misanchoring on a catch handler.
• #28 framing: Phase A thread.create.payload.parent_tid redundantly equals the event's tid field (per event_log.cc:312-326: emitted ON the parent thread's stream, child tid is NOT in payload). Child-tid is recovered by FIFO matching to first_event[tid] chronologically.
• #30 cross-engine SIDs: ours's wedge handle SID d5e23609d3948568 does not appear in canary because these are worker-local Event handles, not process-global dispatchers; only the shared-global recipe is scheduling-invariant.
• Cold-run jitter was not a factor here — only one canary jsonl was processed; the spawn-chain identification is robust because the SID-independent entry_pc + ctx_ptr + stack_size triplet is effectively a content-addressed fingerprint that survives reruns.

Outcome: (A) — historical framing confirmed

The Phase A thread.create data directly corroborates AUDIT-058/063/067:

1. sub_825070F0 IS the function that spawns the 4 sub_82506528-family workers (confirmed in canary trace, never fires in ours).
2. The dispatcher class ANON_Class_713383D7 whose vtable 0x8200A208 slot 1 points at sub_825070F0 has its vtable installed via a path invisible to static guest analysis (AUDIT-067 unresolved).
3. The HEAVY workers (tid=14/15 → XAudio; tid=16 → XMA; tid=21 → NtWait worker) are spawned earlier via different entries (sub_824D2878, sub_824D2940, sub_82178950, sub_824563E0) but are all suspended; their resume gate is also missing in ours (those threads exist in ours-postfix but emit < 100 events each, all from the spawn-time bookkeeping).

Recommended next attack target

Re-attempt the deferred AUDIT-067 / AUDIT-068 host-side vptr install probe with current tooling. Specific subtasks:

1. Identify the allocator that produces the ANON_Class_713383D7 instance with vtable 0x8200A208.

   • Static search: which fn loads 0x8200A208 as a constant? (database says nothing — confirm with a fresh ghidra script that includes split-pair detection.)
   • Runtime probe: instrument both engines to log every stw vptr, 0(obj) where vptr ∈ {0x8200A208, 0x8200A928}. In canary, this MUST fire ≥ 1× before the 10.38 s spawn burst; in ours, it presumably never fires. Identify the PC.

2. If host-side: trace through the kernel exports table. The most likely path is one of XAudio2*Create, XMACreateContext, XMPCreate*, or an undocumented XAudio API. Per the tid=14 call profile, XAudioGetVoiceCategoryVolumeChangeMask is the only XAudio API actively touched — look at its dossier (or canary's xboxkrnl_audio.cc / xam_audio.cc) for object-construction side-effects.

3. Alternative: identify which Sylpheed API call is the trigger for the 10.38 s sub_825070F0 firing. Canary main (tid=6) at host_ns ≈ 10.30–10.38 s does the work that leads up to this; ~300 ms before, tid=6 has activity that ours doesn't reach. Diff tid=6's event stream in canary vs ours's tid=1 in the time window [10 s, 10.4 s] (canary) / [whatever ours's wallclock-equivalent is] — but ours doesn't reach 10 s wallclock either, so the divergence is upstream.

4. Secondary attack: the XAudio tid=14/15 resume gate. Those threads are spawned suspended in BOTH engines (canary at 1.726/1.727 s, ours at 1.626 s); canary resumes them within ~1 ms and they emit 11 M events combined. What guest call resumes them in canary? Cross-thread NtResumeThread on the tid=14 handle. Sylpheed presumably resumes them via an XAudio2 API. If we can identify the resume call site in canary and figure out why ours doesn't reach it, we unblock 60% of the missing event volume (XAudio) independent of sub_825070F0.

Artifacts

All artifacts in xenia-rs/audit-runs/phase-nonmatch-investigation/:

• build_profiles.py — streaming jsonl profile builder (~200 LOC)
• tid-event-counts.csv — per-tid totals (28 rows)
• tid-top-calls.txt — per-tid top-20 kernel.call names
• tid-ntset-handles.txt — per-tid Ke/NtSetEvent handle distribution (EMPTY — canary's kernel.call payloads have args:{} for NtSetEvent; handle is in resolved-arg JSON not exposed in current args_resolved. Not needed for Outcome (A) determination. Future Phase: extend Phase A kernel.call to also surface ALL register args in args for diff-tool consumption.)
• tid-wait-handles.txt — per-tid wait.begin handle distribution (EMPTY for same reason: the wait.begin events I sampled have raw_handle_id=None because the payload uses a handle_semantic_ids array, not a single raw_handle_id. The handle.create map is populated correctly — see handle-create.json.)
• thread-creates.json — canary thread.create payloads keyed by child_tid (note: child_tid is FIFO-inferred, see profiles doc)
• thread-exits.json — canary thread.exit events (3 in this trace: tid=17/18/26)
• excreate-events.json — all ExCreateThread import.call events with idx/host_ns
• create-thread-events.json — full thread.create event payloads
• handle-create.json — all handle.create with raw_handle, sid, object_type
• spawn-chain.json — auto-correlated spawn → ExCreateThread linkage
• canary-tid-profiles.md — human-readable per-tid catalogue + spawn-chain tables
• result.md — this file