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.log # main server log, normal startup output
├── server-debug.log # verbose debug, only if enabled in serverconfig
├── server-worldgen.log # terrain generation, the one to read when a boot stalls
├── server-chat.log # chat history
├── server-build.log # block placement history
├── server-audit.log # admin actions
├── server-crash.log # the last crash, overwritten by the next one
└── Archive/ # previous runs, stamped yyyy-MM-dd_HH_mm_ssThe two you will use most are server-main.log (what was happening before things went wrong) and server-crash.log (the actual exception dump). Note the fixed filename on the crash log: it is not timestamped and it is not kept per crash, so the next crash replaces it. Copy it somewhere before you restart.
What's in a crash file
A server-crash.log 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.logfor 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
The server archives its logs on start, it does not simply overwrite them. On each launch the previous run's files are moved into an Archive set stamped yyyy-MM-dd_HH_mm_ss, and how many of those survive is governed by archiveLogFileCount and archiveLogFileMaxSizeMb. So one accidental restart does not destroy yesterday's evidence, but retention is finite and a server that restarts in a loop will roll the good run out of the archive quickly. server-crash.log is a single fixed filename rather than one file per crash, so treat it as the most perishable of the set. Copy the whole Logs directory before you restart a server you intend to diagnose.
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):
server-crash.log, copied before any restart.- The last 200 lines of
server-main.logfrom 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.log 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.log:
| 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.