Sick Gaming
Fixing Windrose Infinite Loading / Freeze After Crash: Client Profile, Account File - Printable Version

+- Sick Gaming (https://sickgaming.net)
+-- Forum: PC (https://sickgaming.net/forum-50.html)
+--- Forum: PC Discussion (https://sickgaming.net/forum-13.html)
+--- Thread: Fixing Windrose Infinite Loading / Freeze After Crash: Client Profile, Account File (/thread-111411.html)

Fixing Windrose Infinite Loading / Freeze After Crash: Client Profile, Account File - SickProdigy - 08-09-2026

Windrose Infinite Loading Fix: Profile & Steam Cloud

[Image: 1778359043.webp]

Quick summary

I ran into an issue where my Windrose character would either freeze on loading, get stuck on the loading screen, or briefly connect and then get kicked back out. After a lot of trial and error, the fix ended up being a clean client-side profile/account restore, not a server rollback.

The main cause was a mismatched or polluted local profile where the account file did not line up cleanly with the correct player file. Steam Cloud also made things worse by restoring bad local profile data on game launch.

Symptoms
  • Loaded in after a server restart, played for a few minutes, then crashed.
  • After that, the same character kept freezing or hanging during load.
  • The server accepted the connection briefly, then the client disconnected.
  • Another player could stay connected, so the server itself was not completely broken.

Server log messages included:

Code:
Account farewell received in wrong state BLConnected => SaidFarewell WaitingForClientIsReady => SaidFarewell Enter inconsistent state !DefaultPlayerView Character nullptr

Important save path detail

Windrose+ character repair expected the uploaded zip to contain this path:

Code:
SaveProfiles/<steamid>/RocksDB/0.10.0/Players

But my actual local save path was:

Code:
C:\Users\<user>\AppData\Local\R5\Saved\SaveProfiles\<steamid>\RocksDB_v2\0.10.0\Players

So for the Windrose+ repair upload, the zip needed a compatibility layout using RocksDB, even though the live local save folder used RocksDB_v2.

Windrose+ repair result

Safe mode refused to edit the save because the character had spent or allocated progression nodes.

The message was basically:

Quote:The uploaded save has spent or allocated progression nodes, so Safe mode declined to auto-edit it.

A deeper repair was later run against the proper SaveProfiles zip. That repaired progression drift in the Players records, but restoring only the repaired Players folder was not enough. When I restored only Players, the game made me create a new character because the matching account/world context was missing.

[Image: 1777844155.webp]

The real issue

The big clue was that the profile is mostly client-side. On the server, the log showed the server receiving client documents like this:

Code:
Skip client document. Type R5BLAccount Skip client document. Type R5BLPlayer

The account file matters because it maps the account ID to the default player ID.

In my case, the important IDs were:

Code:
Donquixote account: 724AC4AC4B89BF05E8E1D28D8FCE1646 Donquixote player:  1BB7B53D892E4AA8B29CBDDE87DB1133 Lilith account:    851BA4674DF30F1AC9E5478E75B8A68F Lilith player:      E346D1286211493E768E0B125A3544E0

At one point, the Donquixote account loaded with the wrong DefaultPlayerId pointing at Lilith's player ID. That caused inconsistent-state failures.

Later, after more restore/import attempts, Donquixote's account pointed to the correct player again, but the client was still loading both player records and hit this:

Code:
Cannot create record. Duplicated guid 'E346D1286211493E768E0B125A3544E0' SetDataInconsistent Enter inconsistent state. Go to relogin

Steam Cloud made it confusing

Steam Cloud or the game's own backup restore kept repopulating local profile data on launch. Even after deleting or replacing files, the local RocksDB_v2 profile could get rewritten when the game started.

The local folders to watch were:

Code:
C:\Users\<user>\AppData\Local\R5\Saved\SaveProfiles\<steamid>\RocksDB_v2\0.10.0\Accounts C:\Users\<user>\AppData\Local\R5\Saved\SaveProfiles\<steamid>\RocksDB_v2\0.10.0\Players

If those timestamps change right when the game launches, Steam Cloud or the game's restore system may be putting the bad data back.

What finally fixed it

The fix was to import a clean, matched backup so the account and player records lined up again.

For my character, the account had to load like this:

Code:
Account 724AC4AC4B89BF05E8E1D28D8FCE1646 DefaultPlayerId 1BB7B53D892E4AA8B29CBDDE87DB1133

The working restore avoided the accidental/new character records and avoided duplicating the other player's record into the broken account's load path.

After the correct import, the server log changed to the good path:

Code:
Initialize R5Scenario for Player ... PlayerId 1BB7B53D892E4AA8B29CBDDE87DB1133 Character 'BP_R5Character' spawned Join succeeded: Donquixote Doflamino Player is ready CurrentPlayerId 1BB7B53D892E4AA8B29CBDDE87DB1133 WaitingForClientIsReady => ReadyToPlay

Windrose+ also logged a real join event again:

Code:
player.join Donquixote Doflamino

Suggested recovery checklist

  1. Back up the entire SaveProfiles folder before changing anything.
  2. Temporarily disable Steam Cloud while repairing or importing.
  3. Do not restore only the Players folder unless you know the matching account file is already correct.
  4. Restore a matched account/player pair from the same backup period.
  5. Make sure the account's DefaultPlayerId points to the correct player ID.
  6. Remove or quarantine accidental/new character records created during failed repair attempts.
  7. Start the game and check the client log for DefaultPlayerId, duplicate GUID, and SetDataInconsistent messages.
  8. Check the server log for ReadyToPlay.
  9. Check Windrose+ for an actual player.join event.

Bad log signs

Code:
Enter inconsistent state SetDataInconsistent Cannot create record. Duplicated guid Account farewell received in wrong state WaitingForClientIsReady => SaidFarewell BLConnected => SaidFarewell !DefaultPlayerView

Good log signs

Code:
Join succeeded: <character name> Player is ready CurrentPlayerId matches the expected player ID WaitingForClientIsReady => ReadyToPlay Windrose+ logs player.join

Conclusion

In this case, the world did not need to be rolled back. The broken state was in the local client-side profile/account/player data, and Steam Cloud kept trying to restore parts of that bad state.

Once the correct backup was imported so the account file and player file matched again, the character loaded successfully.