[1.1.94] Autosave crashes - WIN11

[Kilitar]

9,5k hours on Steam account, playing factorio few years. Never got crashes so far - except this version.
Crashes happen once per 3-4 hours in the middle of autosave. Result is then corrupted autosave file and CC to desktop.
No mods active, pure vanilla.
All drivers (chipset, graphic card, sound card, BIOS firmware, windows updates) most recent ones. No crashes anywhere else. Memory tested with MEMx86.
I7 13700KF/64GB Ram/RTX3800/3440x1440 . Monitor running at 100Hz in normal mode, (I know it is limited to 60FPS in Factorio, but as I do ALT+TAB during game, into desktop, it might be related as monitor maybe switch to default frequency mode during alt+tab?)

Anyway, exact rig details in attachment.

Crash is allways related to situation when game running some time on background just before crash.
Factorio install directory (steam library) is on different SSD drive than OS. both SSD were also tested, no faults.

Might be same isssue like reported here. But in my case it is definitely not Ryzen issue. Also - I do not have any stability issue anywhere else, even in very resource heavy apps and games.
viewtopic.php?f=29&t=91462

One crash per 3-4 hours is not a game-breaker of course. But there probably is something buggy inside recent version. I know random rare bugs are hardest beasts to track.

[Rseding91]

Thanks for the report. Do you have the log file from when the game crashed? The one you provided is from after you re-launched the game and played for a while.

[Kilitar]

Unfortunately I don't, I didn't know that the game only leaves the last two logs.
As soon as the next crash occurs, I'll put the current log after that crash.
There is only factorio-dump-previous.dmp file I can upload if it is somehow useful.

[Kilitar]

Fresh new crash.
Log and save in attachment.

[Rseding91]

Looking at the crash log; it's crashing while drawing sprites for an entity and doesn't seem to have anything to do with the saving logic. I've never seen that section of code crash on a known stable/working computer before but I have seen computers crash in that area of code when they're unstable and or have bad hardware. I recommend running this https://memtest.org/ just to see if it spots anything as a decent first-thing to try.

Can you keep posting log files from future crashes - I want to see if they're all the same or if it's crashing in random places.

[Kilitar]

Hello,

I tested the RAM with Memtest x86 after the first crash and the complete test passed without a single error (it ran all night repeatedly for 7h).
PC is completely stable in games like Cyberpunk, Baldurs Gate 3, Stellaris, Crusader Kings 3, Starfield,...

At the same time when Factorio 1.1.94 came out, I also updated the nVidia drivers to 546.01 (most recent version).

I'll try reverting to an earlier version of the drivers, or possibly to a previous version of Factorio 1.1.91, which was also fully stable for me, to see if it solve CTD .

[Kilitar]

After last crash Factorio files was transfered to another SSD (in case it is an SSD issue). Another crash anyway with Factorio (Steam Library) on different SSD. I am still on Factorio version 1.1.94.


Now going forward with Video driver reinstall back to 545.92 WHQL. (ATM I have most recent 546.01 WHQL via nVidia Experience - one which was stable with 1.1.91 Factorio) to see if it si related to recent nVidia driver somehow.

-------------------------------------EDIT-------------------------------------------------
Checking log - I am curious about lines
I have OS installed on drive C:\, Factorio was previously on drive A:\ now is on drive F:\
(I have 7 SSD local drives + 3 HDD drives on my rig).
Still, based on logs - looks like there are some temporary files forced on D:\ (But they are not there as D:\ in my case is now empty drive. I did not found riscchandler.cpp neither exe_common.inl nowhere on my PC.

Code: Select all

d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (304): `__scrt_common_main_seh'::`1'::filt$0
d:\agent\_work\2\s\src\vctools\crt\vcruntime\src\eh\riscchandler.cpp (290): __C_specific_handler

Also, last two crashes were not related to autosave, they were in time between saves. Other two before (which I do not have log) happen exactly in middle of autosave.

[Rseding91]

That crash is also in rendering - unrelated to saving. But a different place from the last crash.

The file paths in the stack traces are the paths of those files at the time the exe was compiled and won't have anything to do with your local machine.

[Rseding91]

Note: when I said rendering it's not in the GPU logic. It's in the Factorio C++ logic where it has collected all of the information from the game state about what needs to be drawn and is currently preparing to send it to the GPU driver.

[Kilitar]

Yep, last two crashes did not happen during autosave. Two others before were right in the middle of autosaving process.

My save/temporary files are on the NVME PCIE 3.0 x4 system drive C:/ which has 30k GB writes and 83% health status based on CrystalDiskInfo.

In case C:\ has any issues, might changing path in config to force Factorio use another temporary space help? Or it is unrelated to this issue?

Code: Select all

[path]
read-data=__PATH__system-read-data__
write-data=__PATH__system-write-data__

I still thought of a variant that could be related to the motherboard BIOS update that I performed 2 weeks ago. But I'm totally not excited about trying to revert the BIOS to a previous version because of a single game crashing .

Rig is stable, I have water cooling, CPU in Factorio does not exceed 50C degrees.
I had also updated Asus AI suite and Asus Armoury Crate week ago. Both monitor hardware. Automatic overclock is disabled there as well. However, both run resident and may not be "friends" with Factorio.

Anyway, thanks for your time @Rseding91 , I'll investigate further.

[Rseding91]

... Rig is stable ...

You say that; but the crashes say otherwise. Factorio has always been an outlier in that it pushes CPUs a lot more than most games. Most games focus on crushing the GPU with demanding workloads and the CPU just sits there not doing much. Factorio is the opposite.

[Kilitar]

Hello.
It is solved.
BIOS upgrade messed with XMP memory profile settings and set default 1,2V (JEDEC) instead of 1,45V (XMP) - which my memory needs to run on full frequency. That's never happened before. It also lowered frequency to 3400MHz instead 3600MHz.

My Asus Rog Mobo has Memtest x86 10.0 integrated in BIOS, so I ran it directly from UEFI bios menu). But this one surprisingly used correct voltage 1.45V and also correct frequency 3600MHz for my sticks test - and passed without error.

I useed USB stick with 10.6 Memtestx86 version and this one run with 3400MHz/1,2V - and indeed - seldom errors (4-6) per single full pass.
As I checked using CPU-Z and 3400MHz/1,2V is used in Windows.
I feel pretty stupid, as it is also part of Factorio LOG!!! Just my poor old eyes did not see this.

Code: Select all

   0.026  [0]: Team Group Inc TEAMGROUP-UD4-3600 16384 MB 3400 MHz 1.2 v
   0.026  [1]: Team Group Inc TEAMGROUP-UD4-3600 16384 MB 3400 MHz 1.2 v
   0.026  [2]: Team Group Inc TEAMGROUP-UD4-3600 16384 MB 3400 MHz 1.2 v
   0.026  [3]: Team Group Inc TEAMGROUP-UD4-3600 16384 MB 3400 MHz 1.2 v

So, I set voltage for memory in BIOS manualy to XMP settings to 3600MHz/1.45v - and 10.6 USB stick Memtest x86 version passed few runs. Also - there hasn't been a Factorio crash since.

I am deeply sorry for false alert. It was indeed unstable hardware after BIOS update.

Thank you and have a nice day.