OLE32.DLL exception when loading some Singleplayer missions
First check
- [X] The issue happens on the latest official version of Phobos and wasn't fixed yet.
- [X] I agree to elaborate the details if requested and provide thorough testing if the bugfix is implemented.
- [X] I added a very descriptive title to this issue.
- [X] I used the GitHub search and read the issue list to find a similar issue and didn't find it.
- [X] I have attached as much information as possible (screenshots, gifs, videos, debug and exception logs, etc).
Description
If saving the game when a unit is attacking enemies' base structures, it will not load successfully, leaving no internal error thrown, nor useful information in debug.log. Debugger tells it raised exception at 0x76AFBB7 of ole32.dll while conflicts occured when writing to 0x1a84f1.
Stack trace stopped at OleLoadFromStream(IStream* pStm, const_GUID & iidInterface, void** ppVObj) line 1101 of a socalled cmonimp.cxx.
Phobos Version
b28
Conditions to reproduce
Mod environment: Mental Omega 3.3.6, with cncnet5.dll, cncddraw renderer Mission: Soviet 24: Death's hand RA2MO: ToolTipDescriptions=yes ShowBuildingPlacementPreview=yes
Hold any building to be placed
INI code
No response
Steps to reproduce
- After the debut, use the given 2 apocs rush to the closest enemy's conyard, meanwhile build something till complete and hold it
- Attack the Epsilon barracks without actually destroying it.
- Attack the Epsilon conyard and save the game immediately
The previous conditions are not strict, probably you don't need to have any building on hold or attack the barracks without destroying it 4. Load the game, it may crash when loading ...
Expected behavior
Ares alone and phobos b26- will not create such a loading issue
Actual behavior

Additional context
No response
Hm have you tried compiling Phobos with stream_debugging_t set to true?
Hm have you tried compiling Phobos with
stream_debugging_tset to true?
I did, nothing more is shown
Can someone test this with commit 4245094aefbf6efa46a2f619fee0ed79c97d2f51 ?
Can someone test this with commit 4245094 ?
It seems it did fix it... At least I didn't manage to reproduce it with my old methods