[0.16.51] Windows hard lock and file corruption on "Cropping bitmaps"

[Sparka]

Computer becomes totally unresponsive and requires full restart when starting the game under "normal" conditions, stopping at 39-40% "Cropping Bitmaps". No alternative to restart is possible; all processing halts, including ctrl+alt+del and things as basic as audio passthrough.

Tried forcing openGL and reducing VRAM use, though that shouldn't be necessary on a GTX 970, to no avail.

Deleting the crop-cache.dat file allows it to start reliably, but this is not a good solution when trying to change mods or settings and the client auto-restarts.

File corruption is that config files and most of the logfile get written over with null bytes, eliminating all previous settings and removing most trace information.

The surviving part of the logfile is:

Code: Select all

   0.002 2018-12-25 19:44:54; Factorio 0.16.51 (build 36654, win64, alpha)
   0.002 Operating system: Windows 10 (version 1803) 
   0.002 Program arguments: "N:\Factorio_0.15.10\bin\x64\factorio.exe" 
   0.002 Read data path: N:/Factorio_0.15.10/data
   0.002 Write data path: N:/Factorio_0.15.10 [46792/228806MB]
   0.002 Binaries path: N:/Factorio_0.15.10/bin
   0.403 System info: [CPU: Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz, 12 cores, RAM: 3192/18423 MB, page: 3841/40055 MB, virtual: 4254/134217727 MB, extended virtual: 0 MB]

Everything is fine once I can get in-game, even with significant mods, but this is a rather annoying problem to have to constantly avoid, considering my system drive is still HDD (restart takes considerable time).

[Rseding91]

Do you have any way to reproduce this? I have a GTX 970 myself and it has no problems with the game when changing mods, restarting, or anything.

[Zavian]

Computer becomes totally unresponsive and requires full restart when starting the game under "normal" conditions, stopping at 39-40% "Cropping Bitmaps". No alternative to restart is possible; all processing halts, including ctrl+alt+del and things as basic as audio passthrough.

Nothing any normal program does should be capable of causing that. That makes me think that maybe you have bad/failing hardware.

[Sparka]

There's not a single other problem with 99% of programs - it's a very particular condition here by cropping bitmaps when there's already a working cropped cache.

I've seen it before in one other place - Witcher 3 can have a similar hardlock during cutscenes, where it's semi-widely reported, so not likely an individual hardware problem, and this was years ago, and on multiple CPUs (i7 920 and X5650 both did it), so "failing" is an unlikely scenario to show up so rarely and so particularly. It's certainly possible to cause without failing hardware.

All that said, I've actually found a different way to prevent it, I think, after looking through the config file - it appears to load fine if I disable threaded sprite loading. I would assume from that that 6 core with hyperthreading can hit a race condition of some type when the cropped cache exists and lets it skip straight through to sprite loading, and it was probably crashing before the screen could update to "Loading sprites".

[Rseding91]

If disabling threaded sprite loading fixes the issue for you, that indicates it ran out of RAM but failed to page to disk. Threaded sprite loading is *incredibly* RAM intensive. If it runs out (and you don't have a page file enabled) it would lock your entire system and or crash it. I *highly* doubt there are any race conditions around that logic since you're the first person I've seen have this kind of issue and we run it internally every day without issues.

[Sparka]

I have paging enabled, and 18 GB of RAM. (And given the hard lock, I was running from a fresh start to test, so pretty much the full amount was available)

That would be a convenient explanation but I highly doubt it was able to hit more than double what the median of high-end gaming PCs have. It was also only specifically a problem when the cropped cache exists, again - it loaded fine with threaded sprites so long as that file was deleted, so it definitely did not exceed RAM limits in that case.

[TruePikachu]

Why was this moved to resolved? I'm thinking 1/0, since it's almost certainly a problem on the Windows kernel side of things.

What happens if, for testing purposes (since it will slow things down), you disable Windows' write caching on the disk with Factorio's log file? Do any more log entries show up?

[Allaizn]

I have paging enabled, and 18 GB of RAM. (And given the hard lock, I was running from a fresh start to test, so pretty much the full amount was available)

That would be a convenient explanation but I highly doubt it was able to hit more than double what the median of high-end gaming PCs have. It was also only specifically a problem when the cropped cache exists, again - it loaded fine with threaded sprites so long as that file was deleted, so it definitely did not exceed RAM limits in that case.

You mentioned that you used mods, which will get you into that amount of RAM needed. My vanilla installation easily eats 7-8GB during that phase, and mods are able to easily tripple the number/size of textures to be loaded.

[Sparka]

Having just tested, I'll grant that uses more than expected - it does peak at around 8 GB, but this is not increased for the number of mods (likely because the number of threads isn't increased). It also takes a long time into "Loading Sprites" to even break 4 GB - if I let it hard lock, it's immediate, happening before the UI can even update past "Cropping Bitmaps", indicating it's long before it would even come close to using that 8 GB, and at only 8 GB that would barely be halfway to needing the pagefile on a fresh boot in the first place.