Help with debugging needed

James Liggett jrliggett at
Thu Aug 11 15:06:31 CDT 2005

On Thu, 2005-08-11 at 21:39 +0000, Stefan Dösinger wrote:
> Hello,
> I am trying(once again) to get Empire Earth [1] running with wine. After 
> solving a few problems[2], I've run into a strange access violation crash. It 
> looks like a buffer overrun, followed by a return to an invalid adress.
> A +relay,+snoop trace gives this:
> ...
> 0009:CALL Low-Level Engine.?Deactivate at GERasterizer@@UAEJXZ() ret=7e2b9a14
> 0009:CALL Low-Level Engine.?Dereference at UReferenceCounter@@QAEXXZ() 
> ret=7e2bd6c5
> 0009:RET  Low-Level Engine.?Dereference at UReferenceCounter@@QAEXXZ() 
> retval=7f24fa70 ret=7e2bd6c5
> 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5
> 0009:Ret  ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f0294c5
> 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506
> 0009:Ret  ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f029506
> 0009:CALL MSVCRT._except_handler3(<unknown, check return>) ret=7beb649b
> 0009:CALL MSVCRT._XcptFilter(<unknown, check return>) ret=00665947
> 0009:Call kernel32.GetLastError() ret=7800385f
> 0009:Ret  kernel32.GetLastError() retval=000005b4 ret=7800385f
> 0009:Call kernel32.TlsGetValue(00000000) ret=7800386d
> 0009:Ret  kernel32.TlsGetValue() retval=7f180f80 ret=7800386d
> 0009:Call kernel32.SetLastError(000005b4) ret=7800387e
> 0009:Ret  kernel32.SetLastError() retval=000005b4 ret=7800387e
> 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71
> 0009:Call 
> ntdll.NtQueryVirtualMemory(ffffffff,9803a11c,00000000,7fc2f6e8,0000001c,7fc2f6a8) 
> ret=7fd1aae1
> 0009:Ret  ntdll.NtQueryVirtualMemory() retval=00000000 ret=7fd1aae1
> 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743
> 0009:Ret  kernel32.IsBadCodePtr() retval=00000000 ret=22d2b743
> 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,00000001,00000000) 
> ret=7fccb9b9
> 0009:Ret  ntdll.NtCreateEvent() retval=00000000 ret=7fccb9b9
> wine: Unhandled exception (thread 0009), starting debugger...
> ...
> The crash messages look a little bit different every time, with illegal 
> instructions / access violations or even a Segmentation Fault without 
> starting winedbg at various addreses(Attached file crashes). On very rare 
> occasions, this crash doesn't occur, and the game continues to load and 
> crashes later in some ddraw function. Instead of crashing it complains about 
> a corrupted heap:
>  err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is 
I've also seen similar problems with related heap functions in WinMM.
I'm told that there's something wrong with the heap manager library Wine
> not prev for in-use 0x7fe01cb0
> I've looked at a +heap trace, but I couldn't find anything usefull.
> (See ee-nocrash for a log). I've also attached a normal log without any 
> special debug flags set(ee-normal.log.gz). I've added a few ERR statements 
> for testing in some functions.
> So my questions are:
> *Am I right with my suspection that the problems are caused by a incorrect 
> return?
It's possible. I'm working on a problem like that with palm desktop. But
you won't know until you debug it :) It could be nasty to fix though. 
> *How can I get a disassembly of Low-Level 
> Engine.?Deactivate at GERasterizer@@UAEJXZ or simmilar functions. I didn't find 
> this symbol.
If I had to guess, I'd say these functions are in the game itself, most
likely in one or more DLLs. Your best bet here is to use a good
disassembler. My personal favorite is IDA. You can find a demo version
here: This version works just
fine for this sort of thing. 
> Thanks for your help,
> Stefan Dösinger
> [1]
> A demo is available at 
> but I haven't checked wheter it produces the same results.
> [2]
> Other users reported a msvc runtime error, apparently caused by an error 
> returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with
> cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in 
> this case.
> Furthermore it checks for sound support and the OS version(setting it to Win98 
> or WinME is recommended) and it needs native msvcrt(It even seems to ship 
> it's own version)
I've had a few programs with this behavior. Programs ship with copies of
this library to make sure that it's available, since they can't assume
that it'll be there. Normally I stick with native msvcrt in pretty much
all cases. I hope this advice helps. 

Good Hunting ;-)


More information about the wine-devel mailing list