Windrose Dedicated Server Fatal Crash After Uptime: UNAUTHENTICATED gRPC Disconnect Fix (2026)
If your Windrose dedicated server runs cleanly for a day or two and then suddenly disconnects every player at once and exits with a Fatal Unreal error, you are not looking at a hardware fault, a memory leak, or a misconfigured world. As of May 2026, a recurring failure mode on Windrose dedicated servers is a publisher backend session that the Unreal Engine 5 server treats as unrecoverable. The server keeps a persistent connection to an upstream service for co-op session arbitration. When that connection is rejected by the upstream after extended uptime, the server logs a Fatal error and exits. There is no in-game indicator before it happens. Players just get dropped, and the process is gone.
The good news is that this signature is unambiguous once you know what to look for, the workaround is mechanical (restart the server), and there is a sensible cadence you can run until the publisher ships a fix.
Fast Read
If your Windrose server dies after 1 to 3 days of uptime, scan WindroseServer.log for UNAUTHENTICATED or SetBrokenState. If either is present, restart the server. This is a session-timeout pattern on the publisher's co-op backend, not a fault in your install. Until Windrose ships a fix, a scheduled restart every 24 to 36 hours keeps the server reliably up.
What the symptom looks like
| Where you see it | What it looks like | What it actually means |
|---|---|---|
| Player side | Everyone is disconnected at the same instant with a generic "connection lost" or "kicked" message | The dedicated server process exited under the players' feet |
| Host side | Server is no longer listed in the panel or shows as stopped | The process did not crash randomly. It received a Fatal error from inside Unreal and shut itself down |
| Cadence | The crash is not on minute 30 or hour 4. It tends to happen between roughly 24 and 72 hours of continuous uptime | The trigger is time-based on an upstream session, not based on world state, save size, or player count |
| After restart | The server immediately comes back up clean and players can rejoin | Confirms the install itself is healthy. The fault was in the long-running connection, not the server build |
The log signature that confirms it
Open WindroseServer.log from the session that died and look near the end of the file. The fingerprint is a stack of four related entries. If you see any of these, this article is your answer.
R5NetGrpcClientReactorV2 ... Disconnect with error. error_code UNAUTHENTICATEDReceived http2 header with status: 401LogWindows: Error: appError called: Fatal errorR5NetCmClient_GsStream::SetBrokenState
The first two lines are the upstream rejection. The publisher's co-op API gateway returns an HTTP 2 status of 401 (unauthorized) on the persistent gRPC stream the server has been holding open. The Windrose runtime treats that as fatal rather than as a renewable session, raises appError, and the dedicated server process exits. A crash stack trace is usually written immediately after these lines and points at WindroseServer-Win64-Shipping.exe.
Why this is not your fault. The upstream rejection happens on a connection that has been authenticated correctly for hours or days, doing nothing different than it was doing at startup. The server itself has no way to renegotiate that session in the current build. Restarting the server forces a fresh handshake, which the upstream accepts, and the cycle starts over.
Why this happens (without guessing)
Windrose dedicated servers are part of a publisher-mediated co-op model. Joining is invite-code based, the connection uses NAT punch-through, and session arbitration runs through an upstream gateway on a windrose.support subdomain. The server keeps that gRPC connection open as long as it is running. The current Early Access build does not gracefully handle the case where the upstream eventually returns an unauthorized status on that stream. When it does, the server treats it as unrecoverable and exits.
This pattern is not unique to Windrose. Several Early Access Unreal Engine titles with publisher-backed co-op services have shipped with the same shape of bug at first: long-lived gRPC streams that hard-fail on session expiry instead of reconnecting. It tends to get patched in later updates as the developers add stream-reconnect logic. Until that happens for Windrose specifically, the only mitigation that works end-to-end is a process restart.
How to fix it right now
- Restart the server process. A clean restart establishes a new authenticated stream that the upstream accepts. Players can rejoin within a minute.
- Verify in the new log. After restart, the new
WindroseServer.logshould show a successful upstream handshake and noUNAUTHENTICATEDerrors. If those errors are present at startup, that is a different problem (usually a stale credential or a build mismatch, not this issue). - Tell your players the world state is fine. Because the crash is a process-level exit and not a world-corruption event, saves are intact. Nobody loses progress from this crash.
How to keep it up without manual restarts
The cleanest mitigation while the publisher works on a fix is a scheduled restart that fires before the upstream rejects the session, not after. The exact safe interval varies session by session, but in the field reports we have seen, servers that have been up for more than 36 hours are at meaningful risk. A 24 hour daily restart is conservative; a 36 hour restart is the upper bound you can run comfortably.
| Restart cadence | How it behaves | When to choose it |
|---|---|---|
| Manual only | Each crash drops everyone with no warning. Roughly 1 crash per 1 to 3 days | Tiny private crew that does not mind reconnecting |
| Every 24 hours | Players see at most one short, expected downtime per day at a known time | Recommended for any group that wants reliability |
| Every 36 hours | Stretches the window further; small residual risk of crashing first | Larger groups that want fewer planned restarts |
| Reactive watchdog | A tail process on WindroseServer.log watches for appError called: Fatal error or SetBrokenState and restarts immediately | Self-hosters comfortable with a small script |
If you self-host: a minimal log watcher
You do not need a heavy monitoring stack. Any tool that can tail a log file and trigger a command when a pattern appears will work. Concretely, what the watcher needs to do is:
- Tail
WindroseServer.logas the server writes it. - Match either
appError called: Fatal errororSetBrokenState. - Wait a few seconds for the process to fully exit (it usually does so on its own after the Fatal entry).
- Re-launch the server with your normal start command.
This is essentially what well-run hosting providers do behind the scenes. If you are running your own box, the equivalent in plain shell is a tail -F piped through grep on the two patterns, with a restart command on match. Keep the script idempotent and put a minimum cool-down between restarts so a flaky upstream cannot push you into a restart loop.
If you are on a managed host
Most reputable Windrose hosting providers will already be aware of this signature by the time you read this. If you are running into the crash, it is reasonable to ask your provider three specific questions:
- Do you detect
UNAUTHENTICATEDorSetBrokenStatein the server log and auto-restart? - Can I set a scheduled restart on a 24 or 36 hour cadence from the panel?
- Will the scheduled restart preserve my world save and player progress?
The answer to all three should be yes. If your provider has not heard of the issue, pointing them at the log signature in this article is enough information for them to identify it.
What this is not
Several other Windrose crash modes can look similar at first glance and have different fixes. Use this section to rule them out before assuming the publisher session is at fault.
- Crash at server startup. If the server never reaches a stable running state, you are not looking at session timeout. Check client and server version mismatch after a Steam update.
- Players cannot join even when the server is up. That is a host/join flow problem, not a session timeout. See Windrose can't host or join: kicked to menu and invite errors.
- Server gets slower and slower over a long session. That is memory pressure, not a Fatal exit. See Windrose performance decay and 32 GB RAM.
- World load fails after a clean restart. That is a world-state problem; the session signature above will not be present. See Windrose stuck on loading screen and world load crashes.
FAQ
How long does the server stay up before the crash?
The window is not exact, but reports cluster between 24 and 72 hours. A 36 hour restart cadence eliminates the crash for most groups; a 24 hour cadence is the safe choice.
Does the crash damage my world save?
No. The process exits cleanly from the engine's point of view after the Fatal error, the world file is committed to disk on each autosave, and a restart loads the world in its previous state. The most you can lose is unsaved minutes between the last autosave and the moment of the crash.
Will the publisher fix this?
Almost certainly, but no public timeline yet. The pattern (long-lived gRPC stream that hard-fails on session expiry) is well known in Unreal Engine 5 co-op titles and usually gets fixed by adding stream reconnect logic on the client side. Track Windrose patch notes for entries that mention session, authentication, gRPC, or reconnect.
Can I tell from inside the game that this is about to happen?
No. There is no in-game warning. The only reliable advance signal is the log file, and even there the UNAUTHENTICATED line appears at the moment of failure, not before. Time-based restart is the only proactive defense.
What if I see UNAUTHENTICATED at server startup, not after uptime?
That is a different problem. Startup UNAUTHENTICATED usually means the server build does not match the live game build after a hotfix, or a credential or token expected by the launcher is missing. Re-verify game files, confirm the dedicated server is on the same build as the game, and restart Steam fully on the host.
Sources
- Windrose dedicated server log file:
WindroseServer.log(per-session, written next to the server binary). - Windrose official dedicated server documentation: invite-code model and NAT punch-through.
- Unreal Engine documentation:
appErroras a fatal-exit primitive. - Community reports of disconnect and crash patterns during Windrose Early Access, May 2026.