---
title: "Fix: 'SVC_BAD' Kicking Players Off the Server"
excerpt: "What the SVC_BAD network error means, why a plugin writing malformed messages is almost always the cause, and how to find and disable the offending plugin."
category: "errors"
tags: "svc_bad, netcode"
image: ""
read_time: "8 min read"
---
<p>Players drop with <code>SVC_BAD</code> in the console, sometimes in bursts, sometimes tied to a specific event like a round end or a HUD element appearing. <code>SVC_BAD</code> is the client saying it received a network message it could not parse — the byte stream from the server did not match a valid message type. On CS 1.6 this is almost never the engine's fault and almost always a plugin writing a malformed message. This is how to trace it.</p><h2>1. Understand what SVC_BAD is</h2><p>The server sends the client a stream of typed messages (SVC = server-to-client). Each has a defined structure. When a plugin builds a custom message with the engine message functions and gets the structure wrong — a mismatched begin/end, the wrong argument type, too many or too few writes, an out-of-range value — the following bytes desynchronise and the client reads garbage where the next message header should be. It reports <code>SVC_BAD</code> and disconnects because it can no longer trust the stream. So the trigger is a <em>malformed message</em>, and the source is whatever code built it.</p><h2>2. Correlate the drops with an event</h2><p>SVC_BAD tied to a moment is a huge clue. Note exactly <em>when</em> players drop:</p><ul><li>On <strong>round start/end</strong> → a round-based plugin (round sounds, HUD, money display).</li><li>When a <strong>HUD element or menu appears</strong> → a plugin drawing HUD or menus with raw messages.</li><li>On <strong>spawn</strong> or a <strong>model change</strong> → a models/skins plugin.</li><li>On a <strong>chat command</strong> → whatever plugin handles it.</li></ul><p>The event points straight at a category of plugin. A plugin misusing <code>message_begin</code>/<code>message_end</code>, writing with the wrong <code>write_byte</code>/<code>write_short</code>/<code>write_long</code> type, or sending a bad <code>SendAudio</code>/HUD message is the usual culprit.</p><h2>3. Bisect the plugin list</h2><p>Turn the correlation into a definite answer by disabling plugins and watching the error. In <a href="/tutorials/plugins-ini-load-order">plugins.ini</a>, comment out the suspect category first, change map, and see if SVC_BAD stops:</p><pre>; buggy_hud.amxx
; custom_models.amxx</pre><p>If disabling one plugin stops the drops, you have your offender. If the category guess was wrong, bisect the whole list — disable the bottom half, test, then narrow. Because SVC_BAD is deterministic (the same bad message fails every time), this converges fast.</p><h2>4. Replace or fix the offending plugin</h2><p>Once identified, you have two paths. If it is a third-party plugin, replace it with a maintained equivalent — a properly written HUD or models plugin from the <a href="/plugins/csb-admin-menu">plugin directory</a> constructs its network messages correctly and will not corrupt the stream. If it is your own plugin, audit the message code: every <code>message_begin</code> must have a matching <code>message_end</code>, every write must use the correct width for the message argument, and values must be in range. A single stray <code>write_byte</code> or a message sent to a disconnected/invalid client index can be enough to produce SVC_BAD. Never build a message to an invalid <code>id</code>.</p><h2>5. Rule out the rarer causes</h2><p>If no plugin is responsible, consider:</p><ul><li><strong>A corrupt or mismatched game DLL</strong> — a broken ReGameDLL or a mismatch between engine and mod can emit bad messages. Reinstall/align the <a href="/tutorials/install-regamedll-cs16">ReGameDLL</a> and engine versions.</li><li><strong>A bad Metamod plugin</strong> operating at the network layer — disable Metamod plugins as well as AMXX ones.</li><li><strong>Genuinely severe packet loss</strong> — extreme loss/corruption on the wire can occasionally surface as SVC_BAD for one player, but a whole-server pattern is code, not the network.</li></ul><h2>Troubleshooting</h2><ul><li><strong>Drops always on the same event</strong> — the plugin handling that event builds a bad message. Disable that plugin category first.</li><li><strong>Only one player drops on SVC_BAD</strong> — could be that client's link; a server-wide pattern is a plugin.</li><li><strong>Stops when a plugin is disabled</strong> — that is the offender. Replace it or fix its message code.</li><li><strong>No plugin responsible</strong> — suspect a mismatched engine/mod DLL or a Metamod-level plugin.</li><li><strong>Returns after you re-enable a "fixed" plugin</strong> — the message bug is still there; audit <code>message_begin</code>/<code>message_end</code> pairing and write widths.</li></ul><h2>Verification</h2><p>After disabling or fixing the offender, reproduce the exact event that used to trigger the drops — force a round end, open the HUD, run the chat command — several times with players connected, and confirm nobody gets <code>SVC_BAD</code>. Because the fault is deterministic, a handful of clean repetitions of the previously-failing action is strong proof. Re-enable your other plugins one map at a time to make sure none of them reintroduces it, and keep the offending plugin out of <code>plugins.ini</code> until it is genuinely fixed rather than just suspected.</p>
