client crash — jupiter-pizza-ceiling / GTA5_b3258.exe+FEAC59

FiveM Server Development ES/ESX
, , ,
1

Need help identifying a persistent client crash — jupiter-pizza-ceiling / GTA5_b3258.exe+FEAC59

Hey all, hoping someone can help me pin this down. I’ve been chasing a crash on my ESX + ox_inventory server for most of today and I’ve ruled out a lot, but the actual root cause is still escaping me.

Server setup: ESX (es_extended), ox_inventory, ox_lib, ox_core, ox_target. Game build 3258, server artifact 35245.

The crash:

  • Hash: jupiter-pizza-ceiling
  • Address: GTA5_b3258.exe+FEAC59
  • Same stack trace every single time (8 crash dumps collected today, all identical):
GTA5_b3258.exe+FEAC59
GTA5_b3258.exe+FEA0DF
GTA5_b3258.exe+F1F5AA
GTA5_b3258.exe+F45C6A
GTA5_b3258.exe+F45EF6
GTA5_b3258.exe+F85354
gta-core-five.dll+8760F

Timing: Always 14–16 seconds after “Script initialization finished” in the client log, right after Connecting to mumble, setting targets. and Finished connection logic show up. Players are crashing before they even reach our character selection screen — it’s happening during the initial connect/spawn sequence itself, not while walking around or entering any specific location.

What I’ve already ruled out (with before/after crash-dump confirmation for each):

  • Duplicate weapon registrations across 19 custom weapon-pack resources (found and fixed 3 duplicate WEAPON_ keys + 10 conflicting component defs)
  • A syntax error in ox_inventory’s weapons.lua that broke the whole inventory system
  • Several custom MLO resources bundling unrelated vanilla map files and corrupted audio .rel files (this caused a different crash, fruit-spaghetti-berlin, which is now resolved separately)
  • A stray leftover vanilla heist file in our default-spawn MLO resource (the very first location every connecting player streams through)
  • Attempted disabling our anti-cheat resource (currently broken/expired license) as a test — inconclusive so far, still working out why the config change isn’t taking effect on restart

None of the above stopped this specific crash. Given the timing lines up with the exact moment a player’s character gets placed into the world (not location-specific), I’m now suspecting something in the ped/character spawn process itself — but I can’t pin down which resource from client logs alone.

Attached: 3 crash dumps, all from today, all after the fixes above — same hash/stack trace in every one.

Would really appreciate any pointers on how to dig deeper into this, or if anyone’s seen this exact crash address before and knows what it typically points to. Happy to provide more logs/dumps if useful.