(Even Though the Injector Succeeds)
When RenderDoc Pro attaches cleanly but the game crashes the moment you press Capture, the debugger itself is rarely at fault.
In almost every real-world case the crash is a plain-old out-of-memory (OOM) condition triggered by how Direct3D 11/12 has to stage GPU resources on the CPU side for serialization.
Below is a focused look at what actually happens, why it overwhelms ordinary machines, and what you can do about it.
1. What Happens Under the Hood (DX12)
- Per-resource backup heaps
RenderDoc allocates memory for every resources in GPU, and put in to CPU accessable memory regions. - Full-frame resource copy
As soon as the memory exist, every alive GPU resource (textures, buffers, acceleration structures, etc.) is copied into those memorys viaCopyResource/CopyBufferRegion. - Deferred release
The heaps are not released untilEndFrameCapture(). For a few frames you temporarily hold two copies of every asset: one resident on the GPU, one resident (or committed for residency) in system memory + pagefile.
For example, on a title shipping with 30 GB of textures and buffers, a 16 GB workstation simply cannot commit that much backing store. Windows raises an allocation failure, the D3D driver bubbles it up as E_OUTOFMEMORY, and the game tears down—sometimes gracefully, sometimes as a hard crash.
2. Proven Work-arounds
2.1 Increase Your Pagefile
The simplest fix is purely operational: set the paging file to something enormous (e.g. 64–128 GB). The capture still writes every byte to disk, but Windows can happily swap the cold pages out instead of failing the commit. Zero code, immediate relief.
2.2 Disable “Ref All Resources”
In RenderDoc’s Capture Options uncheck Reference All Resources. RenderDoc will then only back up the resources the GPU actually referenced at least once inside the frame, not everything that merely exists. Many scenes touch a fraction of the resident pool.
2.3 Release Cold Assets Programmatically
If you own the game code, free large, seldom-used resources (e.g. menu cinematics, unused vertex caches) right before you trigger the capture. They will reload on demand once capture ends.
3. A Reality Check on Hardware Requirements
“If RenderDoc Pro is loaded successfully, but the game crashes after you press Capture, then this is not a RenderDoc bug.
A modern AAA frame can weigh tens of gigabytes of data. If you want to capture it, you need a workstation that can host it.”
For an ultra-heavy scene (think The Last of Us Part II, photogrammetry everywhere) a 128 GB RAM box is genuinely “reasonable.” Professional capture rigs in major studios routinely carry 128–256 GB RAM plus a matching pagefile on fast SSDs. If you are developing or dissecting such titles, budgeting for a heavier dev PC is simply part of the tooling cost.
4. Checklist Before You Blame RenderDoc
- Confirm the crash call-stack—
E_OUTOFMEMORYin the D3D runtime or driver is the smoking gun. - Look at Commit Size in Task Manager while you reproduce the issue; watch it spike right before the crash.
- Sanity-check the pagefile size. “System managed” is often too small for capture workloads; set it manually.
- Disable Ref All Resources and try again.
- Move the capture point earlier or on a lighter scene.
- If capture succeeds on a 128 GB machine but not on 32 GB, the diagnosis is confirmed.
5. Key Take-aways
- The capture path copies every live GPU resource into CPU memory, doubling the footprint for a few frames.
- Windows must commit those pages first, then it may swap them out. If commit fails, the game collapses.
- File-mapping heaps or driver residency hacks do not reduce the commit requirement.
- The only robust answers are more virtual memory (bigger pagefile or more RAM) or less to capture (earlier trigger, selective resource capture, custom streaming).
Invest a few minutes in the checklist above before diving into source-level debugging: 90 % of “RenderDoc makes my game crash” reports vanish once the machine has enough swap space to breathe.
发表回复