# Ours wedge localization

**Source data**: `phase-w-wedge-reattack/ours-postfix.jsonl` (50M-instr
cold run, ~3 s wallclock, 121,569 events, 13 tids).
`phase-w-wedge-reattack/halt-on-deadlock-dump.txt` (per-tid state @
deadlock).

## TL;DR

Ours's wedge is **structurally identical** to AUDIT-049 (first found
2026-05-10).  Across 25+ subsequent iterates (Phase C+1 … Phase C+25,
Phase D, AUDIT-049 .. AUDIT-069), the wedge has **never moved**:

- **tid=1 (main)** wedges at `sub_82173990+0x2D4` (PC `0x824ac578`,
  `do_wait_single`) on **handle `0x12c8`** = `Thread(id=13)` — the
  renderer thread's join handle.
- **tid=13 (renderer / cache-IO worker)** wedges at
  `sub_821CB030+0x1B0` (PC `0x824ac578`, `do_wait_single`) on
  **handle `0x12d0`** = `Event/Auto`, created by tid=13 itself at
  `sub_821CB030+0x128` via `NtCreateEvent`.  `<NO_SIGNALS_DESPITE_WAITS>`.
- **`sub_825070F0` fires 0×** at any horizon probed (50M, 500M, ∞
  wallclock).  The 4 workers (entries `0x82506528/58/88/B8`) never
  spawn in ours.

This is what audits 049/058/059/060/062/063/064/065/066/067/068/069
collectively call "the wedge."

## Graph view: ours's actual reachable subgraph vs canary's

### What runs in BOTH engines (matched-prefix 105,128)

```
entry_point
 └─ early CRT init        ✓ ours ✓ canary
 └─ subsystem init        ✓
    ├─ VdInitializeEngines (×2, then VdShutdownEngines, then again)
    ├─ VdInitializeRingBuffer
    ├─ VdEnableRingBufferRPtrWriteBack
    ├─ VdSetGraphicsInterruptCallback
    └─ VdSetSystemCommandBufferGpuIdentifierAddress
 └─ 10× ExCreateThread (the matched first spawn burst)
    ├─ 0x82181830 / 0x8245A5D0 / 0x82450A28      ✓ ✓
    ├─ 0x82457EF0 (spawned by tid=10 → tid=11)   ✓ ✓
    ├─ 0x824CD458 (KeWait worker, susp=F)        ✓ ✓
    ├─ 0x822F1EE0 (renderer, susp=T)             ✓ ✓
    ├─ 0x824D2878 / 0x824D2940 (XAudio, susp=T)  ✓ ✓
    ├─ 0x82178950 (XMA, susp=F)                  ✓ ✓
    └─ 0x821748F0 (file IO spawner, susp=T)      ✓ ✓
 └─ 1× boot-init VdSwap                          ✓ swaps=1
 └─ tid=1 enters sub_8216EA68 → sub_822F1AA8
    └─ bctrl vtable[0] of *(0x828E1F08)
       └─ sub_82175330 → tail → sub_82173990
          └─ sub_821746B0 → spawn worker (= ours tid=13, susp=F)
          └─ KeWaitForSingleObject INFINITE on tid=13.handle    ← WEDGE
```

### What runs ONLY in canary (the missing subgraph)

```
After tid=6's tid=17 worker (= ours's tid=13) terminates:
  sub_82173990 returns to sub_822F1AA8's outer loop
   └─ iterates sub_821741C8 → sub_82172BA0 → vtable[6] = sub_821B55D8
      → sub_824F8398 → sub_824F7CD0 → sub_824F7800 → vtable[1] = sub_825070F0
         └─ 4× ExCreateThread(entry=0x82506528/58/88/B8, susp=T)
            ├─ Worker 0 → tid=28 (file IO, 3.26M events)
            ├─ Worker 1 → tid=27 (36k events)
            ├─ Worker 2 → tid=29 (91k events)
            └─ Worker 3 (0x825065B8 — never resumed in jitter-1 run)

After workers come online:
  Canary's secondary spawn burst (1.94–2.15 s) — 8 helpers (tids 18–25)
  Canary's tid=14/15 XAudio resumes (~ms after tid=6 spawns them in
    susp=T; ours also spawns them susp=T but never resumes them)
  Renderer tid=13 unblocks, starts emitting VdSwap at ~150 fps
  Per-frame game loop: tid=6 emits `0x822F1BCC` 4040× / 60 s
```

## The wedge dependency graph (cyclic)

```
            [tid=1 (main) wedge]
                       │
                       ▼
     wait on handle 0x12c8 (= tid=13.thread_handle)
                       │
                       ▼
       only signaled when tid=13 calls ExTerminateThread
                       │
                       ▼
         tid=13 needs to complete sub_821CB030 body
                       │
                       ▼
         sub_821CB030 waits on event 0x12d0
                       │
                       ▼
   only signaled by sub_825070F0 worker cluster
                       │
                       ▼
        sub_825070F0 never fires in ours
                       │
                       ▼
    sub_825070F0 is reached via:
       sub_82172BA0 → ... → sub_824F7800 → bctrl vtable[1]
    ↑↑↑ which is downstream of sub_822F1AA8's outer loop
        which is downstream of sub_82173990 returning
        which is downstream of tid=1's wait completing
        ← BACK TO TOP
```

