TTDLOADW.ovl is unstable.

[copperpen]

I am running Vista SP1 and have trouble with ttdloadw.ovl. I can play the game for a short length of time, and at that point the screen goes white and "TTDLOADW.OVL has encountered a problem and needs to close". I can restart at thr point where it crashed and carry on, but sooner or later the same thing happens. I have tried with the forcerebuild switch on and off, makes no difference. Attached is a zipfile with 6 crashlogs, my newgrf cfg and ttdpatch.cfg files.

Crash.zip

(7.97 KiB) Downloaded 218 times

.

I noticed while looking at the crashlogs that they all have the same error c0000005 which as far as I know is an access violation caused by accessing memory beyong the string. I only know that because I went and looked it up.

This is also happening on an XP machine so it cannot be a vista problem.

Mervyn

[Lakie]

With the executable of TTDpatch have you set the "Run this program in compatibility mode for:" and set the drop down box value to "Windows XP (Service Pack 2)"?
From my experience that tends to fix Vista killing TTDpatch randomly or when its lost focus.

Not sure if this is directly involved to your issue though, but it might be part of the Vista issue...

[Edit] I've looked at your crash logs, apparently both are caused by invalid esi values;
The first one I've found is "DrawMapIndustriesMode" (Windows IDB),
The second one is in "DrawMapContoursMode" (Windows IDB).

~ Lakie

[copperpen]

Thanks for taking a look. I was not in compatibility mode. I have set up a ttd using only the ttdbasew.grf and set compatibility mode. The same crash happened. I did notice that when the crash occured the map window was open, and I seem to recall that has been the case in all of the other crashes.

Latest crash log

CRASH006.TXT

(1.59 KiB) Downloaded 153 times

Mervyn

[DaleStan]

I expect either of the following fixes will make your problem go away:

1) Choose a different height and/or width. Pixel counts that are exact multiples of 4K (in other words, a width of 1024) often cause problems.
2) Do not move the mini-map such that the map portion of the window is beyond the lower-right corner of the screen.

@eis_os: Would allocating at least 3 bytes more than resolutionheight*resolutionwidth be likely to fix this problem? I can only find one malloc in procs/resolution.asm, but it is not obviously allocating a new video buffer. Or is the size of the video buffer not something that TTD/Patch controls?

[eis_os]

Actually there are two, and the Screenbuffer is doubled for extra protection... I don't see why TTDPatch would crash therefor... The block store redraw functions may crash however... (And I never had problems with 1024x768 fullscreen sizes)

[DaleStan]

Actually there are two, and the Screenbuffer is doubled for extra protection... I don't see why TTDPatch would crash therefor... The block store redraw functions may crash however... (And I never had problems with 1024x768 fullscreen sizes)

Yes, there are two mallocs, but the one at :583 is in an #if 0 block. The other (if I'm reading the code correctly) allocates memory to replace buffers that, in TTD, are 258 bytes long -- hardly long enough to be video memory.

Given the values of ESI in five of the six crashlogs (xxxxDFFD and xxxxDFFE) and that the crash is in a dword-sized instruction, this just makes me think "page edge fault". Even if that does imply either non-aligned pages or memory pages that are only 2K long.

[copperpen]

I expect either of the following fixes will make your problem go away:

1) Choose a different height and/or width. Pixel counts that are exact multiples of 4K (in other words, a width of 1024) often cause problems.
2) Do not move the mini-map such that the map portion of the window is beyond the lower-right corner of the screen.

I changed my screen width, and have not moved the map out of the TTD window. No crash now for a whole game year. Thanks.

[DaleStan]

I may have a fix for this bug. Currently, however (1) I don't know if it works, and (2) if it does, it's probably a rather like using a tac-nuke to kill a fly, though. Please help me make it a little more like a flyswatter:

Step 1: Using any 2.5 beta or a nightly, please return your settings to something that crashes when you move the minimap portion of the map window out the bottom-right corner of the screen. Please test all resolutions you usually use, and as many standard resolutions as come to mind. Report all tested resolutions and which of them caused crashes. Especially of interest is 640x480.

Step 2: Test the attached copy of TTDPatch for all resolutions which caused crashes in step 1 and report which resolutions still cause crashes, if any.

Step 3: Turn both newstations and enhancegui off, and answer question 2 with those settings. (optional)

[Flamelord]

I am using three standard (4:3) resolutions windowed on a 1280x800 display to test this (as I can reproduce it). I am running Vista, and TTDPatch is not in Windows XP compatibility mode for either executable.

ResWxResH:
- 2.5b9
- 2.6a0mod (DaleStanSpecialMod)

