---
address: 0x8245FEB8
classification: normal_callee
confidence: high
last_audit: 060
aliases:
  - "vptr installer for dispatch_table 0x820B5830"
  - "AUDIT-059 'dead' (FALSIFIED)"
---

# sub_8245FEB8 — vptr installer for dispatch_table 0x820B5830

## Synopsis

Installs a vtable pointer / dispatch-table entry into a runtime-allocated object. Body contains `stw r11, 0(r31)` at `0x8245FFC0` writing the vtable address to the object's slot 0. After install, the object's `bctrl` dispatch reaches the methods in `dispatch_table @ 0x820B5830` (slot 0 = `sub_8245F1D0`, slot 1 = `sub_8245EC10`). Fires 5× in ours / 2× in canary; lives in the AUDIT-050 worker cluster but is NOT dead in either engine — both engines reach the same call site `sub_824601A0+0x68 (PC=0x82460208)`.

## Evidence

- Body opcode at `0x8245FFC0`: `stw r11, 0(r31)` — vtable install pattern.
- Two static callers per `xrefs` table (`source_func`):
  - `sub_824601A0` at `+0x68` (PC `0x82460208`) — 1 site
  - `sub_8245FB68` at `+0x198` and `+0x1C0` (PCs `0x8245FD00` and `0x8245FD28`) — 2 sites
- AUDIT-060 Probe C-Win Windows Debug canary: `--log_lr_on_pc=0x8245FEB8`, 120s → **2 fires, both lr=0x8246020C** (= `sub_824601A0+0x6C`, post-bl PC). `r3=BC365C40` (same object), `r4=4` then `r4=1` (different slot indices), `r31=701CF2E0` then `r31=705AFAA0` (different threads).
- AUDIT-060 Probe O ours: `--ctor-probe=0x8245FEB8 -n 500M` → **5 fires total**: 1 from tid=1 boot path at cycle 5.5M via `sub_824601A0+0x68`, 3 more from tid=1 during UI inflation, 1 on tid=13 at cycle 23788 via the wedge chain.
- The `r4` parameter (slot index) and the `r31` saved value diverge per call; install target object differs.

## Activation

Direct `bl` from one of:
- `sub_824601A0+0x68` (most frequent — boot path)
- `sub_8245FB68+0x198` and `+0x1C0` (internal lib path, sub_8245FB68 itself has callers `sub_8245F880`, `sub_8245FAB0`)

Caller chain upward: `sub_824601A0 ← sub_82460118 ← sub_82452AB8 ← sub_82452DC0`. The vptr-install path piggybacks on the work-submitter cluster.

## Static graph

- Callers: `sub_824601A0`, `sub_8245FB68`.
- Body: vtable write at `+0x108` (`0x8245FFC0`). Other body content not yet detailed.
- The vtable being installed is implicit in caller-supplied `r11` (and possibly elsewhere).

## Audit log

- **AUDIT-060 (2026-05-12)** — measured 5× ours, 2× canary, identical call site both engines. AUDIT-059's framing falsified. Convergence to AUDIT-050 work-submitter cluster confirmed. [confirmed]
- **AUDIT-059 (2026-05-11)** — claimed as "vptr installer dead in ours" because static graph showed `sub_8245EC10` (slot 1 of the installed dispatch table) had 0 static callers reachable from any caller-chain that DB classified as live. [STATUS: falsified by AUDIT-060 — was alive in ours all along; the DB caller-chain reachability call was too narrow.]

## Open questions

- What is the *class* being installed? (Read `r11` at the `stw r11, 0(r31)` site — canary trace shows it's a specific dispatch table.)
- The 5 ours fires vs 2 canary fires — is this a parity match (canary just had only 2 because of the same AUDIT-056 3.21× upstream gate) or does ours over-fire? Aligning instruction-horizon vs wallclock would clarify.
- Slot-1 method `sub_8245EC10` is named the canary signaler B. It fires 2× in ours per AUDIT-060 — but not on the wedge handle (per AUDIT-059 ours signal_attempts=0 on 0x12AC). What handle is it signaling in ours?

## Cross-references

- Installs dispatch_table at: `0x820B5830`
- Slot 0: `sub_8245F1D0` (referenced; not yet dossierd)
- Slot 1: [sub_8245EC10](sub_8245EC10.md)
- Direct callers: `sub_824601A0`, `sub_8245FB68`
- Audits: 059, 060
- Artifacts: `audit-runs/audit-059-gamma-wedge/`, `audit-runs/audit-060-fnptr-array-bootstrap/`