xenia-rs/audit-runs/phase-absorber-review/cross-reference.md

Cross-reference — absorbed events vs Phase W wedge ground truth

Baseline diff: Phase W cold canary canary-wedge.head250k.jsonl (56 MB, head-truncated to ~250k canary tid=6 events) vs ours ours-postfix.jsonl (28 MB). Default tid-map 6=1,4=11,7=2,12=7,14=9,15=10.

Total absorbed events: 8

absorber	side	events
shared-global	ours	1
wait-begin	canary	1
nested-cs	canary	6 (1 [E,L] pair = 6 events)

Per-absorbed-event analysis

Nested-cs (6 events, canary tid=6 idx 104607–104612)

Pure RtlEnterCriticalSection+RtlLeaveCriticalSection import/kernel.call/ kernel.return triples on canary's side. Return values all 0x00000000 (uncontended fast-path). No handles referenced. Not wedge-relevant by construction — these are CS API calls, not signal-flow events.

Wait-begin (1 event, canary tid=6 idx 104622)

SID: a25a16a4f6f547aa (object_type=1 EVENT)
raw_handle_id: 0xf8000044 (canary kernel-table slot)
created at: canary tid=10 idx=843 (worker thread)
used by: 108 wait.begin events across canary tids 6, 9, 10, 17, 18

Embedded inside an RtlEnterCriticalSection block (idx 104620 import.call → 104621 kernel.call → 104622 wait.begin → 104623 kernel.return). This is canary's CS slow-path — the CS was contended so the wait.begin fired on the CS dispatcher Event. Object_type=1 (EVENT) is the Xbox kernel's representation of the CS's owned-by-other-thread dispatcher; NOT a user-mode NtCreateEvent-created Event.

The Event is created on worker tid=10 because in canary the worker did run and contend on this CS. In ours the workers don't run so the CS is never contended; ours fast-paths through (uncontended kernel.return at idx 104616 with status 0).

Wedge handles in ours (per halt-on-deadlock-dump.txt) are: 0x12d0, 0x1020, 0x1040, 0x10b0, 0x10ec, 0x12e4 — all object_type=1 EVENT but all created via NtCreateEvent at LR=0x824a9f6c from worker tid=13. They're worker-LOCAL Events (SIDs d5e23609d3948568 etc., computed from ours's per-tid recipe), NOT the shared CS dispatcher Event a25a16a4f6f547aa.

Verdict: absorber is correctly suppressing CS-contention scheduling jitter, not wedge signal flow. The Event canary waits on is the CS dispatcher proxy, never the user-mode worker-private Events.

Shared-global (1 event, ours tid=10 idx 2)

SID: ac8315b371bcf7cb (object_type=3 SEMAPHORE)
raw_handle_id: 0x828a3230 (guest VA — well-known XAudio voice-volume
                            semaphore, documented in C+18)

ours emits handle.create for this Semaphore at idx 2 because ensure_dispatcher_object synthesizes the shadow KernelObject at first touch (Phase C+17). Canary doesn't emit a corresponding handle.create on the same tid pair because the canary first toucher was a different host thread — classic process-global first-toucher race that C+18 was specifically designed for.

Wedge handles are all EVENT (object_type=1). This is a SEMAPHORE (type=3). Different object class, different code path (XAudio voice volume). Not wedge-relevant.

Verdict: absorber is correctly suppressing first-toucher race for a shared XAudio dispatcher, not wedge signal flow.

Selective-disable matched-prefix deltas

Baseline (all absorbers ON): main tid=6→1 matched=105,128.

disabled absorber	main matched	delta	sister 15→10 matched
(none — baseline)	105,128	0	16
shared-global	105,128	0	2 (−14)
wait-begin	104,616	−512	16
nested-cs	104,607	−521	16

The delta pattern matches the absorbed events exactly:

• nested-cs's 6 absorbed events at idx 104,607–104,612 enabled the 104,607 → 105,128 advance (combined with subsequent wait-begin).
• wait-begin's single absorb at idx 104,622 enabled the 104,616 → 105,128 advance (without it, the absorber-chain stops there).
• shared-global's single absorb on tid=15→10 enabled that sister chain's 2 → 16 advance.

Cross-reference verdict

None of the absorbed events reference a wedge-relevant handle.

Specifically:

1. Nested-cs absorbs RtlEnter/Leave API events — no handles involved.
2. Wait-begin absorbs a CS-dispatcher Event used in CS contention. The wedge Events are user-mode NtCreateEvent outputs from worker tid=13 — DIFFERENT object class than CS dispatchers.
3. Shared-global absorbs an XAudio SEMAPHORE — wedge handles are all EVENT type.

What the absorbers DO reveal indirectly

The wait-begin and nested-cs absorbers fire because canary's main thread (tid=6) waits on a CS that ours never contends on. The reason ours never contends on it is because the worker cluster (canary tid=9/10/14/15/17/18) never runs — they emit 17 and 77 events in ours (vs 995k and 1.9M in canary) per Phase W ground truth.

The absorbers are therefore CORRECTLY treating the contention pattern as scheduling jitter at the diff layer. The underlying root cause — workers don't bootstrap — is what Phase W identified and is unchanged by absorber behavior.

Even if we disabled all three absorbers, the surfaced divergences would be:

• canary's main waiting on a CS dispatcher that ours doesn't create (because the contending worker is absent), AND
• canary's main entering CS nested-cleanup branches because the CS-protected registry has more entries (because workers inserted them).

Both are downstream effects of the same upstream "workers don't run" root cause that Phase D's contention-replay (Stage 3/4) and quantum (Stage 0) experiments already failed to unblock. No new signal-flow gap is exposed.