Where Vintage Story Stores Server Crash Logs
Vintage Story writes its own log set under the game's data directory, completely separate from the OS-level stderr.log that catches process-level failures. If you are looking for "the crash log" and the panel's console pane is empty, the actual file is one directory over.
The two log layers
Every Vintage Story server on a Supercraft node produces two parallel log streams:
| Layer | Where | What it catches |
|---|---|---|
| OS / process supervisor | vst/process-control/stderr.log |
JVM/native crashes, OOM kills, missing-library errors, signal terminations. |
| Game's own logger | vst/data/Logs/ |
In-game events, mod errors, world generation issues, network errors, and per-incident crash dumps. |
Most "I need the crash log" requests want the game's own logger. The OS-level stream is only useful when the process never got far enough to write to its own log directory.
What lives under data/Logs/
vst/data/Logs/
โโโ server-main.txt # main server log, normal startup output
โโโ server-event.txt # in-game events (deaths, joins, leaves, chunk loads)
โโโ server-debug.txt # verbose debug, only if enabled in serverconfig
โโโ server-chat.txt # chat history
โโโ server-build.txt # block placement history
โโโ server-audit.txt # admin actions
โโโ server-crash-<timestamp>.txt # one file per crash, rotated automaticallyThe two you will use most are server-main.txt (what was happening before things went wrong) and server-crash-<timestamp>.txt (the actual exception dump).
What's in a crash file
A server-crash-*.txt file contains, in order:
- The exception type and message.
- The full managed stack trace from the .NET runtime that powers Vintage Story.
- The game version, mod versions, and OS info at the moment of crash.
- The last few lines from
server-main.txtfor context.
The structure is straightforward: scroll to the bottom for the game version, scroll to the top for the exception. The first non-engine stack frame usually names the mod or the world subsystem that triggered the crash.
Rotation policy
Vintage Story does not delete old crash files automatically. They accumulate in data/Logs/ until you remove them. The standard non-crash logs (server-main.txt et al) are overwritten on each server start unless you have enabled append mode in serverconfig.json, so if you want to keep yesterday's server-main.txt you have to copy it before restarting.
Common crash signatures
| First line of stack | Likely cause |
|---|---|
References a mod namespace (e.g. VSSurvivalMod.X.Y) |
Mod incompatibility after a game update. Update or remove the named mod. |
References Vintagestory.Server.ServerMain |
Likely a config file with bad JSON. Validate serverconfig.json. |
References WorldGen or ChunkGenerator |
World generation hit an edge case. Often resolves after a restart; if not, a mod that adds blocks is conflicting. |
References NetworkChannel or PacketHandler |
A client sent a malformed packet (often modded clients on a vanilla server, or version skew). |
OutOfMemoryException or stderr shows signal 9 |
Heap ceiling reached. See reading stderr.log. |
If data/Logs/ is empty after a crash
If the panel shows the server stopped and there are no recent crash files in data/Logs/, the process died before the game's logger initialised. In that case:
- Open
vst/process-control/stderr.log. - If stderr is also silent, open
vst/process-control/run_watch.stderr.logfor the exit code and signal. - A
signal 9is an out-of-memory kernel kill: increase RAM. A non-zero exit with no further output usually points at a missing native library; reinstall.
The general procedure is documented in When your game server exits silently: read stderr.log.
Sharing a crash log for support
When you open a support ticket, the useful files are (in order):
- The most recent
server-crash-<timestamp>.txt. - The last 200 lines of
server-main.txtfrom the same run. - Your
serverconfig.jsonwith the password redacted.
That trio is enough to diagnose 90% of crashes without follow-up questions.
Quick rule: if the panel console is empty after a crash, look in data/Logs/server-crash-*.txt first, not process-control/stderr.log. Vintage Story crashes write to its own log directory, not to stdout.
1.22-specific crash signatures (refreshed 2026-05)
The 1.22 release introduced several new crash classes worth recognizing in your server-crash-*.txt:
| Signature in stack trace | Likely cause | First action |
|---|---|---|
ChunkRenderer.RenderChunk or BlockEntityRenderer |
Client-side "look direction" crash class introduced in 1.22 stable | Lower render distance to 16-20 chunks; avoid the trigger location |
WorldGen.RiverGenerator |
1.22 procedural river generation hit an edge case | Restart usually resolves; if persistent, regenerate the affected chunk via admin commands |
InvalidDataException with mod namespace in stack |
Mid-save mod corruption (mod from 1.21 left data in chunks) | See our mid-save corruption recovery guide |
Vintagestory.GameContent.OverlayHook |
External overlay (MSI Afterburner, RTSS, Discord overlay) conflicting with 1.22 render pipeline | Disable overlay; client-side fix only, doesn't affect server |
NullReferenceException at BoatEntity.OnGameTick |
1.22 boat physics hit a null reference during entity update | Acknowledged in 1.22.x patch notes; update when fix ships |
If you're hitting any of these and want broader context on what's known-broken in 1.22, see our 1.22 stability issues guide.
Vintage Story hosting with logs you can actually find
On Supercraft Vintage Story hosting, data/Logs/ is browsable from the panel's file manager and live-tailable from the console. Pair this with the admin commands reference to act on what the log tells you.