xenia-rs/audit-runs/phase-c7-keSetEvent/broad-impact.md

Phase C+7 — broad-impact verification

The user explicitly asked for thorough side-effect analysis beyond standard gates. This document covers (1) new-divergence enumeration, (2) KeSetEvent call-site sampling, (3) wake-cascade check, (4) spawn/exit pattern check, (5) determinism stability over a longer horizon.

1. New-divergence enumeration

Comparing pre-fix (audit-runs/phase-c6half-xam-audit/diff-report.md) to post-fix (audit-runs/phase-c7-keSetEvent/diff-report.md):

chain	pre-fix first-divergence	post-fix first-divergence	category
tid=6→1 (main)	idx 102158 XamTaskCloseHandle ret 1/0	idx 102158 XamTaskCloseHandle ret 1/0	persisted (unrelated to KeSetEvent fix)
tid=4→11	idx 5 KeSetEvent ret 1/0	none (full match in 9-event ours window)	resolved
tid=7→2	idx 26 KeSetEvent ret 1/0	none (full match in 29-event canary window)	resolved
tid=12→7	idx 2 KeWaitForSingleObject ret 258/0	idx 2 KeWaitForSingleObject ret 258/0	persisted (different bug)
tid=14→9	idx 39 XAudioGetVoiceCategoryVolumeChangeMask vs RtlEnterCS	idx 39 same	persisted (different bug)
tid=15→10	none	none	unchanged

• Resolved: 2 (both sister chains where KeSetEvent was the first divergence)
• Advanced: 0
• Persisted: 3 (XamTaskCloseHandle, KeWaitForSingleObject=258, XAudio call-name divergence — all on different functions, none related to KeSetEvent)
• NEW: 0 — no new divergence surfaced. The fix neither unblocked a new code path that then re-diverged nor introduced any regression.

This is the clean-fix outcome (per task description language: "NEW divergences are EXPECTED for a widely-used fix"). The clean-zero outcome here is itself a positive finding — within the current 50M horizon, the boot path was not hiding any downstream divergence behind the wrong KeSetEvent return.

Per-tid event totals are byte-identical pre/post fix ((0,1),(1,108486),(2,30),(3,36),(4,2022),(5,9945),(6,315),(7,3), (8,36),(9,75),(10,15),(11,9),(12,6),(13,426)), confirming no secondary boot-trajectory shift from the return-value change. Same boot, same paths, same imports — the only delta is the value in the return_value field on KeSetEvent / NtSetEvent emits.

2. KeSetEvent call-site sampling

Within the 50M Phase A window, ours emits 2 KeSetEvent kernel.return events (one on each of tid=2 and tid=11). Canary emits 7,495 KeSetEvent returns (spread across many threads that ours doesn't reach in this window). Below: every call-site where both engines have data, plus 3 canary-only samples to characterize the unreached space:

#	canary tid → ours tid	idx	canary ret	pre-fix ours ret	post-fix ours ret	match?
1	4 → 11	5	1	0	1	YES
2	7 → 2	26	1	0	1	YES
3	4 → 11	20	1	(ours stream ended at idx 9)	(same)	n/a — ours blocked upstream
4	14 → 9	107	1	(tid=9 diverges at idx 39 on XAudio)	(same)	n/a — ours blocked upstream
5	14 → 9	215	1	(same)	(same)	n/a — ours blocked upstream

Both call-sites with comparable data are now in bit-identical return-value alignment with canary. Sites 3-5 are downstream of unrelated divergences; the KeSetEvent return on each (canary always returns 1) will trivially match the moment our boot reaches them.

3. Wake-cascade check

Phase A's wake-cascade event kinds (wait.end, handle.*, etc.) are not wired in ours's emitter at the time of writing (per MEMORY.md Phase A index: "4 of 13 schema kinds wired"). Therefore we cannot observe wake events directly. Indirect signal: per-tid event counts are identical pre/post fix, suggesting no new threads progress past prior parking points — i.e. the KeSetEvent return-value flip did not visibly change wake-cascade behavior within 50M.

This is consistent with internal-state inspection: ours's ke_set_event already mutated signaled = true and called wake_eligible_waiters correctly pre-fix; only the return-value emission was wrong. Wake semantics never depended on the return.

4. Spawn/exit pattern check

thread.create and thread.exit events are also not wired in ours's emitter (same 4-of-13 reason). Phase A logs 0 thread.create / 0 thread.exit events in both pre and post fix. We cannot independently verify thread count from Phase A.

From the per-tid breakdown (tids present in the log), ours has the same 14 distinct tids pre and post fix (0,1,2,3,4,5,6,7,8,9,10,11, 12,13) with identical event counts. No new tid spawned and no tid disappeared.

5. Determinism stability over time

50M --stable-digest: 3× identical (c6d89582…). Matches C+6½ baseline byte-for-byte. Sample fields:

{
  "instructions": 50000000,
  "imports": 40470,
  "unimpl": 0,
  "draws": 0,
  "swaps": 1,
  ...
}

200M --stable-digest: 2× identical (8186841b…). New baseline. Field values at 200M: imports=40470 still (no new imports between 50M and 200M — boot still plateaus on the same wait), draws=0, swaps=1. Same as 50M. The boot is still parked on the same upstream gate (XamTaskCloseHandle / KeWaitForSingleObject in the main thread); the KeSetEvent fix alone is not sufficient to unblock the next phase.

Conclusion

The fix is clean-positive: resolved exactly the 2 sister-chain divergences it was scoped to (idx 5 / idx 26), preserved main chain (no #23 redux), preserved all 6 unit tests, added 6 new tests, and introduced zero new divergences. Per-tid event totals are byte-identical pre/post fix — the fix is observation-only (changes what the emitter reports, not what the kernel does). The return-value flip from 0 to 1 propagates through Phase A's kernel.return payloads and nothing else, exactly matching canary's behavior.

Next session's target: main-chain divergence at idx 102158 (XamTaskCloseHandle), per C+6½ XAM-audit memory note. tid=4→11 and tid=7→2 fully aligned; if those chains develop new divergences past their current canary-stream ends, that's a future-boot horizon problem, not this session's.