Fix: 'SVC_BAD' Kicking Players Off the Server

Players drop with SVC_BAD in the console, sometimes in bursts, sometimes tied to a specific event like a round end or a HUD element appearing. SVC_BAD 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.

1. Understand what SVC_BAD is

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 SVC_BAD and disconnects because it can no longer trust the stream. So the trigger is a malformed message, and the source is whatever code built it.

2. Correlate the drops with an event

SVC_BAD tied to a moment is a huge clue. Note exactly when players drop:

• On round start/end → a round-based plugin (round sounds, HUD, money display).
• When a HUD element or menu appears → a plugin drawing HUD or menus with raw messages.
• On spawn or a model change → a models/skins plugin.
• On a chat command → whatever plugin handles it.

The event points straight at a category of plugin. A plugin misusing message_begin/message_end, writing with the wrong write_byte/write_short/write_long type, or sending a bad SendAudio/HUD message is the usual culprit.

3. Bisect the plugin list

Turn the correlation into a definite answer by disabling plugins and watching the error. In plugins.ini, comment out the suspect category first, change map, and see if SVC_BAD stops:

; buggy_hud.amxx
; custom_models.amxx

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.

4. Replace or fix the offending plugin

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 plugin directory constructs its network messages correctly and will not corrupt the stream. If it is your own plugin, audit the message code: every message_begin must have a matching message_end, every write must use the correct width for the message argument, and values must be in range. A single stray write_byte or a message sent to a disconnected/invalid client index can be enough to produce SVC_BAD. Never build a message to an invalid id.

5. Rule out the rarer causes

If no plugin is responsible, consider:

• A corrupt or mismatched game DLL — a broken ReGameDLL or a mismatch between engine and mod can emit bad messages. Reinstall/align the ReGameDLL and engine versions.
• A bad Metamod plugin operating at the network layer — disable Metamod plugins as well as AMXX ones.
• Genuinely severe packet loss — 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.

Troubleshooting

• Drops always on the same event — the plugin handling that event builds a bad message. Disable that plugin category first.
• Only one player drops on SVC_BAD — could be that client's link; a server-wide pattern is a plugin.
• Stops when a plugin is disabled — that is the offender. Replace it or fix its message code.
• No plugin responsible — suspect a mismatched engine/mod DLL or a Metamod-level plugin.
• Returns after you re-enable a "fixed" plugin — the message bug is still there; audit message_begin/message_end pairing and write widths.

Verification

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 SVC_BAD. 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 plugins.ini until it is genuinely fixed rather than just suspected.