I ran "winedbg HoI.exe" and got exactly the same behaviour, though with a bit more info:
<output> First chance exception: page fault on read access to 0x00000006 in
Normally means something like this:
struct something *a = 0;
a->some_member;
(obvious I guess but I thought i'd say anyway).
FWIW %ecx normally == this in C++ apps. So I'd say this was a vtable deref on a null object pointer.
32-bit code (0x004191fb). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 - RIP1) EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44 ESI:418736c0 EDI:45ae16e3 Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060:
Yes well stack dumping is kinda broke by the recent debugger changes.
Backtrace: =>1 0x004191fb (0x406bfe94) 2 0x005af5b2 (0x406bff20)
I don't think this is Wine code.
3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x406bfff4) 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x004191fb: movl 0x6(%ecx),%ecx Wine-dbg>
</output>
I also tried the "WINEDEBUG=+relay" option as recommended in the wine docs. However after leaving the program running overnight, and having generated 3 gigabytes of log output, the point where the bug occurs hadn't been reached. I think that what's happening is that there is a thread (0011) which is driven by timer ticks [probably doing GUI or sound stuff], and that because HoI is running much more slowly under +relay, that the thread doing the load-game work (0009) isn't actually getting any CPU time at all. NB: the log was only 3GB because I used grep to discard output about RtlEnterCriticalSection and RtlLeaveCriticalSection. Without that, the log would be closer to 30GB!
You can use RelayInclude/RelayExclude in the config file to eliminate those.
Any suggestions on how to make progress on this issue are welcome. Pointers to documentation on debugging this sort of thing are very welcome.
It's tricky. For this sort of thing I'd normally work backwards from the disassembly but I'm not sure whether winedbg disassembly still works nicely with showing you API calls and such ....
One thing would be to try and disable any sound threads by switching sound off in the game so you can get a +relay,+tid trace.
thanks -mike