[BTS] Does the game produce crash dumps or logs?

[Miuna]

Hi,
I recently been working on a mod, it's been working fine for a while, i made a large patch update to the mod and ever since it keeps crashing to desktop during games, especially present in multiplayer, I'm not getting any python exception errors or other errors whilst playing it just crashes, is there any logs or dump files the game creates when it crashes to desktop? I'm no pro but anything to work with would be nice.

Or is there any known issues which causes the game to crash to desktop without notice?

(Note the mod is a modmod for FFH2)

 

[f1rpo]

GenerateCrashDumps can be enabled in My Games\Beyond the Sword\CivilizationIV.ini, but, without debug symbols, that'll just say that there was a segmentation fault or so. And I think you'll need Visual Studio just to view the dump file. Enabling RandLog along with MessageLog will log all generated random numbers to MPLog.txt; that might narrow down the cause of the error. One can also enable some more Python logging (to PythonDebg.log; requiring LoggingEnabled=1 in CivilizationIV.ini) through the __LOG variables in CvEventManager.py. None of these will explicitly document a crash to desktop.

It may well be an interrupt in the CPU caused by some memory access or division by 0 in the (GameCore) DLL or in the EXE – indirectly caused, presumably, by some XML change – that kills the BtS process on the spot.

Ultimately, debugging the DLL would likely reveal the cause of the crash, but that requires setting up Visual Studio for the mod in question, which is a bit of an endeavor. Or you could revert changes until the crash no longer occurs. (Though it doesn't sound like the crashes you're experiencing are reliably reproducible ... )

 

[Re-loader]

I am in a similar situation as OP, and have mentioned about it in another thread.
The game hangs after hitting space for next turn, and a Windows option pops up to ask wether to produce full, normal or no dump.
Where do I find the dump file? And will it provide me with any useful information.
I'm playing LoR Dave_uk modmod on Genghis Khan's GEM, having modified the LoR WorldInfo.XML using the data from the GEM WorldInfo.XML
I have crashdumps and logging enabled in the .ini file.
Using windows 10

 

[f1rpo]

I don't actually remember where it gets created; I think a popup will say where. I have a dmp file in the BtS install folder (where the EXE is located), so I guess that's the place. (Or maybe I moved it there; I seem to recall that they get created in the Windows temp folder?) When I open it in Visual Studio (screenshot attached), I learn that there was a segmentation fault at code address such and such in the EXE, and I see a (unreliable) stack trace, showing other functions in the EXE, all in disassembled native code. That's not nothing, but it's far from sufficient for fixing a bug or working around it. If the crash had occurred in the DLL (which is more commonly the case when a DLL mod crashes) and the DLL had been compiled with debug symbols, then one could, I think, in theory, debug it based on the dmp – however, Visual Studio is very finicky about the debug symbols, I think it needs access to the exact same version of the source code that the crashed DLL was compiled from. Much easier to debug it based on a savegame, i.e. to reproduce the crash with the debugger attached. The only potential use of the crash dumps generated by the EXE that I can see is to debug a crash that can't be reproduced locally, i.e. when the player who gets the crash doesn't know how to debug and the developer who does know doesn't get the crash. Not sure if any modders have used crash dumps productively.

I guess you've already tested whether Dave_uk's (original) mod crashes when (auto-)playing one of the LoR scenarios and whether LoR combined with GEM crashes. So the problems seem to arise from the combination of Dave_uk's changes and GEM? You could try the previous version of Dave_uk's mod; that one had supposedly been tested more. Beyond that, I think you'd either have to get into DLL modding in order to use the Visual Studio debugger (or at least to enable runtime assertions) or experiment with changes to the GEM files. Not sure if that's just a WBSave; could try removing all but 2 players etc. For a crash after ending the turn, the last few lines in PythonDbg.log and the BBAI log might provide some clue. The logs will just show things that happened some time before (or possibly just before) the crash, e.g. "The AI is choosing what to produce in York." Not necessarily helpful.

 

[Re-loader]

I don't actually remember where it gets created; I think a popup will say where. I have a dmp file in the BtS install folder (where the EXE is located), so I guess that's the place. (Or maybe I moved it there; I seem to recall that they get created in the Windows temp folder?) When I open it in Visual Studio (screenshot attached), I learn that there was a segmentation fault at code address such and such in the EXE, and I see a (unreliable) stack trace, showing other functions in the EXE, all in disassembled native code. That's not nothing, but it's far from sufficient for fixing a bug or working around it. If the crash had occurred in the DLL (which is more commonly the case when a DLL mod crashes) and the DLL had been compiled with debug symbols, then one could, I think, in theory, debug it based on the dmp – however, Visual Studio is very finicky about the debug symbols, I think it needs access to the exact same version of the source code that the crashed DLL was compiled from. Much easier to debug it based on a savegame, i.e. to reproduce the crash with the debugger attached. The only potential use of the crash dumps generated by the EXE that I can see is to debug a crash that can't be reproduced locally, i.e. when the player who gets the crash doesn't know how to debug and the developer who does know doesn't get the crash. Not sure if any modders have used crash dumps productively.

I guess you've already tested whether Dave_uk's (original) mod crashes when (auto-)playing one of the LoR scenarios and whether LoR combined with GEM crashes. So the problems seem to arise from the combination of Dave_uk's changes and GEM? You could try the previous version of Dave_uk's mod; that one had supposedly been tested more. Beyond that, I think you'd either have to get into DLL modding in order to use the Visual Studio debugger (or at least to enable runtime assertions) or experiment with changes to the GEM files. Not sure if that's just a WBSave; could try removing all but 2 players etc. For a crash after ending the turn, the last few lines in PythonDbg.log and the BBAI log might provide some clue. The logs will just show things that happened some time before (or possibly just before) the crash, e.g. "The AI is choosing what to produce in York." Not necessarily helpful.

Thanks.
Up to now, I have been able to revert the ctd's or hangs by changing something I did with my units.
My laptop(ryzen3) only has 4GB, which might be a problem. I might try the same saves on my desktop with more RAM.
I have played many 100s of hours of LoR with only 1 ctd ever, so like you say, it's probably the GEM map(not the mod, just using it as a scenario from WBS file).

Thanks again, and I will keep persevering.