3.5b did not fix the gamebreaking crash bug I pointed out earlier

[Vox Imperatoris]

I mentioned a crash in this thread, and I was told it would be fixed in 3.5b.

However, 3.5b has failed to fix the problem. The crash can be reproduced in one or two turns from the attached save file.

3.4b continues to work.

[Buster's Uncle]

You'll want to PM Yitzi, so he'll see this in a timely fashion.  -Be polite, please.

[Vox Imperatoris]

Okay, I'll send a PM.

And of course I don't mean to demand that anyone work for free for my benefit! I just wanted to point it out.

[Yitzi]

Thanks, I'll check it out.  I thought I fixed it...

[MercantileInterest]

  Yitzi is a valuable resource. Don't treat him lightly.

[Yitzi]

I'm actually fairly tolerant of such things.

This is strange, as it is working properly for me.

Can you check the version number in-game, just to make sure that you are in fact using 3.5b?  If you are, the only thing I can think of is if you want some instructions on how to use a debugger to gather information from your own computer's behavior.

[gwillybj]

I thought I'd mention I'm running 3.5b with no issues.
I installed the game, then the WinXP patch, then Yitzi's patch.

[Vox Imperatoris]

Yitzi, thanks for your response!

I can confirm that I just tested it again, made sure the version number said 3.5b, and saw it crash again in exactly the same place (in the inter-turn period between 2268 and 2269).

If you can provide me with the instructions to gather information from my system for you, I'd be happy to help. By the way, I'm running Windows 10, 64-bit, using the GOG version of SMACX with your patch on top.

Edit: just to make sure, I tried doing a clean reinstall of the game. Got the same crash.

[Yitzi]

Yitzi, thanks for your response!

I can confirm that I just tested it again, made sure the version number said 3.5b, and saw it crash again in exactly the same place (in the inter-turn period between 2268 and 2269).

If you can provide me with the instructions to gather information from my system for you, I'd be happy to help. By the way, I'm running Windows 10, 64-bit, using the GOG version of SMACX with your patch on top.

Edit: just to make sure, I tried doing a clean reinstall of the game. Got the same crash.

Ok.  So download ollydbg (http://www.ollydbg.de/), open it up, load the SMACX executable, and hit "run".  The game should start.  Reproduce the bug again, and instead of crashing it should switch to ollydbg, which will have some sort of error message.  Take a screenshot of the resulting screen, and PM it to me, and that should at least give me enough information to give you further instructions.

[Vox Imperatoris]

Thanks for the advice!



This is the error message I get: "Access violation when reading [045CB024]". When I do "shift+run" as the program prompts, it tells me "application was unable to process exception".

[Yitzi]

Yeah, shift-run is for certain problems that don't cause actual crashes.

Unfortunately, the problem seems to be in an often-used function, which makes it harder to find the specific point at which the problem happens.  It may be best to modify the program slightly (in a way that won't actually affect anything in how it works) to create a suitable breakpoint:
At 4B428C, it says JMP 005B435B.

We want to replace that with the following instructions (one line after the next; you can double-click in the third column to edit the instructions; highlight multiple NOP's so that there's enough room for it):
CMP DWORD PTR SS:[EBP-8], 1000000 (that's 6 0's)
JL 005B435B
JMP 005B435B

Then set a breakpoint (easiest way is to double-click in the second column, it should turn red) on the JMP instruction (it should be 5B4299), and run it.  When it hits the breakpoint, post a screenshot (preferably with the window maximized so that I can see more), and then run it again and post a screenshot of the next time it hits the breakpoint (and maybe the third as well).  If it hits the crash (i.e. the "access violation when reading" message) before hitting multiple breakpoints, let me know that as well (though I don't think it will).

(When you're done, if you close ollydbg without saving to disk, the changes will not be maintained, though as I said they don't really have any effect other than making a suitable breakpoint.)

[Vox Imperatoris]

I'm sorry; I've never used an editor like this, and I'm not very familiar with how they work.

I can't find an address "4B428C". I assume I'm supposed to be looking in the top-left box, in leftmost row?

The addresses go straight from 4B428A to 4B4290.

[Yitzi]

Sorry, I wrote 4B428C, but that was a typo; I meant 5B428C (so it should be just below the information with the screenshot you showed me).

[Vox Imperatoris]

Thanks for the correction!

Sorry for the delay on my part, but I ran it again and unfortunately got the crash before hitting the breakpoint.

You can see the result here:



I assume this is harmless, but in order to put the instructions in where you said, I had to overwrite one of the lines reading "DD 90909090". I've included one of them for reference here:



It seems like a filler line, and, again, it was necessary in order to put the instructions in where you requested—but I wanted to point that out to you.

[Yitzi]

Yeah, 90 stands for "no operation" and is used for filler, and DD 90909090 just means that for some reason (probably because it's designed for analyzing code that was compiled, rather than compiled and then heavily modified in assembly) Ollydbg thought that line was data, but it wasn't.

So next, try the same thing with a breakpoint at 5B428C (if you didn't save the changes and they're gone, there's no need to redo them).  It's very possible that it will again hit the bug before the breakpoint, but whether it does or not will give me more information.