--- address: 0x8245EC10 classification: dispatch_table_method confidence: high last_audit: 060 aliases: - "canary γ-wedge signaler B" - "dispatch_table 0x820B5830 slot 1" --- # sub_8245EC10 — dispatch_table slot 1 method, canary γ-wedge signaler B ## Synopsis Method living at slot 1 of `dispatch_table @ 0x820B5830`. The dispatch table is installed at struct offset 0 (vptr) by [sub_8245FEB8](sub_8245FEB8.md). In canary, this method is one of two NtSetEvent caller-LRs that signal the AUDIT-059 file-IO completion wedge dup handle (LR `0x8245ED80` post-`bl 0x824AA2F0`). In ours it fires 2× total but not on the wedge handle. ## Evidence - Located at slot 1 of dispatch table `0x820B5830`. Slot 0 is `sub_8245F1D0`. - The dispatch table is referenced from: - `sub_8245F1D0+0x1C` (self-recursive) - `sub_8245FEB8+0x100` (= `0x8245FFC0`, the `stw r11, 0(r31)` vtable install) - AUDIT-060 Probe O ours: fires **2× in ours** (`--ctor-probe`); both fires come from `sub_8245FEB8` callers (transitively, via the installed dispatch-table dispatch). - AUDIT-059 Probe C canary: at LR `0x8245ED80` (`= sub_8245EC10+0x170` or similar internal PC after `bl 0x824AA2F0`), this fn is one of two distinct canary NtSetEvent caller-fns that signal the wedge dup handle (per cross-run `r31` invariant; the other is [sub_82458B90](sub_82458B90.md)). - Both canary signalers wrap `bl 0x824AA2F0` (NtSetEvent wrapper). Each fires once per file-IO completion in canary. ## Activation Indirect dispatch. Reachable only via `bctrl` against an object whose vptr was set to `dispatch_table @ 0x820B5830`. The install happens via [sub_8245FEB8](sub_8245FEB8.md). No direct `bl` callers — and that is correct for a `dispatch_table_method`. ## Static graph - Static callers (direct `bl`): **0** (correct — indirect dispatch only). - Callees: includes `bl 0x824AA2F0` (NtSetEvent wrapper) at internal PC near `+0x170` (canary LR `0x8245ED80`). ## Audit log - **AUDIT-060 (2026-05-12)** — fires 2× in ours; not dead. AUDIT-059's "dead via 0 static callers" framing was too narrow — dispatch_table reachability needs runtime-installed-vptr awareness, not just static `bl` xref BFS. [confirmed alive] - **AUDIT-059 (2026-05-11)** — identified as canary NtSetEvent signaler B for the file-IO completion wedge dup handle. Cross-run `(tid, r31)` invariant matched. [confirmed for canary signaler role] - **AUDIT-059 (2026-05-11)** — claimed dead in ours due to 0 static callers + dispatch-table installer ([sub_8245FEB8](sub_8245FEB8.md)) ALSO claimed dead. [STATUS: falsified by AUDIT-060] ## Open questions - What handle does `sub_8245EC10` signal in ours? (Two fires — capture r3 at each fire to identify the target handles.) - Why doesn't it signal the wedge handle in ours? Either (a) it's running on the wrong object (different installed instance), or (b) the work item it's processing has a different completion-event field. - Cross-engine method match: is canary fire #1 and ours fire #1 the same logical event? Compare object base (would need new instrumentation). ## Cross-references - Installed at: `dispatch_table @ 0x820B5830` slot 1. - Vptr installer: [sub_8245FEB8](sub_8245FEB8.md). - Sibling method (slot 0): `sub_8245F1D0` (not yet dossierd). - Sibling canary signaler: [sub_82458B90](sub_82458B90.md). - Audits: 059, 060. - Artifacts: `audit-runs/audit-059-gamma-wedge/canary-setwrapper.log`, `audit-runs/audit-060-fnptr-array-bootstrap/`.