xenia-rs/docs/functions/sub_822F1AA8.md

address, classification, confidence, last_audit, aliases

address	classification	confidence	last_audit	aliases
0x822F1AA8	normal_callee	high	065	tid=1 post-init dispatch loop (calls sub_82173990 via vtable[0])

sub_822F1AA8 — tid=1 post-init game-loop dispatcher

Synopsis

Normal-callee invoked by tid=1's entry_point → sub_8216EA68 → sub_822F1AA8. Contains the per-frame game-loop pump for the post-init subsystem-dispatch tree (audit-064 chain to sub_825070F0). Runs an outer loop: (a) KeWaitForSingleObject infinite at PC 0x822F1DFC, (b) dispatches vtable[0] of object at *(0x828E1F08) at PC 0x822F1B4C bctrl — which is sub_82175330 → tail-jump → sub_82173990. Canary executes the body 4040× in 60s (per-frame). Ours executes the function entry 1× then blocks immediately inside sub_82173990 (the vtable[0] callee) at sub_82173990+0x2D0 — KeWaitForSingleObject INFINITE on handle 0x12A4 (= tid=13's thread handle = AUDIT-049 wedge).

Evidence

• Disasm prolog: mflr r12; bl 0x825F0F60; stfd f30, -136(r1); stfd f31, -128(r1); subi r31, r1, 256; stwu r1, -256(r1); mr r30, r3; ... — normal-callee.
• Function size: 996 bytes / 249 insns. has_eh=True, frame_size=0 per DB (dynamic 256-byte frame).
• Static caller: sub_8216EA68+0x3AC via bl (the post-init dispatcher).
• AUDIT-064 ours --ctor-probe=0x822F1AA8 -n 500M fires 1× at tid=1, cycle=6,171,801, lr=0x8216ee14, r3=0x40d09a40. Back-chain: tid=1 thread_proc → entry_point → sub_8216EA68+0x3AC → sub_822F1AA8.
• AUDIT-064 ours fine probe at BB-entries 0x822F1ACC/0x822F1AEC/0x822F1B20/0x822F1B30/0x822F1B38 all fire 1× — execution does pass through the function body to PC 0x822F1B38.
• AUDIT-064 ours --ctor-probe=0x822F1B50 fires 0×. The bctrl at PC 0x822F1B4C DOES execute (sub_82175330 fires 1× per separate probe), but never returns — because sub_82175330 tail-jumps to sub_82173990 which blocks at +0x2D0.
• AUDIT-064 canary 60s probe (--audit_61_branch_probe_pcs): all probes in body fire — 0x822F1B5C/0x822F1B78/0x822F1BB8 fire 1×, 0x822F1BCC (outer-loop body) fires 4040×, 0x822F1D58 (the inner bctrl → sub_821741C8) fires 4030×, 0x822F1DFC (outer KeWait) fires 4040×.
• Global 0x828E1F08 is the slot holding the object pointer that the vtable[0] bctrl dispatches off. Its writers are sub_822F14D8+0xF0 (PC 0x822F15A4, observed in ours) and sub_822F1638+0x84 (PC 0x822F16BC). At cycle ~6,171,800 in ours, [0x828E1F08] is set to 0x40111890; [0x40111890+0] evolves through multiple vtable values (0x820AD894, 0x820A183C, ...) before the bctrl fires; final value at bctrl is 0x820A183C (slot 0 = sub_82175330).

Activation

Direct bl from sub_8216EA68+0x3AC on tid=1. One-shot at boot per game session — but the function itself contains an outer loop that iterates KeWaitForSingleObject waits until termination.

Static graph

• Static callers: sub_8216EA68+0x3AC via bl (sole).
• Direct callees: sub_822F13B0, sub_824AA2F0 (NtSetEvent wrapper), sub_82172370, sub_824AA3E0, sub_824C1910 (leaf), sub_824AA8B0, sub_82456B58, sub_824AA330 (KeWaitForSingleObject wrapper), sub_824574C0, sub_82457038, sub_8284E45C (kernel import thunk).
• Indirect: bctrl at PC 0x822F1B4C (vtable[0] of *(0x828E1F08)) and bctrl at PC 0x822F1D58 (vtable[2] of same).
• Reads 0x828E1F08 at PCs 0x822F1B3C, 0x822F1BE8, 0x822F1D40, 0x822F1E44, ... (11 reads).

Audit log

• AUDIT-065 (2026-05-12) — refined the dispatch-target understanding. The vtable[0] callee at PC 0x822F1B4C bctrl is sub_82175330 (2-insn tail-jump to sub_82173990). sub_82173990 is a synchronous task-spawn-and-join helper — not an outer game loop. Canary fires this function exactly 1× per boot (not 4040× as the synopsis previously suggested) — the 4040× metric in audit-064 referred to PCs downstream of sub_82173990's return into sub_822F1AA8's outer loop (PCs 0x822F1BCC/0x822F1D58/0x822F1DFC). Per AUDIT-065 sub_82173990 dossier, the wait at sub_82173990+0x2D0 IS a thread-join, and the body of sub_82173990 itself is clean — only the worker spawned via sub_821746B0 (which becomes ours's tid=13) is wedged inside sub_821CB030. [confirmed]
• AUDIT-064 (2026-05-12) — identified as the immediate dispatch chain origin for the 4-fn ladder leading to sub_825070F0. Disasm + ours fine-grained BB probes localize the wedge: tid=1 enters function (1×), passes through PCs 0x822F1ACC/0x822F1AEC/0x822F1B20/0x822F1B30/0x822F1B38, executes bctrl at PC 0x822F1B4C → sub_82175330 → sub_82173990 → KeWaitForSingleObject(handle=0x12A4 = tid=13 thread handle) → STALL. Canary instead returns from that wait and enters the outer game-loop body (0x822F1BCC fires 4040× in 60s). First divergence between canary and ours is at sub_82173990's wait inside vtable[0] of *(0x828E1F08) — same AUDIT-049 wedge. [confirmed]

Open questions

• The vptr at [0x40111890+0] mutates multiple times before the bctrl fires (writes from sub_82152XXX, sub_8244e850, sub_8244e8bc, sub_82155b4c, sub_82460c40, sub_822F2758, sub_8216F110, ...). Is the final value 0x820A183C (which has slot 0 = sub_82175330) the same as canary's final value? Run the same --mem-watch against canary to verify.
• Why does canary's tid=13 finish (allowing tid=1's join wait on handle 0x12A4 to complete) while ours's tid=13 stalls? That's the AUDIT-049 root question — separately tracked.

Cross-references

• Direct callers: sub_8216EA68+0x3AC.
• Callees of interest: sub_82173990 (via vtable[0] thunk sub_82175330) — where tid=1's stall occurs.
• Downstream (when activated): sub_82173990 → sub_821741C8 → sub_82172BA0 → sub_821B55D8 → sub_824F8398 → sub_824F7CD0 → sub_824F7800 → sub_825070F0.
• Object dispatch: *(0x828E1F08) = 0x40111890, vptr [0x40111890+0] = 0x820A183C (vtable), slot 0 = sub_82175330.
• Audits: 049 (the underlying wedge), 064.
• Artifacts: audit-runs/audit-064-activation-ladder/ours-fine-822F1AA8.stdout, ours-bb-822F1AA8.stdout, ours-vtable820a183c.stdout, ours-vptr-time.log, canary-inside-822F1AA8.log.