[FIXED] Save load crash investigations

[Flocke]

Hey there, while testing some assembler hooks, I came across the 0x000b6c66 fault offset crash again and managed to reproduce this to have a closer look.

One other crash I get every other savegame load is:

Code: Select all

trek.exe 0x000b6c66

This one sometimes even shows up when I solely keep loading unmodified vanilla games. But with modified files it often becomes more frequent. With some games it repeatedly already shows up each second time I load the save. Then when I have rebooted it becomes less frequent again. Therefore my guess is that it is related to some dead memory references, e.g. some array index like a system index that I missed to update. But since it also happens on vanilla games it might also be just random bad luck.

It's sub_4B77E0 race_rst_start_set_races_in_game_via_RToSInfo -> updated races in game bitmask for race IDs 32+ -> loaded [gameInfo+274h]

A strange code also related to the read race crashes during galaxy generation. Shouldn't be used for loaded games, but there is some odd x-ref calls.

Since it also happens with unmodded vanilla trek.exe it can't be outdated/flawed patches in that subroutine?

First of, other than I assumed in viewtopic.php?p=41435#p41435 the fault offset does not refer to the file offset, but to the loaded application base offset. Which often enough happens to be same, but not this case. Relative to base offset 400000h it actually crashed at asm offset 0x4B6C66.

Having the debugger attached I found why:

Screenshot 2026-07-17 065407.png

Screenshot 2026-07-17 065726.png

Here you see ecx has become a negative value, which messes up the copied data offset.

With further analysis I found that by the chop call at asm 418E32 a double of 0 gets rounded to -5 = 0xFFFFFFFB!!
edit: Actually I failed to notice that it already was set to the double value of -5.0 = [0x00000000][0xc0140000].

Screenshot 2026-07-17 104502.png

By the Universe_Sector_GetSectorPos call at asm 418EE3 the eax register, read back from [esp+24h+var_C] at asm 418E3B, is used as the map sector index, and of course the map starts at index 0 and not in the negative range!

If we leave out the chop call, it might be fixed I guess, but due to precision limitations, it often makes sense to round floating points to upper or lower nearest integer before conversion to exactly prevent issues like this - well if only the rounding worked...

The full callstack I deduced as follows:

Code: Select all

418EE3         call    Universe_Sector_GetSectorPos
42B5A1         call    AI_AIPatrol_418E00
419197         call    AI_AIMilEvl_42B4F0
41AD33         call    dword ptr [edx+10h]
4E7875         call    AI_AIColony_41AD30
4DD207         call    UI_MainGal_MapAI_4E7750
4D9EE2         call    UI_MainGal_GalMap_Initialize
4B8F80         call    [ebp+UIDsc_ScreenDescriptor_t.func_InitScreen]
4B9468         call    UI_Screens_LoadScreen
4F00EA         call    UI_Screens_Init2
4F0925         call    UI_LoadSave_LSScreen_LoadOrSave
52D151         call    [ecx+UIWgt_PushButton_t.clickCallback]
52CD9E         call    PushBtn_OnLMB_Up
53D6DC         call    [ecx+UI_Widget_t.eventHandler]
513235         call    Widget_HandleMouseInput
512CD4         call    Graphics_HandleMouseInput
401642         call    Graphics_HandleUserInput

[Flocke]

Since we have a file attachment limitation, here two Vanilla 1.0.4 savegames to reproduce this issue:

game8.sav

game11.sav

First load game8.sav, then game11.sav and then game8.sav again and for me it (for now) reliably crashes with above error.

[Spocks-cuddly-tribble]

Yeah, this mess looks like a bug.

418E4E         jnz     loc_418EDD  // eax is never a sector index in this case

Not sure if just nop works here or more edits are required.

[Flocke]

Not sure if just nop works here or more edits are required.

And I hoped that you would give me a suggestion how to fix this mess!

[Spocks-cuddly-tribble]

And I hoped that you would give me a suggestion how to fix this mess!

Sorry mate, I've yet to download and test tunderchero's great installer.

This one is a multifactorial issue, the triggered/bugged code path might not even matter depending on the chosen fix concept.

I guess your project focus would be sorting out all save/load game data/code issues (here reinitializing or recreating problematic active game data when cross loading different saved games). There is a million cases of this issue in BotF, with a million ways to go about them each. They suck, but are no priority projects in my book.

My focus would be the fatal bias to use quite useless average ship strengths in own and hostile fleets in specified areas instead of the total fleet strengths for AI patrol tasks. This bias is quite easy to exploit and weakens the AI. We talked about this in context of AI data analysis -> unused ship sorting codes.

[Flocke]

During further tests, this crash kept bugging me, so I had another look. As I found, the chop to zero rounding actually works perfectly fine. Instead when it crashed the whole grid table is full of negative values in the range of -3.0 to -5.0.
Therefore I started to search where it actually is getting initialized and did some further debug tests.

Turns out that on first load the allocated GridTable at asm<403B71> resp. asm<418F54> / asm<47A6E4> for me always (during my tests) happens to be zero initialized. At that point the allocated memory however is not explictly initialized yet. And in fact I didn't find it being initialized anywhere.

When then I load another savegame, some values already get messed, by luck the values however often are in the positive range so when used to index the GridMap it causes a buffer overflow reading some invalid values but doesn't necessarily crash. Other times however I happen to find a GridMap full of negative values in the range -3.0 to -5.0. So it's most likely some reused memory garbage that is causing above crash.

[Flocke]

I gave it a try and fixed that very annoying issue with below patch, which confirms it is an uninitialized memory issue.

Code: Select all

NAME: Random Savegame Load Error Fix
DESC: Fixes an uninitialized memory bug for the AI GridMaps used by the patrol command.
AUTHOR: Flocke
URL: https://www.armadafleetcommand.com/onscreen/botf/viewtopic.php?p=66351#p66351

>> 0x0001835d 8B 03 5E 5A 59 5B C3 00 00 00 00 00 00 00 00 00
<< 0x0003e908 6A 00 6A 00 E8 7A 16 06 00 8B 03 5E 5A 59 5B C3

#00418F5D    6A 00             push 0           // 0-initialize 8 byte double value
#00418F5F    6A 00             push 0
#00418F61    E8 7A 16 06 00    call sub_47A5E0  // call Game_Map_GridMap_Fill, with eax = the allocated GridMap
# followed by former pop & return