How to Find Which Plugin Is Crashing Your Server

April 22, 2026 Daemon666 8 min read 9 views

The server crashes, restarts, crashes again, and you have thirty plugins. Guessing wastes an evening; bisection finds the culprit in a handful of restarts. The method is the same whether the crash is a hard segfault, a map-change abort, or a slow degradation: read what the logs already told you, then halve the plugin list until one plugin is left holding the knife.

1. Read the logs before you touch anything

The engine and AMXX often name the plugin for free. Look in:

ls -t addons/amxmodx/logs/
cat addons/amxmodx/logs/L*.log | tail -50

And the engine's own output — hlds_run writes a crash file:

cat debug.log
ls -la core*   # a core dump, if one was written

AMXX errors look like Run time error 10: native error or a specific plugin name with a line number. If a plugin is named right before the crash, start there — you may skip the whole bisection.

2. Reproduce it reliably

You cannot bisect a crash you cannot trigger. Note exactly what causes it: a specific map change, a player action, a command, a certain player count, or simply "within N minutes". A crash on changelevel is often a precache or delta problem; a crash on a player action points at the plugin handling that action. Write the trigger down — you will run it after every step.

3. Halve the plugin list

Open addons/amxmodx/configs/plugins.ini. Comment out the bottom half with a semicolon:

; disabled for bisection
; zombie.amxx
; shop.amxx
statsx.amxx
adminmenu.amxx

Restart, reproduce the trigger. If it still crashes, the culprit is in the enabled half; if it stops, it is in the disabled half. Re-enable/disable to keep halving the guilty half. With thirty plugins you reach one plugin in about five rounds. This is far faster than disabling one plugin at a time.

4. Don't forget Metamod plugins and modules

Not everything is in plugins.ini. Metamod plugins (ReAPI, some anti-cheats, custom modules) live in addons/metamod/plugins.ini, and AMXX modules load from configs/modules.ini. If halving AMXX plugins never stops the crash, bisect those lists too:

meta list
amxx modules

A crash that survives disabling every AMXX plugin is either a module, a Metamod plugin, the game DLL, or the map — which is a useful result, because it clears a whole category.

5. Separate plugin crashes from engine/map crashes

If the crash reproduces with a completely empty plugins.ini, it is not an AMXX plugin. Now the suspects are the engine, the game DLL, delta.lst, or a specific map. A changelevel crash with no plugins usually means a bad precache/overflow or a mismatched ReGameDLL delta.lst. Test on a stock map like de_dust2 to rule the map in or out.

6. Turn on more detail before the next bisection round

You want the maximum information from each crash so you need fewer rounds. Two levers help. Raise AMXX's log verbosity so runtime errors are written with a stack, and keep the engine's console output where you can read it:

amx_logging 2
developer 1

A JIT-related crash sometimes only reproduces with the AMXX JIT on; if a plugin crashes hard with no useful log, temporarily disabling the JIT can turn a silent segfault into a readable runtime error that names the plugin and line. Do this on a staging server, never by experimenting on the live one — the whole point is to stop crashing the box players are on. Once you have the plugin, put the settings back.

Common errors

  • Bisection points nowhere — you re-enabled the wrong half, or the crash is timing-dependent. Reproduce more carefully and keep the trigger identical each round.
  • Two plugins crash only together — rare but real (a shared entity or hook conflict). If halving is inconsistent, test suspect pairs.
  • Crash survives an empty plugins.ini — it is a module, Metamod plugin, game DLL, or map, not an AMXX plugin.
  • Only crashes with players on — a per-client code path. Note which action precedes it; that names the subsystem.

Verification

Once one plugin is isolated, prove it both ways: run the server with only that plugin disabled and confirm stability across several map changes and the original trigger, then re-enable just that plugin and confirm the crash returns.

; suspected culprit isolated
; badplugin.amxx

That two-way confirmation is what separates the real culprit from a coincidence. With the guilty plugin named, either update it, replace it with a maintained equivalent, or fix its source and recompile. If it turned out to be a bad load rather than a crash, that is a different problem — see the bad load fix.

Contributors: Daemon666 ✦
Share: