TL;DR: Frame freezes of 0.1–2.6 seconds during matches, mid-fight, while looting, at match start and on lobby return. I instrumented the game with PresentMon and a custom lightweight ETW trace. The game thread stalls executing its own code with heavy Windows memory-management work underneath (VM decommit + soft page faults). The GPU sits idle, nothing is read from disk, and the thread is never preempted — it owns a core the entire time. This looks like Unreal's Garbage Collection or an internal pool rebuild, and I'd love input from people who know UE internals.
The problem. For the last few months, Fortnite freezes for a split second or — at worst — for 2.6 full seconds at unpredictable moments. It happens everywhere: mid-fight, while looting, when a match starts, when I return to the lobby. My hardware is: Ryzen 5 7600X, RTX 4060 8GB, 32GB DDR5, 180Hz 1080p, game on NVMe, Performance Mode (DX11/ES31) with low textures. If you're not technical: think of it as the game's "cook" stopping to do a full inventory of the pantry instead of serving the next dish.
How I measured it. I treated it like a production incident instead of guessing. PresentMon recorded the timing of every single frame (86,224 frames across a lobby session and a full match). In parallel, a custom Windows ETW trace recorded what the CPU was doing per thread, every context switch, every wait, every disk read and every driver interrupt — for about four minutes during a real match. I validated the tracing overhead first with an A/B test: average frametime went from 8.37ms to 8.41ms with tracing on, so the data describes the real game, not the observer. A first attempt with the default Windows profiles produced 37GB and visibly degraded the game, so I built a profile that's roughly 1/40th of that.
What the worst freeze (2596ms) looks like inside. The frame that stuttered reported CPUBusy 2595ms and GPUBusy 7.7ms — the GPU did almost nothing and waited for the CPU. The game thread first spent ~0.7s in rapid wait/wake cycles (hundreds of sync-object waits per second), then ran continuously for 1.6 seconds without being interrupted once. During that run, its time inside Windows' memory manager exploded: kernel functions like KiPageFault and MiDecommitAddToList (which releases physical memory back) dominate the samples, versus nearly zero in normal gameplay. Meanwhile the RHI and render threads dropped to almost nothing — everything in the game waits behind the game thread. Disk activity during the whole stall: 13 hard faults, 1.6ms of I/O total, so nothing was being streamed.
The phase I cross-referenced every stutter I felt with the trace. In the traced match the biggest hits landed on match start and looting, but fights are affected too, same symptom, same feeling, different session. What matters is that every freeze I could cross-reference maps to the same anomaly on the same thread, so I'm treating this as one mechanism, not several.
What it is NOT; each ruled out by data: the GPU and its driver (7ms of work in a 2.6s frame), disk streaming (no reads), scheduler contention (the thread was never preempted), DPC storms, RAM pressure (no hard-fault spikes, 32GB installed). EasyAntiCheat appears in the samples but accounts for about 2%.
My read: this is Unreal Engine's Garbage Collection or an internal memory pool rebuild — a batch of objects gets destroyed, memory gets decommitted, then soft page faults refill it. It started after a recent Fortnite update, which is why I don't believe it's my hardware: failing RAM or a sick CPU don't produce clean, repeatable 2-second stalls, they produce crashes.
Questions:
UE devs: does kernel KiPageFault + MiDecommitAddToList under a sustained, unsymbolized game-thread stall match the GC-purge signature? What else produces exactly this?
Anyone else on high-end hardware getting 1–3s freezes specifically on match start, looting, mid fight or anything else ?
Did anything change in Fortnite's GC or streaming behavior in recent seasons?
I have the full trace data, the custom WPR profile and the analysis scripts, happy to share details. I haven't touched a single config file, and I'm not expecting a reinstall to change code behavior — but if you have a fix that survives measurement, I'm all ears.