This is the **AUDIT-063 self-referential lock**: the activation chain
that produces the signal that unwedges the wait is itself downstream
of the wait completing.  In canary, the lock resolves because the
tid=17 worker (= ours tid=13's analog) calls `ExTerminateThread`
**by completing** its `sub_821CB030` body — and that completion is
fed by some OTHER signal source that ours doesn't replicate.

## Where the "other signal source" lives (the actual root cause)

From AUDIT-069 Session 5 (work-semaphore release-rate diff):

> Canary 414 release events vs ours 99 (24% rate).  Worker (tid=10/5):
> 382 vs 90.  Main (tid=6/1): 7 vs 8.  **Other producers: 25 vs 1**.

The discrepancy in "other producers" (25 producers vs 1) is the key.
**Canary has multiple non-worker threads that release the work
semaphore during bootstrap — releasing this semaphore is what feeds
the worker-side wait that eventually causes sub_821CB030's event to
be signaled.** Ours has only one (tid=13 itself, before it wedges).

From AUDIT-069 Session 4 (`sub_82450A68` dispatch loop):

> Ours r3=0x1 (semaphore acquired) 91/91 captures (100%); canary
> r3=0x102 (TIMEOUT) 3/4 (75%).

**Ours's work-semaphore has count > 0 every time tid=5 checks; canary's
times out 75% of the time.**  This is a *paradox at face value*: how
can ours have MORE semaphore signals available but still process
LESS work?  The S5 reframe resolves it: ours's worker self-releases
the work semaphore from `sub_82450B68+0xCDC/+0xD28` MORE OFTEN than
it consumes, because the consume path early-exits when the dispatch
table doesn't have an entry to process — and the dispatch table
doesn't have entries because the producers (canary's "other 25 tids")
aren't running.

## Bootstrap divergence (when does ours first diverge from canary?)

Per the AUDIT-069 H3 framing: somewhere in the *bootstrap* of the
worker-cluster, a producer thread that should be alive in canary
isn't alive in ours.  Candidates:

1. **XAudio render thread (canary tid=14/15)**: spawned suspended in
   ours, **never resumed**.  Canary resumes within ~1 ms of spawn at
   1.726 s.  Canary's tid=14 calls `XAudioGetVoiceCategoryVolumeChangeMask`
   26,126× and is one of the top event producers.  This thread runs
   the host-audio bridge feed loop — *if it isn't running, downstream
   producers expecting audio cues block.*
2. **XMA decoder (tid=16, entry `0x82178950`)**: spawned non-suspended
   in both; ours emits 0 events from this thread because it presumably
   waits on a kernel object that's never signaled.
3. **NtWaitForMultipleObjectsEx worker (canary tid=21, entry
   `0x824563E0`)**: 1M events in canary; absent in ours (canary's
   second spawn burst doesn't happen).
4. **The "tid=10 helper" (canary tid=10, entry `0x82450A28`)**: ours
   has this thread (ours tid=5), but it's running the dispatch loop
   `sub_82450A68` in a degenerate fast-path mode (S4 finding).

The most defensible single-root claim:

> **Ours never resumes the XAudio threads (tid=14/15), because the
> guest API call that triggers their resume in canary doesn't fire in
> ours, and as a knock-on the worker cluster never gets the bootstrap
> producer it expects.**

But this claim is not yet proven; AUDIT-068/069 stopped short of
identifying the resume trigger.

## Verified-but-doesn't-help LOC budget across recent audits

(For methodology context — every recent audit landed correctness or
diagnostic LOC but moved progression 0%.)

| Audit / Phase | LOC added | Component | Effect on progression |
|---|---:|---|---|
| AUDIT-067 vptr-mem-watch | +422 (canary) | Mem-watch diagnostic | 0 |
| AUDIT-068 S1-S4 | +520 cumul (canary) | Host-side write hooks | 0 (writer identified at guest PC) |
| AUDIT-069 S1-S5 | +60 (canary), 0 (ours) | Wait/release watch | 0 (counts diverge, no fix) |
| Phase D Stages 0-4 | +450-500 (ours+tools) | Contention manifest | 0 (104,607 cap unbroken) |
| Phase D D-extension | +95 (tool) | Nested-CS absorber | +439 matched-prefix only |
| Phase C+1 .. C+25 | varies | Allocator/event/thread shims | 0 (matched-prefix only) |
| Phase W | +20 (ours) | VdInitializeEngines r3=1 | +66 matched-prefix only |
| **Total to break wedge: 0 LOC of any kind** | | | |

This is the single most striking pattern from the audit chain: **every
honest correctness fix advances matched-prefix; none move
`draws / swaps / unique_render_targets`.**

## Falsification budget for the wedge framing

The wedge framing IS robust (no audit has falsified it since AUDIT-049).
But it has limited explanatory power: it tells us *what is blocked*,
not *what should unblock it*.  Reading-error #38 (cross-spawn producer
paths missed by static reachability) and #36 (POD struct copy bypass)
both proved that the install / wake mechanism in canary involves paths
guest static analysis cannot see.  This is a methodology constraint,
not an unsolvable problem.