Logo

Diagnose and resolve a FiveM crash

Diagnose and resolve a FiveM crash

When your FiveM server crashes, the logs usually say everything. You just need to know where to look and how to read the stack trace. This guide covers the most common crash patterns, txAdmin and CitizenFX log analysis, and concrete solutions.

Introduction

A FiveM crash can come from:

  • A broken resource (Lua/JS script that throws, missing dependency)
  • A corrupted or outdated artifact
  • A memory leak (OOM kill by the kernel)
  • A MySQL crash (loss of oxmysql connection)
  • An assertion failed in Cfx native
  • A corrupted anti-cheat or ESX/QB

This guide gives you the methodology to identify the cause in under 10 minutes.

Step 1: Precisely identify the crash moment

Before diving into logs, ask yourself:

  • Does the crash happen at startup or during gameplay?
  • Is there a pattern (a specific event, command, used script)?
  • How many players were connected?
  • Did it happen after an update (artifact, resource, etc.)?

Is the crash on a consistent delay (always after X hours = memory leak) or random (often a buggy resource)?

Step 2: Inspect txAdmin logs

txAdmin keeps crash history:

txAdmin Panel → System → Logs

You'll see:

  • Server Log: FiveM console logs
  • Action Log: admin actions (ban, kick, etc.)
  • CrashHandler Log: crash-specific info

Look for the line just before the crash:

[script:RESOURCE] SCRIPT ERROR: @resource/server.lua:42: attempt to index a nil value

This tells you immediately:

  • Which resource crashed (RESOURCE)
  • Which file (server.lua line 42)
  • What error (attempt to index a nil value)

Step 3: Enable verbose mode in server.cfg

Add these lines to server.cfg for more detail:

# General verbose
sv_debugQueue 1
sv_enforceGameBuild 2944  # or newer
set onesync on
set sv_debugScripts true

# Hang logs (long freezes)
set sv_scriptHookAllowed 0

Restart the server.

Step 4: Concrete case — "Couldn't load resource"

Couldn't load resource oxmysql: failure to load schema

Cause: the oxmysql resource doesn't load, usually due to a wrong Node.js version (oxmysql 2.x requires Node 18+) or a malformed MySQL connection string.

Solution:

# Verify MariaDB is reachable
sudo systemctl status mariadb
mysql -u fivem -p -e "SELECT 1;"

Inspect the connection string in server.cfg:

set mysql_connection_string "server=localhost;database=fivem;userid=fivem;password=Password"

Watch out for special characters in the password (@, !, & etc.): they must be URL-encoded or escaped.

Step 5: Concrete case — "FX has hung"

The server has been running for 60 seconds without responding.

Cause: a script blocks the main thread (infinite loop, blocking synchronous operation, I/O block).

Solution: isolate the faulty resource.

  1. Start the server without any custom resource (comment all ensure lines in server.cfg)
  2. Start resources one by one watching the console
  3. The resource that triggers the hang is identified

Step 6: Concrete case — OOM crash (out of memory)

On Linux, check:

sudo dmesg | grep -i "killed process"

If you see:

Out of memory: Killed process 1234 (FXServer)

Cause: your VPS doesn't have enough RAM. FiveM typically uses:

  • 1 GB for base server
  • 2 GB with ESX/QBCore
  • 4-8 GB with 32+ players and many resources

Solution: upgrade to a VPS with more RAM (VeryCloud offers Ryzen VPS from 8 GB to 16 GB for these uses).

In the meantime, add swap:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Step 7: Concrete case — artifact crash

FXServer.exe has triggered a breakpoint.

Cause: the FiveM artifact is buggy or incompatible with your OS.

Solution: change artifact build.

  1. Go to https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/
  2. Avoid the very latest build (latest), take the one marked recommended (usually 2-3 builds back, more stable)
  3. Download and replace:
cd ~/server
rm -rf alpine FXServer run.sh
wget https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/XXXX-XXXX/fx.tar.xz
tar xf fx.tar.xz && rm fx.tar.xz

Step 8: Concrete case — "C-stack overflow" error

sol3 / C-stack overflow

Cause: a Lua resource makes recursive calls without stop condition.

Solution: almost always a custom resource. Disable them one by one (see step 5) until you find the culprit. Then inspect the Lua code and look for unbounded loops.

Step 9: Analyze minidump files

FiveM generates minidumps during critical crashes. On Linux:

ls -lh ~/.fivem/data/cache/
ls -lh ~/.fivem/data/server-cache-priv/CitizenFX_Server_*.dmp

These files can be opened with gdb:

sudo apt install -y gdb
gdb ~/server/FXServer ~/.fivem/data/server-cache-priv/CitizenFX_Server_XXXX.dmp
(gdb) bt

The stack trace shows the native that crashed. If the crash comes from a Cfx native function, open a ticket on https://forum.cfx.re with the dump.

Step 10: Complementary tools

txAdmin Live Console

The live console is your best friend: it displays Lua errors in real-time without having to parse log files.

Built-in FiveM profiler

Type in the server console:

profiler record 1000

After 1000 frames, type:

profiler view

You get the resources consuming the most CPU.

Slow resource inspection

In the console:

resmon

Shows a real-time CPU/memory dashboard per resource.

MySQL-specific error troubleshooting

"User space is full"

This error occurs when you have more tables / columns per user than InnoDB's default limit. Solution:

SET GLOBAL innodb_file_per_table = ON;
ALTER TABLE table_name ROW_FORMAT=DYNAMIC;

Or increase the limit in /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M

Restart MariaDB:

sudo systemctl restart mariadb

"Too many connections"

ERROR 1040 (HY000): Too many connections

Increase in /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
max_connections = 500

Useful commands

# Live logs
sudo journalctl -u fivem -f

# CPU/RAM usage per process
top -p $(pgrep -f FXServer)

# Memory used by FiveM
ps -o pid,user,%mem,rss,command -p $(pgrep -f FXServer)

# Test MySQL connectivity from fivem user
sudo -u fivem mysql -u fivem -p -e "SELECT 1;"

# View latest system crashes
sudo dmesg | tail -50

# Check disk space (a full disk crashes FiveM)
df -h

Conclusion

90% of FiveM crashes are resolved by following this methodology:

  1. Identify the moment (startup / runtime / OOM)
  2. Read txAdmin logs
  3. Disable resources one by one if needed
  4. Check MySQL and RAM
  5. Update artifacts if nothing works

For really complex cases, the VeryCloud support team helps diagnose (open a ticket with the last 100 log lines + context).

Resources

Join our Discord community server

For any questions, suggestions, or just to chat with the community, join us on Discord!

900+Members