When a plugin misbehaves, AMX Mod X does not stay silent — it writes the reason to a dated log file. Learning to read that file turns "a plugin is broken" into "line 214 of this plugin divided by zero." This walks through where the logs live, how a single log line is structured, and what each of the recurring error types actually means so you can act on it instead of guessing.
1. Find the log files
AMX Mod X keeps its own logs, separate from the HLDS logs, in one directory:
cstrike/addons/amxmodx/logs/
Inside you will find files named by date, error_20260715.log and a matching L20260715.log. The error_* file is the one you want — it collects plugin load failures and run-time errors. Open the file whose date matches when the problem happened; a fresh error is always at the bottom.
2. Read the anatomy of an error line
A run-time error is a small block, not one line. A typical entry looks like this:
L 07/15/2026 - 21:04:11: Run time error 4 (plugin "myplugin.amxx") (native "get_user_name") - debug not enabled! L 07/15/2026 - 21:04:11: [AMXX] Displaying debug trace (plugin "myplugin.amxx") L 07/15/2026 - 21:04:11: [AMXX] Run time error 4: index out of bounds L 07/15/2026 - 21:04:11: [AMXX] [0] myplugin.sma::show_name (line 88)
Read it bottom-up: the last [0] line is the exact source file, function, and line number where it broke. The Run time error 4 tells you the kind of fault, and the plugin name tells you which file to open. That is everything you need — the file, the function, the line, and the class of error.
3. Turn on the debug trace
If the log says debug not enabled! you only get the error number, not the line. Enable line numbers by loading the plugin in debug mode — add the debug flag after its name in plugins.ini:
myplugin.amxx debug
Change the map and reproduce the error; now the trace includes the ::function (line N) detail shown above. Leave debug on only while investigating — it is slightly slower — then remove the flag. This is covered in more depth in debugging AMXX plugins.
4. What the common messages mean
| Log message | What it means |
|---|---|
Run time error 4: index out of bounds | The plugin read past the end of an array — often a player index of 0 or an unchecked loop. See run time error 4. |
Run time error 10: native error | A native was called with a bad argument, or a required native does not exist — frequently a sub-plugin loading before its core. |
failed to load: Module/Library "x" required | A module the plugin needs is not enabled in modules.ini. Enable it. |
Plugin "x.amxx" is not a valid AMX Mod X plugin | The file is corrupt, truncated, or compiled for a different AMXX branch. Recompile it. |
Function "y" was not found | A forward or a bind points at a public function name that does not exist in the source. A typo in the register call. |
5. Tie the error to a plugin and act
Once the line names a plugin, list your plugins to confirm its state:
amxx plugins
A plugin repeatedly throwing errors often shows as debug or, if it failed at load, bad load. If a single plugin is spamming the log every round, pause it immediately from the console so the server stops throwing while you fix the file:
amxx pause myplugin.amxx
If you cannot even tell which plugin crashes the whole server, the log narrows it down; the systematic hunt is in finding a crashing plugin.
Common errors
- Log shows an error number but no line — debug is off. Add the
debugflag inplugins.iniand reproduce. - Log directory is empty — the server has no write permission to
addons/amxmodx/logs/. Fix directory ownership; nothing is being recorded. - 'not a valid AMX Mod X plugin' — the
.amxxis corrupt or wrong-branch. Recompile from source with the matching compiler. - Same error repeats hundreds of times — it fires every event; the log grows fast. Pause the plugin, fix the line the trace names, reload.
- Error names a native you did not call — it is inside a plugin you loaded, not yours. The plugin name in the line is authoritative.
Verification
After a fix, clear your view by noting the current bottom of the log, reproduce the action that used to error, and confirm no new line is appended. Then restart or change map and check amxx plugins shows the plugin running rather than debug or bad load. A quiet error_*.log after a full map is the signal that the plugin set is healthy — keep an eye on it, because a growing error log is the earliest warning that something regressed.
