3 replies to this topic

[aqrit]

anyone/scient have any plans to fix the crash on exit?

It looks like some uninitialized value is being passed to delete[]

I think the reason it effects windows x64 more is just because the loader leaves slightly different garbage on the stack

anyways on the 4cd v1.1 if you place a breakpoint on WinMain (004357FB) the garbage value is at ( esp - 0x4 + 0xFFFFB118 + 0x3562 + 0x5A + 0x8 + 0x12 )
this should be initialized to zero I think...

or one could simple nop the clean-up call (004358E8) at the end of WinMain
since the process is exiting the game shouldn't be doing clean-up anyways (is this true for win9x?)

[scient]

Yah, I looked into this and you're right. It's passing an invalid memory pointer to delete() which gives that error message on exit. It looks like it has to do with how heap is working for Win 95/98 vs Vista/7 since Microsoft Application Compatibility toolkit with EmulateHeap enabled resolves issue.

If you enable this compatibility fix on a process, then all the OS-level heap functions (from HeapCreate to LocalLock to GlobalReAlloc and everywhere in between) are redirected to replacement functions that emulate the Windows 95 heap down to the very last detail.

For example, you might have a program that allocates two blocks of memory, frees them both, then allocates a third block of memory and relies on the fact that the pointer returned by the third allocation is numerically identical to the pointer returned by the first allocation, because that’s what happens on Windows 95.

You might have a program that overflows a heap buffer and suffers no serious consequences because the memory that comes after the heap buffer is not being used for anything, or at least that's what happens on Windows 95.

You may also be running a program that frees memory, then accesses the freed memory some time later, expecting that the memory will still contain the values that it did when it was freed and hasn't been reused for some other memory allocation, or at least it isn't reused on Windows 95. (Or even scarier, the program relies on the fact that the values change after the memory was freed in a very particular way!)

http://technet.micro...e/ff625273.aspx

Anyway, you're right I don't think clean up really matters since it is exiting. I put together this quick patch that will resolve issue by zeroing that invalid ptr in clean up function so delete just skips passing it to HeapFree. Works fine on Win7 x64, I'm hoping to get someone to try it out on WinXP. Do you know if it was just Vista/7 that had issue?

Fix error message from showing up (Win7/Vista) when game is exiting by zeroing out invalid memory pointer on stack that gets passed to delete()
search: 89 8D 2C FF FF FF 8B 85 2C FF FF FF C7 00
replace 2cd: 89 8D 2C FF FF FF C7 01 04 CC 8D 00 C7 81 D6 35 00 00 00 00 00 00 90 90 90
replace 4cd: 89 8D 2C FF FF FF C7 01 F4 BB 8D 00 C7 81 D6 35 00 00 00 00 00 00 90 90 90

Edited by scient, 05 February 2012 - 03:53 PM.

[aqrit]

the bad heap pointer is coming from an uninitialized value on the stack
the game expects the stack to be zero'd
when application compatiblitly "shims" are used there is a higher water mark on the stack than on old systems
so less of the stack is zero'd

on win7 x86 I can actually toggle the crashing off by disabling the "fast user switching shim" then running sdbinst /c .. so no app compat stuff is loaded at all.

EmulateHeap resolves the issue only because it pipes all calls to HeapFree through IsValidHeapPointer before trying to free the memory

I don't recall it crashing on XP sp3 (which has app compat ) ( I can test on XP x64 but it shouldn't matter )

Edited by aqrit, 07 February 2012 - 06:59 PM.

[scient]

Ahhh that makes sense. Yah, I'd be interested to see how XP reacts just for sake of it if you don't mind. Otherwise, above patch data should make its way into next release of fixpack.