Apex Speed Craft

The game keeps vanishing to the desktop — no error, no dialog, just gone. We got tired of guessing, built a monitoring tool, and watched the crash happen in real time. Here’s what we found, what you can do today, and what actually needs fixing.

TL;DR

• The crash happens during the game’s “optimizing shaders for your PC” pass. On our test machine it leaked memory at roughly 55 MB/s until the game hit an internal ~16 GB wall and quietly shut itself down.
• We know what the leaked memory is. A live memory snapshot taken mid-leak shows it’s D3D12 upload heaps — GPU staging buffers, mostly identical 64 MB blocks, allocated in a loop and never freed. Seven gigabytes of them and climbing at the moment of the snapshot.
• It’s a silent exit (code 0): no error dialog, no Event Log entry, no crash dump. The game doesn’t even think it crashed.
• The usual advice — delete shader cache, verify files, reinstall drivers — didn’t apply to what we measured. The game never wrote a single byte to its shader cache during the leak.
• We tested the obvious workaround — raising the NVIDIA driver shader cache size to 10 GB — and it changed nothing: the driver cache never grew, and the crash was identical.
• We confirmed a workaround with 20 minutes of telemetry: changing the game’s language in the options menu (which forces an automatic restart) yields a session that survives well past the crash window. The nuance our own instrument caught: it does not prevent the bloat — the game still balloons to ~16.85 GB, but this time it plateaus and stabilizes instead of running off the cliff. On a GPU with less headroom than our 16 GB card, that plateau might still be too much. The real fix is still on Playground.

The symptom

Game launches fine. Menus fine. Then the shader optimization step kicks in and, 2–15 minutes later depending on your hardware, the game silently closes. Community threads report the same pattern across wildly different rigs — AMD and NVIDIA, fresh Windows installs, every driver version — which is usually the signature of a software bug, not a broken PC. Some players see error codes (FHD01, FHE01, FHF01); many see nothing at all.

What’s actually happening (measured, not guessed)

We ran a telemetry monitor alongside the game — sampling GPU memory, process memory, network connections, and shader-cache disk activity every two seconds. On an RTX 5070 Ti / 32 GB RAM machine, one session told the whole story:

• T+0:00 — T+1:30Perfectly healthy. Loading completes, memory settles at 1.4 GB of VRAM, online services connect.
• T+1:33The shader optimization pass starts — and memory explodes. VRAM jumps from 1.4 GB to 4.4 GB in two seconds, then climbs relentlessly at ~55 MB/s.
• T+3:15Committed memory hits ~16.4 GB and growth stops. The allocator is done getting more.
• T+3:35 — CRASHThe game exits with code 0 — the “everything is fine” code. No dialog. No event log. Nothing.

Three things it wasn’t, on this machine:

1. Not a network/disconnect issue. Connections to the game’s online services stayed up until the very end. (Some players separately report disconnect-related crashes — that may be a different bug, or a different face of this one.)
2. Not a corrupt shader cache. The game’s shader cache folder was completely untouched during the leak — zero writes. This is the damning detail: the optimization pass never saves its work. That’s why it runs again on every launch, and why deleting the cache changes nothing. Worse than nothing: since the pass leaks, forcing extra recompilation feeds the leak.
3. Not your hardware failing. At the moment of death the machine had 9.5 GB of RAM free and 6 GB of VRAM headroom. The game gave up on itself.

One more spicy detail from the game’s own diagnostic files: it identified the RTX 5070 Ti as a plain “RTX 5070” hardware profile. A near-miss hardware classification feeding a per-PC optimization pass is exactly the kind of thing that sends code down a broken path — we can’t confirm that’s the trigger, but Playground’s engineers should look there.

What exactly is leaking — the autopsy

Because the game exits “cleanly,” Windows never writes a crash dump — so our monitor takes its own snapshot of the live process the moment memory crosses 12 GB, while the leak is still running. We reproduced the crash a second time (identical signature, to the second) and caught it in the act. The snapshot’s memory map is unambiguous:

• Of ~12 GB committed at snapshot time, 7.1 GB was write-combined memory — the unmistakable fingerprint of D3D12 upload heaps, the CPU-visible staging buffers a game uses to push shaders, textures, and pipeline data to the GPU. A healthy title carries a few hundred megabytes of these. By the moment of death it was 9.6 GB, up from 1.3 GB before the optimization pass began.
• The allocation list reads like a bug reproducing itself in slow motion: dozens of identical 64 MB write-combined blocks, plus scattered 96–148 MB ones — 185 allocations in the 16–256 MB range totaling 7 GB. Something allocates a staging buffer per shader batch and releases none of them.
• Total memory regions tripled during the leak, from ~6,500 to ~19,000.

So the one-sentence bug report an engine programmer can act on: during the “optimizing shaders for your PC” pass, the game allocates D3D12 upload heaps — predominantly 64 MB write-combined blocks — at ~55 MB/s, never releases them, and self-terminates silently (exit code 0) at roughly 16 GB committed.

