b24264ef5c
Rebuilt canary twice to test the freeze, and the result demotes my own headline. 1. The game does not size anything from MmQueryStatistics. Xenia reports kernel_pages = 1 MB under a comment admitting the numbers are guessed, and the game really does call the export -- sub_82612420 converts total_physical_pages and title.available_pages to bytes, and its caller holds available-bytes in r23 while creating render surfaces. Patched it to 32 MB, twice the shortfall, and rebuilt: 122 allocations, 484.5 MB ever, 379.5 MB live in 84 blocks, failing at "free 28969/131072" -- byte-identical to stock. A 32x change moved nothing. Refuted; reverted. 2. The ~19 MB the ledger could not see is Xenia's own startup reservation: memory.cc:240 pins 16 MB of the parent heap for GPU writeback before the guest runs, and vC0000000's parent IS the 512 MB physical heap. 16 MB is more than the 14.84 MB shortfall. 3. Shrinking that reservation to 1 MB removes the failure completely -- zero AllocRange failures, zero guest throws -- AND THE GAME STILL FREEZES. Verified with a single emulator after killing the stale one: three frames at rmse 0.00, an 8 MB guest slab unchanged over 3 s, 389% CPU on 3 running threads. The ledger shows it dying EARLIER, stopping at the 32 MB doubling step where stock reached 64 MB, so shrinking a live GPU region hangs the GPU instead. Reverted. So "the freeze is the refused 128 MB allocation" was too strong. The refusal is real and Xenia's 16 MB reservation is the swing factor that decides it, but the guest hangs without it too, at an earlier point. The refusal is one way this stage load dies, not the cause. Also recorded: --eh_dispatch, --mem_watch and --audio are all named in this corpus's own scripts and docs and NONE exists in this build. Each is silently rejected, which blocks boot rather than warning.