xenia-rs/audit-runs/phase-c22-rtl-enter-leave-control-flow/investigation.md

Phase C+22 investigation — RtlEnter/RtlLeave post-wait control-flow divergence (2026-05-18)

TL;DR

ESCALATE. The divergence at tid=6→1 idx=104,607 (canary import.call RtlEnterCriticalSection vs ours import.call RtlLeaveCriticalSection) is a downstream effect of the same scheduler-determinism asymmetry that C+20 escalated. C+21's floating-absorb correctly removes the visible wait.begin jitter event from the diff (floating_wait (c/o) = 2/0 engaged on this chain in the fresh c22 sample), but the post-wait guest-code branch taken in canary because shared state was mutated during the wait is NOT an observation artifact — it's a structural behavioral consequence of scheduler interleaving and cannot be papered over at the diff layer without falsely matching genuinely different guest behavior.

Verification: NOT jitter

Per reading-error #32 discipline, sampled 4 canary cold streams

• 1 fresh ours cold. The Enter/Leave PATTERN in the post-wait region is structurally consistent across all canary samples:

sample	events 104,604-104,615 (tid=6, import.call only)
c21 archived	E E L L (nested pair after acquire)
jitter-1	E (wait.begin slow-path) E L L
jitter-2	E E L L (same as c21)
jitter-3	(index-shifted +3) E E L L
fresh c22	E (wait.begin slow-path) E L L

All canary samples take an EXTRA nested RtlEnter after the post- loop E at 104,604. Ours never does — it goes E L NtClose.

The two canary jitter shapes (with vs without the wait.begin emission inside the first E pair) are the C+21 absorption target; both shapes converge to the same post-wait nested-Enter behavior.

Mechanism (classification: A + B-via-A)

C+21 absorption confirmed working — the diff harness correctly folds the wait.begin and handle.create events on shared-global dispatcher sid=75ae880ec432eb36 / raw=0xf8000034 (an Event dispatcher used cross-tid) into the matched prefix:

fresh c22 floating_create (c/o) = 1/0
fresh c22 floating_wait   (c/o) = 2/0

Result: matched prefix advances to 104,607 (canary stream internally at idx 104,610 after C+21 unfolds the 3 absorbed events).

The remaining divergence is:

canary [104,610] import.call RtlEnterCriticalSection  (nested 2nd acquire)
ours   [104,607] import.call RtlLeaveCriticalSection  (release first acquire)

This is NOT a "ghost" event. It's a real divergence in guest control flow at the same logical execution point.

Why it happens

Sylpheed's guest code at this PC, after the post-loop CS acquire, reads a state value (e.g. a queue pointer, a reference count, an event-signaled flag) protected by that CS. Based on the value, it either:

