Skip to main content
If SS14.Watchdog detects that your server has locked up, it will kill the server and restart it. If this happens for real on a live server, a chance of just looking at logs is out of the window. This guide will give a quick 101 for how to approach debugging this kind of issue.
Just to be clear: you may get a similar error if the game server can’t reach the watchdog due to misconfiguration, in which case the game server will reliably get killed after startup, on loop. This article is not about that, this is about a genuine, real-nasty crash bug.

​
Background: Watchdog Pings

The watchdog expects the game server to send it regular ping messages to indicate that the game server is still alive. The game server sends these pings at a regular interval of 15 seconds (currently unconfigurable, what was past me thinking), and the watchdog expects one at least every TimeoutSeconds in the instance configuration. If the game were to get stuck in an infinite loop of some kind, it would cease to send these pings and the watchdog would quickly kill it and restart it.

​
Alright, so what have we got?

If you want to trigger this real easy, connect to your server and run something like this in scsi: scsi prompt about to run 'while (true) ' Expanding the log excerpt from above, we have something like this:
If you’re even reading this page I hope you have enough experience hosting a server to know this, but just to be clear: those two [WARN] messages are not it.
The game server itself produced no meaningful logs (as it rarely does in a case like this), all we got to go by is the watchdog killing us. Luckily, the watchdog is configured by default to make a core dump of the game server process if it has to kill it, and listed the path dumped to in the log output. What is a core dump? It’s a file that contains the memory of the process when it crashed. By default, this dump includes enough memory to get stack trace information using a debugger. If you want more, you can change the TimeoutDumpType property on the watchdog instance configuration to one of these values. Be warned that core dumps are quite big, and reporting more info can make them outright huge.
Core dumps can contain sensitive information from your server (such as database passwords) and should not be given to people you do not trust!
“Ok, so I have a file that weighs a couple hundred megabytes, what do I do with it? Do I drag it into Rider?” Oh you sweet summer child. You have two options that I know of to debug this: lldb and WinDBG. One of those is a command-line debugger. The other is a command-line Windows debugger that at least has the courtesy of having a basic UI. Hey, at least you don’t need to use gdb!
Core dumps are fragile little beings, and by default do not include all the context needed to debug something on their own. In general, it is by far the easiest to debug them if you’re debugging them on the system they happened on, and none of the underlying files changed, e.g. through game server update.With the necessary experience and or/infrastructure (symbol servers my beloved) it is possible to handle them much later or on another system, but that’s far outside of the scope of this tutorial and even I don’t have experience with that.1

​
Using lldb

lldb is a decent2 debugger for Linux and macOS. Install it:
You will also need SOS. This will extend lldb to make debugging a .NET trace possible:
Now you are ready to load the core dump into lldb:
You’re going to want a cheat sheet for that (lldb) prompt.
At this point you have a native debugger open and you can well and truly debug everything. Hell, if the game server dies due to native crashes, this is also how you’d be debugging it. You can use regular lldb commands to do regular native debugging on native modules and whatever. Though it’s still not for the heart and may require further setup, e.g. to get symbols for native libraries. For some meaningful info out of the managed stack trace, we can run the clrstack command from SOS:
Now this we can work with! At the bottom is the program main, at the top is Submission#0 which is an internal detail of the C# Interactive that we ran while (true) { } in. While I can’t show you the IL bytes or C# code in lldb (well I’m sure the former is possible with SOS), I can show you the assembly code which looks like a pretty simple infinite loop:
I hope this helped getting started using a native debugger on stuff like this.

​
Using WinDBG

WinDBG is the Windows debugger you pull out when all else has failed (which it has, here). You can get WinDBG Preview from the Microsoft Store. You will also need SOS. This will extend WinDBG to make debugging a .NET trace possible:
You can load the created dump file into WinDBG by going File -> Start debugging -> Open dump file, then selecting the file. If the file doesn’t have an extension, you need to change the filter on the open dialog to select it. Showing the navigation in WinDBG to open dump file You will need to run the .load command mentioned in the above output to load SOS:
You probably still want a proper cheat sheet for WinDBG Preview. It has a bit of UI, but usage of the internal command line is still very necessary. Anyways I couldn’t find anything like the well-formatted lldb one in 5 seconds of searching online, so find one yourself I guess.
I won’t repeat myself from the lldb side: you have a full native debugger. This can do everything, if you know how to use it. You can use !clrstack to show the managed stack trace:
Same as above, again. Wow! I hope this helped getting started using a native debugger on stuff like this.
🤫 I actually used dotnet dump collect to get the Windows dump because I was too lazy to set up the watchdog twice just for this article. Works the same, mostly. Hell I’m pretty sure it uses the same underlying library to create the dump as the watchdog!

Footnotes

  1. I tried to open a Linux core dump in WinDBG, which is supported to some degree… but it cried about enough missing files and other pains I gave up. Try moving your watchdog bin/ folder out of the way and debugging a core dump with lldb… Yeah you get wildly different results huh? ↩
  2. About as good as dev tooling on Linux gets, which is not very great. ↩
Last modified on June 20, 2026