What about workarounds?

1. The one that works (with a caveat): change the game’s language

Change the game language in the options menu; the game auto-restarts, and the restarted session survives. We confirmed this with 20 straight minutes of telemetry — comfortably past the ~3.5-minute death window that killed three prior runs.

Here’s the honest part, because the telemetry surprised us and overturned our first guess: the restart does not skip the leak. The game still balloons to ~16.85 GB committed, ~10.3 GB of it upload heaps — the same bloat as the crash runs. The difference is that this time the growth plateaus and stops, and the game stabilizes and keeps running, instead of climbing until it dies. It looks like the restarted run lets the optimization pass run to completion, whereas a fresh launch gets stuck allocating until it crashes mid-pass. Why the restart changes that, we can’t yet prove — it’s three-for-three crashes on a normal launch versus one-for-one survival via the language change, suggestive but not proof. Two practical caveats: the surviving session holds ~10 GB of VRAM the whole time, so on a smaller GPU that plateau alone might exceed your VRAM; and you’ll likely need to redo it after game or driver updates re-trigger the pass.

2. The shader-cache-size theory: tested, and busted

We initially suspected NVIDIA’s driver shader cache (pinned at ~1 GB on our machine) was starving the pass and forcing endless recompilation. So we tested it: raised the cap to 10 GB and ran the crash again. Result — the driver cache didn’t grow by a single megabyte, and the game died on the exact same schedule. The driver was never the bottleneck; the leak is entirely inside the game’s staging-buffer lifecycle. We’re leaving this section in because half the guides on the internet recommend cache tweaks for this crash, and our data says they’re a placebo.

3. If you’re on the Steam beta client, opt out

Steam → Settings → Interface → Client Beta Participation → “No beta chosen.” At least one player with the silent-crash pattern reported this fixed it entirely. It did not apply to our machine — we weren’t enrolled and crashed anyway — but it costs you nothing to check.

4. Skip the folklore

Deleting shader caches, verifying files, unplugging controllers, uninstalling random apps — by all means try them, they’re harmless. But our measurements suggest none of them touch this particular bug, so don’t reinstall Windows over it.

How to deal with it (when it happens anyway)

The cruel part of a silent crash is that it leaves nothing behind — support asks for logs and you have none. That’s fixable:

• Measure, don’t describe. We’ve built our monitor, ShaderDebug, to run alongside the game and produce a full incident report on every crash: second-by-second memory/network/cache telemetry, your hardware fingerprint, and — because the game exits “cleanly” and Windows crash reporting never fires — a live memory snapshot taken before the game gives up. (Release link coming when the repo goes public.)
• File a real ticket. A report to Forza Support that says “crashes after 3 minutes” gets a template reply. One that says “the game leaks D3D12 upload heaps (64 MB write-combined blocks) at ~55 MB/s during shader optimization, exits silently with code 0 at 16.4 GB committed, shader cache receives zero writes, game build 6.382.893.0, driver 32.0.16.1074, telemetry CSV and memory-map analysis attached” gets escalated. Data moves tickets.

How it should be fixed

For Playground Games / Turn 10, the telemetry points at five concrete engineering items:

1. Fix the upload-heap lifecycle. The memory snapshot shows staging buffers allocated per batch and never released. Release each upload heap once its copy completes — or better, reuse a small ring of them. This is the leak itself; everything else below is defense in depth.
2. Bound the optimization pass. Compile shaders in batches with a memory budget; release intermediate blobs as you go. A per-PC optimization step should never be able to allocate 16 GB.
3. Persist progress. The pass writes nothing to disk until it finishes — so a crash at 95% means starting from zero next launch, forever. Checkpoint completed work so every launch makes progress, and one bad session doesn’t become a permanent crash loop.
4. Fail loudly. Exiting with code 0 on an allocation failure is the worst possible behavior: no dialog for the player, no dump for Windows Error Reporting, no signal for support triage. Detect the failure, write the crash report the game already knows how to write, and tell the player what happened.
5. Fix hardware profile matching. New GPUs ship constantly; a lookup that maps a 5070 Ti to a 5070 profile today will map next year’s cards to nothing at all. Fuzzy-match conservatively and log the mismatch.

And one for NVIDIA: modern titles ship shader sets that don’t fit in a 1 GB driver cache. If the effective default is still that small on some configurations, that’s a footgun for every big game, not just this one.

The bottom line

This isn’t your PC, your drivers, or your shader cache. It’s a game bug — a D3D12 upload-heap leak in the shader optimization pass, caught on camera three times with identical signatures, made invisible by a silent failure path, and made recurring by the fact that the pass never saves its work. We tested the popular workarounds against real telemetry and they don’t touch it; the one thing that helps is the language-change restart, which — surprisingly — doesn’t stop the bloat but lets it plateau instead of crash. Until Playground patches it properly: try the language trick, and if you want to help get it fixed, capture data and send it where it counts.