Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

I guess all we can do is take his save and advance by one turn.
Sure that might work for him but I'm more concerned about if it's a problem we can fix before a release.
 
By the way, I was testing only the dll, not reverting the entire assets to 10661. Have you all tried updating assets except dll to latest before running his save again?

I dare not revert assets because of my huge commit in between and some of raxo's...
 
Last edited:
Running 10661 dll with latest (10681) assets. Did not recalculate. Advanced 1 turn.
File size shrank from 3823KB to 3811KB.
This one crashed on trying to do next turn.
 

Attachments

@raxo2222 ,@hau , one thing you two have in common, is a windows 7 system (ntdll version 6.1.7601.23915 vs ~.17725), and toffer and I are running windows 10. But it could still be me not downgrading to 10661 assets. Trying that later.
 
@raxo2222 ,@hau , one thing you two have in common, is a windows 7 system (ntdll version 6.1.7601.23915 vs ~.17725), and toffer and I are running windows 10. But it could still be me not downgrading to 10661 assets. Trying that later.
So it seems like Windows 10 is more graceful about some stuff.

By the way minidump is always one compilation behind when it comes to revision number:
Last time DLL was compiled in SVN 10674.
Before it was compiled in SVN 10660.

So minidump should been called MiniDump_10674.dmp
 
Last edited:
For that screen, just enable Microsoft Symbols Server and load again.
View attachment 529667
Call stack from post #3924.
My Visual Studio cannot load CvGameCoreDLL.dll even though I point it to a 10661 dll...
Figured out how to do this - documentation was making a mess out of trying to explain it when it's a simple few clicks in the debug panel during a mini evaluation.

This is kinda interesting:
upload_2019-7-14_13-41-11.png

The call stack shows that while the crash took place in the ntdll.dll, it suggests that it might've had some kind of memory allocation problem beforehand. It's here, trying to erase a game message that has expired and then the dominoes end up falling into some memory issue:
upload_2019-7-14_13-43-58.png

Unfortunately, it's not like it's code I can see where it's really running into trouble.

This is one of Rax's most recent minis but it's much the same with the first ones as well. I did notice Raxo is using a lot of memory options I don't usually use in the Ini BUT changing them over I still didn't get a crash. Could this simply be something to do with how his and hau's processor is working with the memory differently? Maybe someone has a guess as to what RtIpLowFragHeapFree@8() (a function?) is hinting at.
 
By the way minidump is always one compilation behind when it comes to revision number:
Last time DLL was compiled in SVN 10674.
Before it was compiled in SVN 10660.

So minidump should been called MiniDump_10674.dmp
Didn't know about that. 10661 dll+assets still fine.(save is 1KB larger than my previous save) Now 10674 dll+assets still won't crash me. deleted usersettings, did not recalculate. save is the same size as previous post (3811KB).
 
@raxo2222 ,@hau , one thing you two have in common, is a windows 7 system (ntdll version 6.1.7601.23915 vs ~.17725), and toffer and I are running windows 10. But it could still be me not downgrading to 10661 assets. Trying that later.
No I think you nailed it... I was suspecting they might have a different operating system but I thought sure raxxo was on win10 already.

Question is what can be done about it? Anything?

Another interesting thing you mentioned:
windows 7 system (ntdll version 6.1.7601.23915 vs ~.17725)
So ntdll has to do with the operating system... fascinating. (Alberts2 probably told me that a while back already... sorry if I forgot all about that!)

I wonder if the more modern compiler is doing a few things that Win7 doesn't like because I've seen a few crashes like this I couldn't diagnose that were taking place in ntdll. That would explain a lot.
 
No I think you nailed it... I was suspecting they might have a different operating system but I thought sure raxxo was on win10 already.

Question is what can be done about it? Anything?
They could try to run BtS in compatibility mode, try out windows XP compatibility for example.

Spoiler or try these lines in CMD (comand prompt in administrative mode) :

  • regsvr32.exe /u ntdll.dll ▬ (this will uninstall the file)
  • regsvr32.exe ntdll.dll ▬ (this will reinstall the file)
Maybe the reinstalled file will be different than the default fully updated win 7 version of that file... Maybe.
 
Last edited:
No I think you nailed it... I was suspecting they might have a different operating system but I thought sure raxxo was on win10 already.
Yeah, I mentioned few times that I'm on Windows 7.
 
They could try to run BtS in compatibility mode, try out windows XP compatibility for example.
I selected Windows XP compability mode here (Right click and then on compatibility tab).
I also checked to always run as administrator too.

I passed turn normally.
 
Yeah, I mentioned few times that I'm on Windows 7.
So pretty much, in the end, it's not something we can really address is what I'm hearing here. Unless something that's being forgiving on Win10 in our code can be made more forgiving on Win7... But I have no idea what that could be.

I selected Windows XP compability mode here (Right click and then on compatibility tab).
I also checked to always run as administrator too.

I passed turn normally.
Oh wow... hell yeah!
 
Figured out how to do this - documentation was making a mess out of trying to explain it when it's a simple few clicks in the debug panel during a mini evaluation.

This is kinda interesting:
View attachment 529677
The call stack shows that while the crash took place in the ntdll.dll, it suggests that it might've had some kind of memory allocation problem beforehand. It's here, trying to erase a game message that has expired and then the dominoes end up falling into some memory issue:
View attachment 529681
Unfortunately, it's not like it's code I can see where it's really running into trouble.

This is one of Rax's most recent minis but it's much the same with the first ones as well. I did notice Raxo is using a lot of memory options I don't usually use in the Ini BUT changing them over I still didn't get a crash. Could this simply be something to do with how his and hau's processor is working with the memory differently? Maybe someone has a guess as to what RtIpLowFragHeapFree@8() (a function?) is hinting at.
This observation is consistent with your previous run on the first dump files. The last thing on the stack before leaving CvGameCore was ~CvTalkingHeadMessage(), which is supposed to destroy an object of its class. It then passed on to the runtime system and the operating system to free its heap memory. Why is it causing trouble then I don't know. Looks pretty innocent in my untrained eyes.
 
Back
Top Bottom