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:
- Detects the unprocessed crash from the previous session.
- 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 nollvm-symbolizeroraddr2lineis needed inside a bare steamrt container; on Windows through DbgHelp, from the PDB next to the DLL. Frames resolve tofunction @ file:line. - Prints the crash stack with the suspected culprit — the first
addons/frame — to the server console. - Sends the report to a Discord webhook through the Steam HTTP API, with
the crash
.txtattached.
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:39Reports 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 with | A frame resolves to |
|---|---|
Debug info — Linux: built with -g / RelWithDebInfo and not stripped; Windows: the .pdb next to the .dll / .smx | function @ file:line |
| No debug info, symbol table intact (Linux) | the function name |
| Stripped binary | module + 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.