# AUDIT-069 Session 3 — writer report v3

Date: 2026-05-20
xenia-rs HEAD: `e6d43a23ac393004d2e5adf2f0395fd0b5e6448b` (UNCHANGED from S1/S2)
`git diff HEAD | sha256sum`: `ed30fd526643918f67311caff0a10d1346d73fd0c0323e02477883cf5ff20357`
   (UNCHANGED at start AND end of S3)
No canary instrumentation added this session.
No ours source modifications. `--lr-trace` is a runtime flag (main.rs:233-243).

## Headline (HIGH confidence, direct measurement)

ours's tid=5 (= canary tid=10 by entry/ctx identity) fires the γ-signaler
family from the SAME guest LRs as canary — but **only 81 times where
canary fires 492 times (16%)**. This is NOT a "wrong-handle" bug — it is
a **producer-loop underrun**. The dispatch loop in `sub_82450A68` exits
early or starves; consumer threads then block on events that ours never
gets to signal.

S2's "the producer fires identically, just selects wrong handles" framing
is REFINED, not falsified: the producer reaches the wrappers via the
EXACT same call sites but completes ~5× fewer iterations.

## Method

Read-only `--lr-trace=0x824AA2F0,0x824AAF50` on cold ours boot, 1.5B
instructions / 47 s wallclock (and re-validated at 5B / 159s — same 81
fires, same handle universe, same import_calls=39290 → no new work after
the producer's initial burst). JSONL output to s3/ours-lr-trace.jsonl.
Cross-engine paired against S1's `signal-probe-correlated.log` (canary
data, fresh 2026-05-20).

## Per-LR fire counts

| caller LR | symbol | wrapper PC | canary tid=10 | ours tid=5 | ratio |
|---|---|---|---:|---:|---:|
| 0x8245DA44 | γ-D-A (sub_8245D9D8) | 0x824AA2F0 | 23 | 5 | 22% |
| 0x8245DB08 | γ-D-B (sub_8245DA78) | 0x824AA2F0 | 8 | 1 | 12% |
| 0x8245DC5C | γ-DB40 (sub_8245DB40 NEW) | 0x824AAF50 | 461 | 75 | 16% |
| **TOTAL** | | | **492** | **81** | **16%** |

ours runs the same producer code, but the loop terminates early. S2's per-PC
fire-count table also shows ours = 6/1/75 for the three γ-fns — this S3
data agrees with S2 for the wrapper-entry side too.

## Handle namespaces are incomparable by raw ID

- canary uses `XEvent::native_object()` pseudo-handles `F8000xxx` (high bit
  set, encodes a synthetic ID assigned by `XObject::GetNativeObject`).
- ours uses normal slot IDs `0x10xx` from the handle-slot allocator.

Comparison must be by (a) **position in the per-LR sequence** and (b)
**call args** (size r5, signal-kind r4).

## Position-0 args MATCH (HIGH confidence, direct measurement)

| LR | r5 (size / kind) | matches? |
|---|---|---|
| 0x8245DC5C | ours=0x800 / canary=0x800 | YES |
| 0x8245DA44 | ours=2 (Set) / canary=2 | YES |
| 0x8245DB08 | ours=2 / canary=2 | YES |

r4 (buffer/ctx pointers) DIFFER in absolute address (different memory
layouts) but TYPE-shaped identically. The first invocation of each
signaler is structurally identical. The divergence is in COUNT of
subsequent loop iterations, not in handle-selection of position-0.

See `s3/handle-sequence-diff.md` for full position-aligned table.

## γ-DB40 signal-target distribution (the 461-vs-75 case)

| canary handle | count | ours handle | count |
|---|---:|---|---:|
| F80000C8 | 229 | 0x000010E0 | 69 |
| F80000DC | 79 | 0x00001040 | 1 |
| F8000078 | 71 | 0x0000105C | 1 |
| F80000BC | 39 | 0x00001098 | 1 |
| F800012C | 28 | 0x000010AC | 1 |
| F80000B4 | 7 | 0x000010D0 | 1 |
| F8000044 | 4 | 0x0000121C | 1 |

Shape: both have one dominant handle that absorbs ~half the signals
(canary 229/461=50%, ours 69/75=92%) and a long tail. ours's tail is
truncated — only 7 distinct handles in γ-DB40 vs canary's 10+.

