d8f0a5e798
Four runs now freeze at the first content load after the main menu with three different allocation outcomes: stock (fails at 128 MB and throws), GPU-writeback patched (no failure, stops at 32 MB), heavy XMA logging (no failure, stops at 16 MB), and no-savegame (no failure, no throw). The memory account on this page is accurate but describes a symptom; everything treating the 128 MB refusal as the freeze is superseded. The savegame is not the variable. --content_root pointed at a profile-only tree (the real content untouched) boots to the identical pools -- BC220000 Size 03A80000 and B50C0000 Size 070E0000, same addresses and sizes, same 43 allocations by the menu -- then freezes at the same press with zero failures. Not slow shader compilation either. Every earlier run called it frozen within ~30 s; this one was left six minutes at 0.00% liveness with CPU still 399-479%. Correction made mid-measurement: the allocation counter creeping 119->124 looked like "guest running, display stuck". It is not. A broad sample -- 400 extents, 8.2 MB -- changed 18 bytes in 3 seconds. The guest is spinning, with one thread allocating about once a minute. The earlier "8 MB slab unchanged" reading was weak for the same reason in reverse: one arbitrary region proves little. Sample broadly before calling a guest alive or dead, exactly as the screen needed two frames rather than one. Now excluded: the heap failure, the leak, rounding, MmQueryStatistics, a heap-size knob, the exception cvar, a kernel-object wait, a build regression, the route, the savegame, and shader compilation.