• (canary's path): re-enters a nested CS to drain or clean up additional state, then releases both levels.
• (ours's path): proceeds directly to release the outer CS and close the Event handle.

In canary's contended scenario, while tid=6 was blocked on the shared dispatcher at 104,608 (the embedded DISPATCHER_HEADER of the CS object — its wait.begin was on sid=75ae880ec432eb36, the canary's first-toucher SID for this Event), another guest thread held the CS and may have mutated the protected state. When tid=6 resumes and the slow-path RtlEnter completes acquisition, the state value that the post-acquire branch reads has changed, and the branch takes the nested-cleanup path.

In ours, tid=1 never blocked here. No other thread had a chance to mutate the protected state during a wait window. The state value the branch reads is the pre-wait value, and the branch takes the simple-release path.

This is the same downstream effect that the C+20 escalation analysis predicted: "That requires ours to schedule tid=9 ahead of (or concurrently with) tid=1's RtlEnter, exactly as canary's host scheduler did. Ours's deterministic single-stepping scheduler runs tid=1 near-monolithically through this region — tid=9 has no opportunity to claim the CS before tid=1 fast-paths through."

The classification is class A in the C+22 prompt taxonomy: ours's RtlEnter takes a fast path (uncontended) that canary's contended path doesn't — same root cause as C+20.

Why this can't be absorbed in the diff tool (reading-error

#23 risk)

Unlike the wait.begin event itself (which is a transient observation directly correlated to scheduling), the post-divergence Enter / Leave sequence corresponds to distinct guest code paths. Folding canary's extra RtlEnter at idx 104,610 + matching RtlLeave at 104,613 into the matched prefix would require the diff tool to over-absorb a 6-event block per contention occurrence, regardless of whether ours's code path ACTUALLY corresponds to canary's contended path. This crosses the line from "scheduling-jitter mitigation" to "matching genuinely different guest behavior" — reading-error #23 in action.

The C+21 absorb is justified because the wait.begin event is guaranteed to be a no-op observation if/when it fires (canary's xeKeWaitForSingleObject is the slow path that the fast path trivially skips). The post-wait Enter / Leave block is the opposite: real work, real guest code execution.

Engine-side fixes considered and rejected

(i) Wire wait.begin into ours's rtl_enter_critical_section

park path Symmetric to canary, but does NOT fix the divergence at idx 104,607 because ours doesn't park here at all. The patch would be inert in this case; the divergence persists. Useful prophylactic but not the C+22 target.

(ii) Force ours to spin-wait briefly at every RtlEnter to

give other tids a chance to claim the CS Extremely fragile, no guarantee of matching canary's exact interleave. Likely shifts divergence elsewhere without resolving it.

(iii) Implement deterministic CS-priority scheduling

where any other tid that has a pending wait on the same CS gets to run before the current tid's fast-path Would change ours's scheduler semantics broadly. Multi-thousand- LOC scope. Explicitly NOT authorized per the C+22 prompt:

You may NOT (without escalating): Refactor scheduler / thread-model.

(iv) Record canary's contention trace and replay it in ours

("scheduling-trace replay") A new subsystem; recorded under C+20 escalation already.

(v) Modify Sylpheed's guest code at the post-loop branch to

force the simple-release path Would require modifying guest binary — outside scope and defeats the parity goal.

(vi) Add a no-op cs_ptr Phase A emitter additive for

diagnosis ~30 LOC each engine + canary recompile. Cvar-OFF zero-cost. Would allow future investigation to distinguish whether canary's nested RtlEnter at 104,610 is on the SAME CS pointer (recursive bump) or a DIFFERENT CS (nested cleanup lock). Deferred — not needed for the escalation decision because the mechanism (post-wait state mutation) is already established by the C+20 analysis; the additional cs_ptr data would only refine the cause-of-branch story.

Cascade outcome (per C+22 prompt)

• A=verify divergence is NOT jitter: PASS (4 canary cold samples agree on EE-LL nested pattern; C+21 absorber engaged floating_wait (c/o) = 2/0 and matched prefix is 104,607 exactly).
• B=classify (A/B/C/D): PASS — (A) ours's RtlEnter fast-paths while canary's contends → downstream state mutation during the wait → different post-acquire branch in guest code.
• C=land fix or escalate cleanly: ESCALATION (per C+22 prompt authorized fallback).
• D=main matched-prefix > 104,607: N/A (no engine change).

Cold-vs-cold gate matrix (escalation-mode)

gate	result
ours-cold byte-identical to c19	YES (121,569
	events match)
Main matched-prefix	104,607 (= C+21)
Sister chains	11/32/3/41/16 ✓
Phase B image_loaded_sha256	unchanged ✓
Engine source	UNCHANGED
C+21 absorber engagement	1/0 + 2/0 (fired)

Per-chain delta vs C+21 baseline

NONE. All chains identical to C+21:

chain	C+21	C+22 (this)	delta
canary tid=6 → ours tid=1 main	104,607	104,607	0
canary tid=4 → ours tid=11	11	11	0
canary tid=7 → ours tid=2	32	32	0
canary tid=12 → ours tid=7	3	3	0
canary tid=14 → ours tid=9	41	41	0
canary tid=15 → ours tid=10	16	16	0

Methodology note — reading-error class #34

#34 (NEW): cold-run determinism depends on input path form. Running ours against default.xex directly (extracted file) produces a different boot trajectory than running against the parent .iso containing it. The C+19 / C+21 baselines used the .iso path; the .xex direct path yields 40x more imports and 1.6M unimpl warnings (CPU stuck/looping in a probe that doesn't fire on the iso). All cold-vs-cold protocol entries MUST use the iso path. Reproduces deterministically: ours-cold against .iso is byte-identical to the c19 archived ours-cold modulo host_ns/guest_cycle fields (verified 121,569 events all match post-normalization).

Likely cause: the iso path triggers xenia_vfs::disc_image:: DiscImageDevice::open at main.rs:1397-1400, mounting a full disc VFS at d:\ / \Device\Cdrom0\. The bare-xex path skips this and leaves the VFS unmounted for most disc-prefixed opens, causing different boot-validator branches.

This affects ALL future cold-vs-cold protocol runs — always pass the .iso path, not the loose .xex.

Recommendation for next sessions

This is the SECOND C-series session (after C+20) classified as scheduler-determinism in the post-loop RtlEnter region near idx 104,607. The pattern is stable and well-understood. Recommended next-target sequence:

1. C+23 = D-NEW-2 (KeWaitForSingleObject timeout_ns sign/scale asymmetry on tid=12→7 idx=3): canary=-30000000 vs ours=429466729600. Small ε-class encoding fix in ke_wait_for_single_object's timeout-pointer dereference. Independent of scheduler determinism. Out of scope for C+22 per prompt's explicit "You may NOT ... Fix D-NEW-2 in this session."

2. C+24 = D-NEW-3 (canary tid=14 → ours tid=9 idx=41: canary calls XAudioGetVoiceCategoryVolumeChangeMask while ours calls RtlEnterCriticalSection). Pre-context shows identical KeReleaseSpinLockFromRaisedIrql + KfLowerIrql pair; the next branch picks completely different exports. Likely a missing/stubbed XAudio export in ours that, when absent, causes a fallback to a different code path.

3. Open the parallel scheduler-determinism track to attack the C+20 / C+22 family at the root. Estimated multi-session refactor; per prompt this is "a separate session."

Files

• diff-cold-vs-cold.md — full diff report.
• cold-vs-cold-result.md — matched-prefix table + gates.
• canary-binary-cache-pre-wipe.tar.gz — pre-wipe oracle backup.
• canary-xdg-cache-pre-wipe.tar.gz — pre-wipe XDG oracle.
• escalation.md — this document's TL;DR + recommended next.