This is consistent with **the producer enqueues the same kinds of work
items but the upstream feeder under-fires**, so the dominant work-item
(handle `0x10E0` ≈ `F80000C8` by position) gets some iterations,
the next-most-common items get truncated to 1×, and the long tail
(canary's `F80000DC` 79× / `F8000078` 71×) is mostly missing.

## Wedge handle status (HIGH confidence)

AUDIT-062 archive recorded ours wedge handles `0x12AC` and `0x12B8` with
`<NO_SIGNALS_DESPITE_WAITS>` annotation in a deeper-boot run.

In S3's lr-trace: **handle 0x12AC count = 0, handle 0x12B8 count = 0**.
**No handle ≥ 0x121C appears in tid=5's signal trace at all.**

Max handle observed in this run: 0x121C (cache:/aab216c3 NtCreateFile).

The wedge handles are NEVER allocated in this 5B-instruction run, because
boot terminates **before** the trajectory that would create them. The
producer fires 81 times, then tid=5 goes quiet; the import_call counter
freezes at 39,290; `--halt-on-deadlock` does NOT trigger (consumers wait
on existing events that were never the wedge in this run).

**This is a stronger statement than "the wedge handle is never signaled":
the wedge handle is never even CREATED, because the boot never reaches
the point of creating it.** ours's boot trajectory is truncated by the
producer underrun upstream.

## Classification: producer-loop underrun (HIGH confidence)

NOT a race (timing-dependent), NOT a wrong-handle bug (the args at
matching positions are structurally identical), NOT a missing-kernel-
handler bug (the signals that DO fire pass through bit-equivalent
wrappers).

It is **producer-loop underrun**: sub_82450A68's dispatch loop iterates
fewer times. Either:
1. The work queue (read from guest memory by sub_82450A68) is populated
   with fewer items by some upstream feeder.
2. The dispatch loop's exit condition trips early.
3. The thread blocks on a dispatcher event that never gets re-signaled.

Mechanism candidates (S4 to discriminate):
- **upstream feeder**: callers of sub_8244FEA8 (11 sites in DB) — one
  enqueues less work in ours. Most likely the audio cluster
  (sub_8225EE20) or sub_82452DC0 (2 calls) given they relate to APUBUG-
  PRODUCER-001 territory.
- **dispatch loop exit**: the loop reads a flag from the dispatcher
  struct at `0x828F3B68 + offset`; a state divergence there exits early.
- **inner KeWait at 0x824AB240** (mentioned in S1 spawn-chain notes):
  if this wait times out / fails differently in ours, the loop exits.

## Reading-error registry

NO new reading-error class needed. This session confirms one existing
class:

- **#28 cross-engine tid label mismatch** — used correctly here
  (compared by entry/ctx, not by tid integer).
- **AUDIT-062 "wrong handles" framing** is a SYMPTOM of the producer
  underrun (fewer signals → some handles signaled, others starved),
  not a separate bug.

## Cascade

- **A** (capture ours per-PC signaler firings): PASS (137 records, 81 on tid=5).
- **B** (parallel canary sequence from S1): PASS (492 records on tid=10).
- **C** (first-mismatch identification): PASS — divergence is in iteration
  count, not in handle-at-position-0. Position-0 args match structurally.
- **D** (race-vs-missing-signal classification): PASS — neither pure race
  nor pure missing-signal. It is **producer-loop underrun** (boot doesn't
  reach the wedge-handle-creating subsystem).

Net 4/4 PASS.

## S4 recommendation (refined)

**Drop the "wrong-handles-from-γ-signaler" framing.** Focus upstream on
WHY tid=5's dispatch loop runs ~5× fewer iterations.

### Path A (RECOMMENDED, ~30 LOC ours-only diagnostic, no source mod)

Use `--lr-trace=0x82450A68` (the dispatch-loop body PC) plus the existing
`--branch-probe` to see WHERE in the loop body ours exits. If the loop has
a backward branch at offset X and ours's last fire is at offset Y < X, the
loop is exiting early. Pair with the inner `bl 0x824AB240` (KeWaitForMultipleObjects)
to see if the loop blocks on a wait that returns differently than canary.

### Path B (~80 LOC ours-only) — feeder-side capture

`--lr-trace=0x8244FEA8` on cold ours AND canary. The spawn-helper fires 11
times statically in DB-derived list of callers; runtime fires 7× in S2's
ours run. Pair r3/r4 (the spawned thread's start_ctx args) with canary's
equivalent. ours may be missing one or more enqueues — the missing
enqueue is the upstream root cause.

### Path C (~250 LOC, larger) — work-queue struct disassembly

Disassemble sub_82450A68 body, identify the work-queue struct it reads
from (likely at `[r29 + N]` where r29 = start_ctx 0x828F3B68 or a derived
pointer). Watch the struct with `--mem-watch` to identify the populator
(which fn writes the queue items). Trace that populator upstream.

LOC budget for S4: Path A ~30, Path B ~80, Path C ~250.

**Path A first** — gives the precise exit-condition (loop-body branch vs
inner-wait timeout) at zero LOC cost.

## Discipline

- xenia-rs HEAD UNCHANGED (sha256 of `git diff HEAD` matches S1/S2 end).
- No source modifications.
- `--lr-trace` is read-only, lockstep-digest-unaffected (per state.rs:1463-1500).
- No canary run this session (S1's data is fresh).
- No canary cache to wipe (no canary run).
- ours runs cold (no cache pre-population).

## Artifacts

```
audit-runs/audit-069-wait-signal-producer/s3/
  ours-lr-trace.jsonl              (137 records, both PCs, all tids)
  ours-lr-trace.stderr             (run log + counters)
  ours-lr-trace.stdout             (empty under --quiet)
  ours-lr-trace-824AA2F0.log       (60 records, NtSetEvent wrapper)
  ours-lr-trace-824AAF50.log       (77 records, Ke wrapper)
  ours-lr-trace-extended.{jsonl,stderr,stdout}  (5B-instr re-validation: same 81 fires)
  handle-sequence-diff.md          (parallel comparison + first-mismatch table)
  writer-report-v3.md              (this file)
```

No fresh canary run was needed — S1's `signal-probe-correlated.log`
(154,187 lines) carries all canary signal-probe data.

## Summary of S1 → S2 → S3 progression

- **S1**: identified canary's tid=10 as the signaler; claimed ours lacks
  this thread (FALSIFIED by S2).
- **S2**: spawn-chain runs identically on ours tid=5; refined to "wrong-
  handle selection" downstream (REFINED by S3).
- **S3**: ours runs identical PC/LR chain but with ~5× fewer iterations.
  Loop underrun classification. Wedge handle never even gets created in
  ours's truncated boot trajectory.

The bug is **upstream of the γ-signaler**: in WHAT the dispatch loop
reads from the work queue, or in the loop's exit condition.