=== AUDIT-024A diff: canary (post-XAudioSubmitRenderDriverFrame trigger) vs ours (-n 500M) ===

Canary log telemetry pre-dump:
  - First XAudioSubmitRenderDriverFrame fires (triggers dump)
  - KeReleaseSemaphore(0x828A3230, 1, 1, 0) firing repeatedly
    (audio buffer-completion semaphore — audit-018 prediction confirmed)
  - VdSwap, VdGetSystemCommandBuffer, VdRetrainEDRAM all firing
  - Multiple texture loads (1280x720 k_8_8_8_8) — renderer running steady-state
  
Ours stats at -n 500M:
  - instructions=500000003
  - VdSwap=2 (plateau persists)
  - XAudioRegisterRenderDriverClient=1 (registration ran)
  - **XAudioSubmitRenderDriverFrame=0** (NEVER reached)
  - **KeReleaseSemaphore=0** (still missing — canary-only export queue)
  - NtSetEvent=3334 (matches post-KeResumeThread cascade)

=== Address-by-address comparison ===

addr=0x828F4070 (the [+64] singleton — audit-017 hypothesis target)
  CANARY  +0x00: all zeros for 0x40 bytes
  OURS    +0x00: 01 00 00 00 ... ff ff ff ff (0x10) ... 00 00 15 ec (handle@0x1e) ...
  *** [0x828F4070+64] = 0x828F40B0 ***
  CANARY  +0x40 (=0x828F40B0+0): 00 00 00 00 00 00 00 00 ... (zeros)
  OURS    +0x40 (=0x828F40B0+0): ff ff ff ff 00 00 00 00 ... (sentinel -1 plus zeros)

  → CANARY [0x828F40B0]+0..0x40 = ALL ZEROS
  → OURS   [0x828F40B0]+0..0x40 = -1 sentinel at +0, then zeros
  → AUDIT-017's claim "[0x828F4070+64]==-1 init by sub_821701c8" matches OURS exactly.
  → CANARY's [0x828F4070] family is initialised LATER than ours (or an unrelated path).
  → AUDIT-017's β-blocker hypothesis [+64]!=-1 is WRONG: at the post-populator moment
     when canary is firing audio frames, [0x828F40B0]==0 in canary, NOT a non-(-1) handle.

addr=0x828F4838 (audit-023's lead — early-init listener struct)
  CANARY  +0x00: 01 01 00 00 00 00 00 00 58 45 4e 00 f8 00 00 34  ("XEN\0" + handle 0xF8000034 at +0x08)
                +0x10: ff ff ff ff 00 00 00 00 ... 
                +0x20: bc 36 57 40 00 00 00 08 ... (heap ptr 0xBC365740, count=8)
                +0x34: bc 36 51 80 00 00 00 13 (heap ptr 0xBC365180, count=0x13)
                +0x40: bc 36 51 e0 00 00 00 01 ...
                +0x50: bc 65 c9 80 00 00 00 10 00 00 00 00 00 00 00 13 00 00 00 04
                +0x60: 00 00 00 00 f8 00 00 2c f8 00 00 28 00 00 00 01 (kernel handles 0xF800002C, 0xF8000028)
  OURS    +0x00: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (NO "XEN\0" magic, NO handle)
                +0x10: ff ff ff ff 00 00 00 00 ...
                +0x20: 40 24 a2 e0 00 00 00 08 ... (heap ptr 0x4024A2E0, count=8)
                +0x34: 40 24 a1 a0 00 00 00 0f (heap ptr 0x4024A1A0, count=0x0F)
                +0x40: 40 24 a2 00 00 00 00 00 ... (heap ptr 0x4024A200)
                +0x4c: 40 54 22 40 (=0x40542240)
                +0x50: 00 00 00 10 00 00 00 00 00 00 00 0f 00 00 00 0f
                +0x60: 00 00 00 00 00 00 10 30 00 00 10 28 00 00 00 01 (handles 0x1030, 0x1028)
                +0x70: ... 82 8f 40 70 00 00 00 01 ... (back-pointer to 0x828F4070!)

  → BOTH have the listener struct populated.
  → CANARY missing in OURS: "XEN\0" magic + handle 0xF8000034 at +0x08-0x10.
     This is a kernel-handle dispatch type-tag, NOT data-pointer divergence.
  → Heap pointers differ (0xBC36xxxx vs 0x4024xxxx) — different allocator,
     not bug-relevant.
  → Counts and handles all populated in ours; back-pointer to 0x828F4070 present.

addr=0x828A3230 (audio buffer-completion semaphore — KeReleaseSemaphore target)
  CANARY  +0x00: 05 00 00 00 00 00 00 00 58 45 4e 00 f8 00 00 70  (state=5, "XEN\0" + handle 0xF8000070)
                +0x10: 00 00 00 06 01 00 00 00 ... 
                +0x14: 01 00 00 00 (count=1, the released semaphore — was 0)
                +0x18: 00 00 00 00 58 45 4e 00 f8 00 00 80 ("XEN\0" + handle 0xF8000080)
                +0x28: 01 00 00 00 ("XEN\0" + handle 0xF800007C)
                +0x38: be 62 8e dc 1f ca 70 00 (likely callback ptr or last-completed timestamp)
  OURS    not dumped — added to extra-watch-list for next session.

addr=0x828F48B0+0x24 = 0x828F3EC0 (the dispatcher addr for handle 0x100c per audit-003)
  CANARY  +0x24: 82 8f 3e c0 (the dispatcher for the 0x100c worker)
  → confirms the singleton-pool layout in canary too, populated identically.
  → OURS not dumped — added to next-session.

=== Conclusions ===

Outcome (ii) — **`[0x828F4070+64]` is STILL ZERO in canary at first XAudioSubmitRenderDriverFrame**.
The audit-017 β-blocker hypothesis ([+64] becoming non-(-1)) is FALSIFIED.
The actual divergence at this boot point: canary's `"XEN\0" + 0xF8000034` magic at 0x828F4838+0x08
is not present in ours (already known from audit-023, confirmed stable).