Guides

Crash Handler

Minidumps processed on the server itself, symbolized plugin frames, a suspected culprit and a Discord report.

The core ships its own crash handler on both Linux and Windows. It is a port of AcceleratorLocal and AcceleratorCS2 — nothing is uploaded to Throttle, everything is processed on the server.

There is nothing to install. The handler comes up with the core and works for every plugin on the server, Source2Mod's own and any other Metamod plugin.


What happens on a crash

When the server crashes, a minidump plus a .txt with the map, the game path, the command line and the full console history is written to addons/source2mod/dumps/. On the next start the core:

  1. Detects the unprocessed crash from the previous session.
  2. Re-processes the minidump and symbolizes third-party (addons/) modules in-process — on Linux with the bundled Breakpad, straight from the ELF/DWARF on disk, so no llvm-symbolizer or addr2line is needed inside a bare steamrt container; on Windows through DbgHelp, from the PDB next to the DLL. Frames resolve to function @ file:line.
  3. Prints the crash stack with the suspected culprit — the first addons/ frame — to the server console.
  4. Sends the report to a Discord webhook through the Steam HTTP API, with the crash .txt attached.
Server crashed: SIGSEGV /SEGV_MAPERR @ 0x67

#0 some_plugin.smx + 0x1dcc0 (CBadClass::DoStuff() @ badclass.cpp:39)
#1 some_plugin.smx + 0x1db86 (some_command_callback(CCommandContext const&, CCommand const&) @ commands.cpp:56)
#2 libtier0.so + 0x15f682
#3 libengine2.so + 0x3ecb4e

Suspected culprit: some_plugin.smx -> CBadClass::DoStuff() @ badclass.cpp:39

Reports are queued until the Steam API activates and sent then, so a report generated at boot is never lost.


Configuration

The handler is configured in addons/source2mod/configs/core.json:

"CrashHandlerEnabled": true,
"CrashDiscordWebhook": ""

Leave the webhook empty to keep the dumps local only.


Getting full symbols

How much a frame tells you depends on what is deployed next to the binary.

Deployed withA frame resolves to
Debug info — Linux: built with -g / RelWithDebInfo and not stripped; Windows: the .pdb next to the .dll / .smxfunction @ file:line
No debug info, symbol table intact (Linux)the function name
Stripped binarymodule + offset

Only modules under addons/ are symbolized. Frames inside the game's own libraries stay as module + offset, which is what you look up in a disassembler.


Crash-loop protection

If the server crashes twice in a row without ever finishing startup, the pending dump is left unprocessed, so the reporting itself can never keep the server down. The dump stays in addons/source2mod/dumps/ and can be looked at by hand.


Windows

The handler catches access violations, illegal instructions, stack overflows, heap corruption and Sys_Error through a vectored exception handler ahead of Valve's own, exactly like AcceleratorCS2.

Any .NET runtime in the process (CounterStrikeSharp) needs the server started with -DoNotPreloadDLLs, or its managed binaries trip the handler at boot.


Running next to Accelerator

Do not run Accelerator or AcceleratorLocal next to Source2Mod. Two exception handlers fight over the same signals, and neither report can be trusted.

On this page