Sys_Error is GoldSrc's fatal-error path: when the engine hits a condition it cannot recover from, it prints Sys_Error: <reason> and exits. The server does not limp on — it dies. The good news is that the reason string after Sys_Error: is specific and tells you almost exactly what failed. This explains how to read it and the most common variants CS 1.6 admins hit.
1. Read the whole error line
Never act on just "it crashed with Sys_Error". Capture the full line and the lines above it. On Linux run the server in the foreground or tail the log:
./hlds_run -game cstrike +map de_dust2 # or watch the server log / console output as it dies
The text after Sys_Error: is the diagnosis. A few lines above it usually show what the engine was doing when it died — loading a module, precaching a map, running a plugin. Read both. Everything below hinges on that reason string.
2. 'Couldn't get DLL API' — a bad module or mod DLL
One of the most common variants:
Sys_Error: Couldn't get DLL API from <path>.so!
This means the engine tried to load a game/Metamod library and the library was the wrong architecture, corrupt, or built for a different engine. Typical causes: a 64-bit .so on a 32-bit engine (GoldSrc is 32-bit — everything must be 32-bit), a mismatched Metamod/ReGameDLL, or a truncated file from a failed upload. Reinstall the offending library and make sure engine, Metamod, and mod DLL are the matching flavour and architecture. If it names Metamod, the liblist.gam gamedll line or the Metamod path is pointing at the wrong file.
3. Hunk / cache overflow — too much content
Variants like a hunk allocation failure or ED_Alloc: no free edicts mean the map or plugins asked for more of a fixed resource than exists. A content-heavy map with many entities, or too many precached models/sounds, can exhaust the engine's memory hunk. Fixes: raise the heap size on the command line and trim content:
./hlds_run -game cstrike -heapsize 128000 +map de_dust2
-heapsize (in kilobytes) enlarges the engine's memory pool; a common value is 128000 (128 MB). If the crash is edicts, the map spawns too many entities — that is a map problem, not a heap one. The same over-budget pattern behind the sound-slot overflow can surface here as a fatal.
4. Crash during a plugin or on a specific map
If Sys_Error fires only on a certain map, that map is corrupt or references something missing — re-download the .bsp and its resources. If it fires shortly after a plugin loads or on a plugin action, bisect: disable plugins in plugins.ini and find which one precedes the crash. A plugin needing a module you do not have throws its own error (see module failed to load), but a plugin doing something the engine rejects can escalate to a Sys_Error.
5. Isolate a clean baseline
When the reason string is unfamiliar, strip the server to bare metal and add pieces back. Start with no Metamod, no plugins, a stock map:
./hlds_run -game cstrike +map de_dust2 +maxplayers 12 # no metamod line in liblist.gam, empty plugins.ini
If the stock server runs, add Metamod, then AMX Mod X, then plugins in groups, changing map between each. The step that reintroduces the Sys_Error is the culprit. This is slower than guessing but it always finds it, and it distinguishes an engine/DLL fault from a content or plugin fault.
Troubleshooting
Couldn't get DLL API— wrong-architecture or corrupt library, or a Metamod/ReGameDLL mismatch. Reinstall matching 32-bit binaries and checkliblist.gam.- Hunk allocation / memory fatal — raise
-heapsizeand trim heavy content. no free edicts— the map spawns too many entities. It is a map issue, not heap.- Only on one map — corrupt or incomplete
.bsp/resources. Re-download that map. - Right after a plugin loads — bisect
plugins.ini; the plugin may need a missing module or do something illegal. - Random and rare — strip to a stock baseline and add components back to isolate it.
Verification
After a fix, start the server in the foreground and watch it reach a running console without a Sys_Error line, then load through several maps — especially the one that crashed — and let it run under real player load for a while. Because Sys_Error is fatal and usually deterministic for its cause, a server that survives the previously-crashing map and a full plugin load has resolved it. Keep the server's console output logged so that if it ever recurs you capture the exact reason string instead of a vague "it went down".
