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.
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.
SVC_BAD tied to a moment is a huge clue. Note exactly when players drop:
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.
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.
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.
If no plugin is responsible, consider:
message_begin/message_end pairing and write widths.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.