Home/Blog/FiveM
// blog · fivem

Hunting a FiveM client crash: a CEF/NUI story

July 5, 2026 · by Wax

The hardest bugs in FiveM aren’t the ones that throw an error. They’re the ones where a player’s game silently vanishes to desktop, no message, no console line, no pattern they can describe beyond “it just closed.” We had a run of those. Here’s how I cornered it, because the method matters more than the specific culprit.

Rule one: a crash without an error is a memory or a native problem

When something throws a Lua error, you get a stack and a resource name — that’s an easy day. A silent client crash-to-desktop almost always means the game engine itself died, not a script. That points you at a short list: a bad native call, a corrupt streamed asset, or memory pressure — frequently from the browser layer that powers NUI. Knowing that reframes the hunt from “read the logs” (there are none) to “bisect the resources.”

The bisection, done properly

You cannot fix what you can’t reproduce, and you can’t bisect a city by vibes. I split the resource list in half, ran a session, and watched for the crash signature — then halved the suspect group again. It’s tedious and it’s the only thing that actually works. The trap is changing two variables at once; discipline here is the whole game. Within a few rounds the crashes clustered around one CEF/NUI-heavy resource under load.

Why CEF/NUI is a repeat offender

NUI runs on an embedded Chromium instance (CEF). Every heavy in-game UI — a tablet, a cinema screen, a fancy HUD — is a little browser. Browsers eat memory. Stack several alongside a big streaming budget and you can push a client’s memory past the edge, and the machines that fall off that edge first are exactly your lowest-spec players. The crash wasn’t “a bug in one line” so much as one resource being the straw on top of an already-loaded camel — which is why the streaming cleanup I did earlier was part of the fix, not a separate project.

The fix, and the boring prevention

Two-pronged: reduce the resource’s memory behavior (tear down the browser context when the UI isn’t on screen instead of leaving it resident), and lower the ambient pressure it was tipping over. Crashes stopped. The prevention going forward is unglamorous — a memory budget you actually watch, and skepticism toward any resource that keeps a CEF context alive permanently.

If you’re staring at silent crashes and a player base thinning out because of it, that’s squarely the kind of forensic work I do — and it starts with the same bisection, not a guess. The broader diagnosis order lives in my performance guide.