Info on debugging requested: trying to run "Hearts of Iron"
simon at ecnetwork.co.nz
Thu Aug 19 01:43:14 CDT 2004
I recently tried to run the MS-Windows WWII strategy game "Hearts of
Iron" using Wine on Linux. And it *very nearly* works. In fact, it's so
close I'm trying to debug the problem in the hope of getting it working.
I hope that someone here can give me a few wine debugging tips.
Actually, the game runs perfectly - absolutely "gold" standard. I gave
it a 5-hour "stress test" ;-) and did not experience a single problem.
There are some minor problems on startup, but there are reasonable
workarounds for those.
The problem, though, is that saved games cannot be loaded.
Unfortunately, this is a show-stopper as a game of HoI typically takes
several days to play! Fortunately the problem is 100% repeatable.
FYI: I'm running Debian Sarge on x86, no native windows partition. I
first tried the latest debian wine package, and then rebuilt from CVS
HEAD code of Fri 13 August (possibly a bad day to choose :-). Exactly
the same behaviour occurred.
Info on the game can be found here: http://www.heartsofiron-game.com/.
It's a WWII strategy game with pleasant but not intensive graphics.
When running "wine HoI.exe" and trying to load a saved game, a message
wine: Unhandled exception (thread 0009), starting debugger..
Usage: winedbg [--auto] [--gdb] comdline
There is then no response to the keyboard; no debugger prompt or
anything. Is this meant to start a debugger interactive session here, or
am I supposed to somehow start a debugger and point it at the wine
process? If so, info on how to do so would be appreciated.
I ran "winedbg HoI.exe" and got exactly the same behaviour, though with
a bit more info:
First chance exception: page fault on read access to 0x00000006 in
32-bit code (0x004191fb).
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 -
EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44
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
=>1 0x004191fb (0x406bfe94)
2 0x005af5b2 (0x406bff20)
3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32
4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000)
0x004191fb: movl 0x6(%ecx),%ecx
Qn: is there any way of getting function names in that backtrace rather
than just addresses? I've tried "CFLAGS=-g ./configure" when rebuilding
wine, but haven't had time to test the resulting wine binaries.
And then is there a way to step through at the source rather than
It's apparent here that %ecx is null when not expected to be, resulting
in a bad access to memory address 0x00000006.
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!
Any suggestions on how to make progress on this issue are welcome.
Pointers to documentation on debugging this sort of thing are very
By the way, I'm an experienced c/c++ developer on unix/linux, but know
very little about Windows programming (and frankly would prefer to leave
it that way :-). It's been a while since I've used gdb and friends, but
can brush up on that if it's useful.
PS: Congrats to the Wine team. I was most impressed how well HoI ran on
More information about the wine-devel