Skip to content

Game Crashes With Plenty of Free RAM: RADAR_PRE_LEAK and the Tiny System-Managed Pagefile

Date: 2026-07-12 Host: MajorRig (Windows 11, 64 GB RAM) Symptom: Game process (ACBlackFlag.exe) exits abruptly mid-session; no error dialog worth anything; system otherwise healthy.

TL;DR

A game crashed on a 64 GB machine because Windows had provisioned only a 4 GB system-managed pagefile, capping the commit limit at ~68 GB. A leaking 64-bit game hit the commit ceiling and died from failed allocations. The tell in the Event Log is a RADAR_PRE_LEAK WER event with no accompanying Event 1000. Fix: set an explicit 16–32 GB pagefile.

Diagnosis walkthrough

1. Pull recent crash events from the Application log

From WSL2 (note: single-quote the PowerShell command in bash, or $_ gets mangled by the shell):

powershell.exe -NoProfile -Command 'Get-WinEvent -FilterHashtable @{LogName="Application"; Id=1000,1001; StartTime=(Get-Date).AddHours(-6)} -MaxEvents 8 | ForEach-Object { "=== $($_.TimeCreated) | Id $($_.Id) ==="; $_.Message.Substring(0,[Math]::Min(500,$_.Message.Length)) }'
  • Event ID 1000 (Application Error) = classic crash with an exception code and faulting module.
  • Event ID 1001 (Windows Error Reporting) = WER report; the Event Name field carries the bucket type.

2. Read the signature

The crash produced this and only this:

Event Name: RADAR_PRE_LEAK_64
P1: ACBlackFlag.exe

RADAR is Windows' Resource Exhaustion Detection and Resolution subsystem. It fires as system commit charge approaches the limit and names the process whose private memory is growing abnormally — i.e. the presumed leaker.

The combination to recognize:

Evidence Meaning
RADAR_PRE_LEAK_* naming the process System was running out of commit; this process was the top grower
No Event 1000 for the same process It didn't fault on bad code — its allocations started failing and it went down "quietly"

That combination = death by commit exhaustion, not a conventional bug-triggered crash.

3. Check why commit ran out

powershell.exe -NoProfile -Command 'Get-CimInstance Win32_OperatingSystem | ForEach-Object { "TotalRAM_GB: " + [math]::Round($_.TotalVisibleMemorySize/1MB,1); "CommitLimit_GB: " + [math]::Round($_.TotalVirtualMemorySize/1MB,1) }'

Result on MajorRig: 63.9 GB RAM, 67.9 GB commit limit → the pagefile was only ~4 GB.

powershell.exe -NoProfile -Command '"Auto: " + (Get-CimInstance Win32_ComputerSystem).AutomaticManagedPagefile; Get-CimInstance Win32_PageFileUsage | ForEach-Object { "$($_.Name) Allocated=$($_.AllocatedBaseSize)MB" }'

Confirmed: AutomaticManagedPagefile: True, C:\pagefile.sys Allocated=4096MB.

The counter-intuitive part

More RAM can mean a smaller safety net. "System-managed" sizes the pagefile to observed demand, and a 64 GB box rarely pages — so Windows keeps the file tiny. The commit limit ends up barely above physical RAM. One leaking process (plus, here, WSL2 holding its own slice) eats the entire margin, and the pagefile can't grow fast enough during a rapid leak. On a 16 GB machine the same leak would have had a proportionally bigger cushion.

Fix

Set an explicit pagefile — 16 GB initial / 32 GB max is a sane gaming-rig baseline. Via elevated PowerShell:

$cs = Get-CimInstance Win32_ComputerSystem
Set-CimInstance -InputObject $cs -Property @{AutomaticManagedPagefile = $false}
$pf = Get-CimInstance Win32_PageFileSetting | Where-Object { $_.Name -like "C:*" }
if (-not $pf) {
    New-CimInstance -ClassName Win32_PageFileSetting -Property @{Name = "C:\pagefile.sys"} | Out-Null
    $pf = Get-CimInstance Win32_PageFileSetting | Where-Object { $_.Name -like "C:*" }
}
Set-CimInstance -InputObject $pf -Property @{InitialSize = 16384; MaximumSize = 32768}

A reboot is required — pagefile sizing only applies at boot. Afterwards the commit limit reads RAM + max pagefile (~96 GB here).

From WSL2, run the script elevated with Start-Process powershell.exe -Verb RunAs -ArgumentList ... and have the script write its result to a file in $env:TEMP — the elevated process' stdout is not visible to the WSL caller.

If it crashes again anyway

With a real commit cushion in place, a repeat RADAR_PRE_LEAK against the same game means the game itself leaks:

  • Check the publisher's patch notes for memory-leak fixes.
  • The WER report folders (C:\ProgramData\Microsoft\Windows\WER\Report{Archive,Queue}) will have more to dig into on the next occurrence.
  • Optionally cap WSL2 in %USERPROFILE%\.wslconfig (memory=16GB) so it doesn't compete during gaming sessions.