---
title: "How to Debug a CS 1.6 Server That Crashes with No Error"
excerpt: "A methodical process for a HLDS/ReHLDS server that dies silently: enabling the debug log, reading a core dump, and bisecting Metamod and AMXX plugins."
category: "errors"
tags: "crash, debugging"
image: ""
read_time: "8 min read"
---
<p>A server that crashes and simply disappears — no console error, no log line, the process gone — is the hardest kind to fix because there is nothing to paste into a search box. The trick is to stop guessing and generate real evidence: turn on the engine's debug crash log, then narrow the cause by bisecting your add-ons. This is the process that actually finds it.</p>
<h2>1. Capture a backtrace with -debug (Linux)</h2>
<p>The Linux dedicated server launcher, <code>hlds_run</code>, has a built-in crash handler. Start it with <code>-debug</code> and, when the game binary crashes, it writes a gdb backtrace to <code>debug.log</code> in the server directory:</p>
<pre>./hlds_run -debug -game cstrike +map de_dust2 +maxplayers 20</pre>
<p>After a crash, open <code>debug.log</code>. The bottom of the file holds the crash time, the signal (usually <code>SIGSEGV</code>, a segmentation fault), and a stack trace. Even if the symbols are partial, the trace usually names the module at fault — the engine itself, <code>metamod</code>, or an AMXX module — which points you at the right area immediately.</p>
<h2>2. Enable core dumps for a deeper look</h2>
<p>If <code>debug.log</code> is not enough, allow the OS to write a core file before launching:</p>
<pre>ulimit -c unlimited
./hlds_run -debug -game cstrike +map de_dust2</pre>
<p>A <code>core</code> file appears after the crash. Load it in gdb against the game binary to read the full stack:</p>
<pre>gdb ./hlds_linux core
(gdb) bt full</pre>
<p>You do not need to be a C++ programmer — you are looking for the first recognisable name in the trace (a module <code>.so</code>, a plugin) to know where to point the bisection.</p>
<h2>3. Read the AMXX and Metamod logs</h2>
<p>Before bisecting, check the logs that <em>do</em> get written. AMXX logs run-time errors per map under <code>addons/amxmodx/logs/</code>, and Metamod issues show in the main server log. A plugin throwing a <code>Run time error</code> just before the crash is your prime suspect. Confirm what actually loaded:</p>
<pre>meta list
amxx plugins</pre>
<p>Anything marked <code>bad load</code> or a module that failed is a lead. See <a href="/tutorials/plugins-ini-load-order">plugins.ini load order</a> for reading that output.</p>
<h2>4. Bisect the plugins</h2>
<p>Silent crashes are very often a single misbehaving AMXX plugin or Metamod module. Narrow it by halving:</p>
<ol>
<li>Comment out the bottom half of <code>plugins.ini</code> (prefix lines with <code>;</code>), change map, and see if it still crashes.</li>
<li>If it stops, the culprit was in the disabled half — re-enable half of that, repeat.</li>
<li>If it still crashes, the fault is in the enabled half (or in Metamod / a module, not a plugin). Move to disabling Metamod modules in <code>metamod</code>'s <code>plugins.ini</code>.</li>
</ol>
<p>A handful of map changes isolates one line. Run that suspect plugin in debug mode to get a precise trace:</p>
<pre>myplugin.amxx debug</pre>
<h2>5. Rule out the obvious triggers</h2>
<p>If the crash correlates with an event, the cause is narrower than a random fault:</p>
<ul>
<li><strong>Crashes on a specific map</strong> — a corrupt or oversized <code>.bsp</code>, or a plugin that trips on that map's entities. Test the map alone.</li>
<li><strong>Crashes on map change only</strong> — a plugin's map-end handler, or a bad <a href="/tutorials/mapcycle-txt-setup">mapcycle</a> entry pointing at a missing map.</li>
<li><strong>Crashes under player load</strong> — a memory or rate issue; watch it fill up and note the count at which it dies.</li>
<li><strong>Crashes at a fixed time</strong> — a cron-like task or a scheduled plugin action.</li>
</ul>
<h2>Troubleshooting</h2>
<ul>
<li><strong>No <code>debug.log</code> appears</strong> — you launched the binary directly instead of through <code>hlds_run -debug</code>. The crash handler lives in the launcher script.</li>
<li><strong>No <code>core</code> file</strong> — <code>ulimit -c</code> is 0 in that shell, or the working directory is not writable. Set <code>ulimit -c unlimited</code> in the same session that launches the server.</li>
<li><strong>Backtrace is all <code>??</code></strong> — stripped binaries; you still get the module boundaries, which is enough to bisect. Focus on which <code>.so</code> appears.</li>
<li><strong>Disabling all plugins stops the crash</strong> — it is an add-on, not the engine. Bisect back in.</li>
<li><strong>Crash persists with everything disabled</strong> — engine, mod DLL, or OS. Consider moving to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a>, which is more stable and better instrumented than legacy HLDS.</li>
</ul>
<h2>Verification</h2>
<p>Once you suspect a specific plugin or module, remove only that one, restart, and run the server through the exact conditions that killed it before — the same map, the same player load, the same map change. If it survives a full cycle that previously crashed it reliably, you have your culprit. Re-enable everything else to confirm the rest is innocent, then either update or replace the offending add-on. Keep <code>-debug</code> on until you have gone a full day without a crash.</p>
