Info on debugging requested: trying to run "Hearts of Iron"

[Mike Hearn]

> 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