1024x768:
- crash
- no-crash (hang on focus lost)
800x600:
- no-crash (no hang on focus lost)
- no-crash (hang on focus lost)
640x480:
- no-crash (hung while viewing "preview" while mouse-overing window title in task bar)
- "Failed to find string #008E at 00648B8A, found 02/01 at 00555CE5 for findgiantscreenshotreadfromtmp in patchresol" -> OK -> <termination>

I actually have two different crashlogs from the 1024x768 crashes. At least, those are the crashes I think they are from. Attached.

Edit: I cannot test the third option because my startup map has been changed to one which I believe requires newstations on. As such, TTDPatch aimply crashes when it tries to load the map. I have two crashlogs from 2.5b9 doing that and one crashlog from 2.6a0mod doing that. Want any/all of those?

[Lakie]

If you are using Vista you must set the compatibly mode, otherwise Vista will kill it within seconds of focus loss.

~ Lakie

[Flamelord]

Ah, so that is a known issue with a known workaround. Any possibility of an actual fix?

[Lakie]

As I do not know how TTDpatch does the 'MesagePump' or what Vista expects from it, I'm inclined to keep the 'work around', which might as well be the solution.
If you'd like to fix the code in TTDpatch, please feel free to do it and give us a working patch.

~ Lakie

[DaleStan]

- no-crash (hung while viewing "preview" while mouse-overing window title in task bar)
- "Failed to find string #008E at 00648B8A, found 02/01 at 00555CE5 for findgiantscreenshotreadfromtmp in patchresol" -> OK -> <termination>

Oh, right. resolutionwidth 640 / resolutionheight 480 won't start in the alphas.

But, mostly, you confirmed what I was expecting, even if I can't explain why: 640x480 is immune. Nevermind that 640*480 is 75*4K.

Edit: I cannot test the third option because my startup map has been changed to one which I believe requires newstations on. As such, TTDPatch aimply crashes when it tries to load the map. I have two crashlogs from 2.5b9 doing that and one crashlog from 2.6a0mod doing that. Want any/all of those?

Not here. In a separate thread or on the bug tracker would be nice, though.
I doubt that there's any difference in the map-window drawing depending on the enhancedgui setting, but it couldn't hurt to check. It sounds like it's too much work, though. I'll check the code for patches, instead.

[Flamelord]

Speaking out of my depth here, but wouldn't the original programmer have put a workaround in his code to prevent that, since (IIRC) the game was originally locked to 640x480?

[DaleStan]

Well, the way I would have fixed that is to add a couple extra bytes to the end, but that would work for any resolution, and I don't see why Oskar would have patched it out.

I suppose it could be that DirectX always allocates an even number of pages, so the 75-page 640x480 is protected, but 1024x768 and 1280x1024 are not.

[eis_os]

a) TTD(Patch) can work in several modes depending how it recognizes the system (GDI / DirectX)
b) A lot of people tested with 1024x768 with no problems
c) The resolution switches brute force changes all locations of 640 and 480 to be bigger to the request Screen Resolution and don't give up to early when searching specific modes.
d) If TTD can't start in fullscreen mode (because DirectX tells it can't alloc the screenbuffer, it does a window mode failback)
e) Personally I don't play with the minimap so any problems are unknown to me, but the MiniMap is changed by other TTDPatch switches too...

TTDPatch resolution switches may write outside the right pixel lines (a reason why the horizontal resolution width has to be a multiply of 4, and 32 on some old ATI cards / drivers), but there is as far as I can say enough room and the DirectX/GDI calls should be good. Expect mode 5 I never got working right and is set to mode 4 automatically. (TTConfig Modes).

Note if a DirectX call fails, you should get some DirectX error...

Vista changes the way DirectX is handled, this could create problems with restoring surfaces (the Windows TTD code is not patched in that part) and could theoretical produce a hang.
TTD trying to restore it without a success and not doing anything anymore - this could be connected to TTDPatch code in the minimap, but that isn't possible to explain in a forum topic, but I doubt there is really a connection. Specially allocated memory parts of the TTD Dos version in special memory regions to be faster.

Feel free to debug all DirectX calls, but I doubt it's a memory problem, I guess some patch code simply assumes a register and sometimes a register is simply wrongly filled. -> You get a crash or well a hang as TTD(Patch) never exits in some loop.


-edit-

Ohh, and about the 4 times multiply, well TTD never had any need for some guards with fixed screen sizes, and me was simply to lazy to change all code trying to understand odd screen widths. I can't remove something TTD never had...

[DaleStan]

If it's not a page-edge fault, then why does my fix make the crash go away?

The only change I made was to make the OR only OR up to the highest non-zero byte of edx, instead of always using all four bytes.