Game hangs at saving

[Crowley9]

This one is frustrating, since it happens rarely and somehow seems to clear itself up after a while. After having put some twenty hours into the game it has happened to me twice that when saving the game, it simply stays in the "Saving" screen and nothing happens. I have tried waiting some ten minutes, and still nothing. Checking the user files, it seems it successfully erases the old save but does not write a new one.

I have kept a bunch of backup copies of my saves and if I try loading from a backup save, the game still repeatedly hangs when I try to save. Even if I try from an earlier backup, the problem still persists. So this seems to be something that is not directly dependent to the game conditions that are stored in the save file. Then after having tried again from my backup copies for a while, the game suddenly starts saving normally again. I have no idea what causes the issue to clear up.

I have attached info and debug level logs from game sessions where this bug happened, plus an info level one from the previous session. I also have fifty megabytes worth of trace logs if you want. Hopefully these will be of some help.

save_fail_logs.zip

[LittleBitUA]

That's a nasty one - thanks for writing it up with the "old save gone, new one never written" detail, that narrows it a lot.

On the 360 a save is a content container the system creates; my runtime maps that onto a folder under userdata: it deletes the old container, then writes the new files. "Saving" sitting there forever means the game is waiting on one of those steps to finish and it never does. The pattern you describe - independent of which save you load, clears up by itself later - smells like something else holding that folder at that moment: antivirus scanning the freshly written 9 MB file, Windows Search, a sync client, a backup tool. Two questions: is the game folder under OneDrive / Dropbox / anything synced, and does anything watch that folder?

And a request: the next build logs every step of the save path with its result, so a log from a session where it hung will name the failing call. Until then, when it hangs, don't kill it right away - check whether some process has the save folder open (Resource Monitor → CPU → Associated Handles, search for Savedata). If you catch the culprit there, that's the fix right there.

[Crowley9]

The userdata folder is not cloud synced, and the only antivirus I have running is Windows Defender. The next time this happens, I will check for the processes as you describe.

[LittleBitUA]

1.3.2 is up: https://github.com/LittleBitUA/DPRecomp/releases/tag/v1.3.2 (launcher Update button, or unzip over your folder). It logs every step of a save now - the container being created, opened, closed or deleted, with the result of each - and every line says which game thread wrote it. So when the "Saving" screen hangs again, the log will show which step never completed and whether the game's own thread is the one waiting.

When it happens: let it sit for a minute, then close the game and attach logs\deadlyprem_XXX.log from that session. The two questions from above still stand (synced folder? anything watching it?), but the log will probably answer them for us.

[LittleBitUA]

1.3.4 is out and it was built for this report: https://github.com/LittleBitUA/DPRecomp/releases/tag/v1.3.4

The log now gets a [stats] line every minute, written from its own thread, so it keeps coming after the game thread is stuck. It carries process memory and handles, VRAM, every guest heap, and the kernel object / thread counts - and when the stuck thread is holding a kernel lock, that line says objects busy / threads busy instead of numbers, which by itself tells us where to look. The game's own PhysX errors and asserts land in the log too now.

So the ask is small: update, play until it hangs on a save again, leave it hanging for a minute or two, then close it and attach the newest logs\deadlyprem_XXX.log. The last few [stats] lines plus whatever came right before the save are what we need. Thanks for sticking with this one.