Windrose servers can crash repeatedly during Early Access. Most of the time it’s one of three causes: not enough RAM, a version mismatch after a patch, or a save file that’s hit a bad state. Work through the steps below in order and you’ll usually narrow it down quickly.
Step 1: Take a Manual Backup
Before changing anything, capture the current state so you can roll back if a fix makes things worse.
- Stop your server
- Follow Backing Up Your Windrose Server to download both the world folder and
ServerDescription.json
WinterNode also runs automatic backups every 12 hours, so you have a safety net even if you skip this. A manual backup right before troubleshooting is still the safest move.
Step 2: Read the Console Output
The crash output usually names the cause directly.
- Log in to the Game Control Panel
- Open the Console for your Windrose server
- Scroll to the last few minutes before each crash and look for lines that start with
Error,Crash, orOut of memory - Click Upload Logs at the top right of the console to generate a shareable link if you want to send the output to support
If the same error string appears at every crash, that’s your starting point.
Step 3: Check RAM Usage
Out-of-memory is the single most common cause of repeat crashes on Early Access games.
- With the server running, open the Console page
- Watch the Memory graph during normal play and during whatever activity (boss fight, large crew, dense settlement) tends to precede a crash
- If memory consistently pins near the top of the graph before the server stops, you need more RAM
Recommended sizing per the Windrose pricing guide:
- 1-2 players: 8 GB
- 3-4 players: 12 GB
- 5-8 players (full crew): 16 GB or more
To upgrade, see Upgrade or Downgrade Your Service.
Step 4: Confirm the Server Is on the Current Patch
Crashes that started right after a Windrose update are usually a version mismatch. WinterNode tracks Windrose server-binary updates and applies them same-day, but a stale install can still happen.
- Stop your server
- Click Start to let the auto-update run
- Watch the Console output during startup for the version line printed by the launcher
- Compare against the latest patch on the Windrose news page
If the server still won’t pull the new version, navigate to Advanced > Server Actions and click Reinstall Server. Reinstall replaces the game binaries; your R5/Saved/ (worlds) and R5/ServerDescription.json are not touched.
Step 5: Try a Recent Backup
If logs and RAM look fine, the world itself may be in a bad state. Save corruption is rare but does happen during Early Access.
- Stop your server
- Restore one of the automatic backups from before the crashes started
- Start the server and play for a session
- If the crashes stop, the previous save was the cause. Treat that earlier backup as your new starting point.
Still Not Working?
If you’ve worked through the steps above and the server still crashes, contact our support team with:
- Your Server UUID
- How often the crashes happen and roughly when they started
- The last 50 lines of console output at each crash (use Upload Logs for a shareable link)
- Your current RAM tier and crew size
- Whether the crashes started right after a Windrose patch
Frequently Asked Questions
Windrose is in Early Access. The dev team ships frequent patches and the server binary is still maturing. Occasional crashes are common, especially around patch days or with the full 8-player crew online. Repeated crashes within a short window usually point at one of: insufficient RAM, a version mismatch after a patch, or a corrupted save.
Open the Console in the Game Panel and watch the memory graph in the minutes before a crash. If memory pins near 100% before the server stops, you need more RAM. The developers recommend 16GB for a full eight-player crew.
Open a ticket with: your Server UUID (top-right of your server's entry in the Game Control Panel server list), the exact time(s) of the crashes, the last 50 lines from the Console at each crash, and the version number from the Game Panel dashboard. The more specific the timing and log output, the faster we can correlate it with known patch-day issues.





