Good luck! Please don't be discouraged if you can't crack this one though, both me and Lionel have looked at Dungeon Keeper (1 and 2) and couldn't figure out why it doesn't work. Lionel has been a Wine hacker for 5+ years now! If you can't get DK to work, or are finding it too frustrating, perhaps move on to another program and see if it's any easier?
Hehe, ok ... but I'm not giving up yet;)
Unhandled vs first chance, hmm, how to explain this. Well in the debugger you can trap *all* exceptions, even if the program itself may in turn catch that exception and deal with it. So it's called a first-chance because you the debugger get the first chance to deal with it. Unhandled just means there was an exception and the program didn't do anything with it, so it falls back to the debugger (in Windows you would see the crash dialog). Notice how the numbers are the same, and the fault (writing to null) is the same.
Ok, I understand.
2. How to compile debug information into the 32bit DLL's so I don't get 'No debug information in 32bit DLL' anymore and maybe some better info? I tried 'configure --enable-debug && make depend && make && su -c "make install"' to no avail.
They have debugging info in, but unfortunately there has been breakage in the debugger recently which has not yet been fixed in CVS. This is very bad :( EricP sent a patch here which works great for me and fixed all my debugger problems, try looking in the archives for Jan and December looking for it (it was sent to wine-devel not wine-patches iirc).
For now try setting WINELOADER to the path to your actual wine binary (wine-pthread)
That works.
No, they aren't called, they just happen to be the closest exported symbols the debugger could find. In general the names given to you when there are no debug symbols are useless. Look:
1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL2.DLL)
see the +0x17fd here? That means the crash occurred in some code a long way from the start of that function, who knows where without debug symbols though.
Ok.
IIRC keeper makes only one or two API calls before crashing, both of those calls are trivial and succeed (setting a timer or something I think) so it's more likely to be to do with the layout of an in memory struct or something. Remember that the TEB is stored in %fs, if you see references to that register.
Yep. It's setting up a timer which in turn creates a thread as far as I understand until now. There's something like a stack overflow going on _maybe_. I've put a backtrace dumping to the start of RTLLeaveCriticalSection which shows more than >1024 stackframes being used near the occurance of the prob - it's showing a re- peating pattern, as does wine --debugmsg +relay,+seh.
Here a little excerpt of the latter:
...
...
...
0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f
0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9
0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9
0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f
0013:RUnhandled exception: page fault on write access to 0x00000000 in 32-bit code
(0x00406062).
In 32-bit mode.
0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): movb $0x0,0x0(%eax)
Wine-dbg>walk thread
process tid prio
00000011 (D) C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE
00000013 0
00000012 0 <==
00000008
00000009 0
Wine-dbg>I've set stack_reserve to 8MB min. That didn't make much of a difference. Unfortunitely I run across a bunch of debugger bugs (I think) following the creation of the timer thread, I decided to put these problems into another post though. I wanted to step to the point where the thread comes alive when the debugger left me at/near a syscall :( I think it has something to do with this thread cause the exception you get is always another depending on what you currently debug ... somehow asynchronous, as the above :)
-- Thank you, Frank
