Hi Pavel,
Right, my app also crashes in a different place under winedbg, although
it crashes in the same winedbg place under gdb.
I took a closer look at wine --winver nt40 --debugmsg +all.
I found something interesting. If I search for queue_exception, I find
that there is an exception raised before the LoadOEMCall, about
328klines in:
0806d398:Call
kernel32.VirtualProtect(00459000,00000018,00000002,40616e74) ret=0075fd82
0806d398:trace:virtual:VirtualProtect 0x459000 00000018 00000002
0806d398:trace:virtual:VIRTUAL_SetProt 0x459000-0x459fff c-r--
View: 0x400000 - 0x765fff 28
0x400000 - 0x400fff c-r--
0x401000 - 0x458fff c----
0x459000 - 0x459fff c-r--
0x45a000 - 0x758fff c----
0x759000 - 0x765fff c-rw-
0806d398:Ret kernel32.VirtualProtect() retval=00000001 ret=0075fd82
0806d398:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0
0806d398: queue_exception_event( first=1,
record={context={flags=00000000,eax=00002000,ebx=40110dc4,ecx=404260f0,edx=40426174,esi=00456000,edi=00000000,ebp=40616e68,eip=00760dcd,esp=40616e48,eflags=00010206,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x760dcd,params={0,456010}}
)
0806d398: queue_exception_event() = 0 { handle=0 }
0806d398:trace:seh:EXC_CallHandler calling handler at 0x761b10
code=c0000005 flags=0
0806d398:Call kernel32.SetLastError(00000000) ret=00760711
0806d398:Ret kernel32.SetLastError() retval=00000000 ret=00760711
0806d398:Call kernel32.GetLastError() ret=00760303
0806d398:Ret kernel32.GetLastError() retval=00000000 ret=00760303
0806d398:Call kernel32.CloseHandle(00000028) ret=00760f0d
0806d398: close_handle( handle=40 )
0806d398: close_handle() = 0 { fd=10 }
0806d398:Ret kernel32.CloseHandle() retval=00000001 ret=00760f0d
0806d398:Call kernel32.GetLocalTime(40504a5c) ret=00761d66
0806d398:Ret kernel32.GetLocalTime() retval=00000000 ret=00761d66
0806d398:Call kernel32.GetLocalTime(40504a5c) ret=00761cd4
0806d398:Ret kernel32.GetLocalTime() retval=00000000 ret=00761cd4
0806d398:Call kernel32.GetModuleHandleA(40504a58 "USER32") ret=0075fbdf
0806d398:Ret kernel32.GetModuleHandleA() retval=406e2000 ret=0075fbdf
0806d398:Call kernel32.GetProcAddress(406e2000,0075b05c "MessageBoxA")
ret=0075fbfd
0806d398:trace:win32:MODULE_GetProcAddress (406e2000,MessageBoxA)
0806d398:trace:win32:PE_FindExportedFunction (MessageBoxA)
0806d398:Ret kernel32.GetProcAddress() retval=4077f8e0 ret=0075fbfd
0806d398:Call user32.MessageBoxA(00000000,0075d4e0 "C:\\My
Documents\\power-structure-demo.exe
(3.4) 12/08/01 16:19:00 - Dispatcher in"...,0075b3e8
"SHRINKER.ERR",00002030) ret=0075fc1a
0806d398:warn:dialog:MessageBoxA Messagebox
The eip mentioned in the queue_exception_event trace is the same eip
that winedbg (and gdb) segfault in. Notice the SHRINKER.ERR message that
comes afterwards. Also notice the exception handler at 0x761b10. This is
also inside the application, so it looks like the app sets up an
exception handler, and is all set to display an error message box.
Then comes another exception, about 900 lines later:
0806d398:trace:gdi:GDI_ReleaseObj (004c): leave 1
0806d398:trace:win32:_LeaveSysLevel (0x4082dfc4, level 3): thread
0x806d398 (fs 008f, pid 24366) count before 1
0806d398:trace:win32:_LeaveSysLevel (0x4082dfc4, level 3): thread
0x806d398 (fs 008f, pid 24366) count after 0
0806d398:trace:palette:GetSystemPaletteEntries hdc=004c,start=0,count=0
0806d398:trace:resource:RES_FindResource2 (000000b6, 0000000e,
40764cceL"", 0000, W, PE)
0806d398:trace:resource:RES_FindResource2 (00400000, 0000000e,
40764cceL"", 0000, W, PE)
0806d398:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0
0806d398: queue_exception_event( first=1,
record={context={flags=402d40e8,eax=0045f000,ebx=40110dc4,ecx=0045f000,edx=0000000e,esi=0000000e,edi=0045f010,ebp=40503f98,eip=40096688,esp=40503f88,eflags=00010216,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=4050401c,dr1=40504020,dr2=00000000,dr3=00000000,dr6=402d40e8,dr7=40504030,float={40504034,405042e8,402d40e8,40504040,402d40e8,40504048,ffffffff,00000000,ffffffff,402d40e8,4050405c,40504060,402d40e8,40504068,4010447e,40773882,400ed2fd,402d40e8,4050407c,40504080,402d40e8,40504088,4050408c,402d40e8,40504094,402d40e8,4050409c,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x40096688,params={0,45f00c}}
)
0806d398: queue_exception_event() = 0 { handle=0 }
0806d398:trace:seh:EXC_CallHandler calling handler at 0x400714d0
code=c0000005 flags=0
0806d398:trace:seh:EXC_RtlUnwind code=c0000005 flags=2
0806d398:trace:seh:EXC_CallHandler calling handler at 0x40070d60
code=c0000005 flags=2
0806d398:trace:seh:EXC_CallHandler handler returned 1
0806d398:warn:resource:RES_FindResource page fault
This time eip is in pe_resource.c in libntdll.so, the find_entry_by_id
method. The exception is handled by NTDLL.DLL.__wine_exception_handler
in libntdll.so.
Finally, about 2000 lines later, our friend the LoadOEMResource
exception occurs.
So we have three exceptions in a row. The first is apparently
intercepted by the application. The second is generated by trying to
display the message box popped up by the first exception. The third is
generated in LoadOEMResource, *probably* long after the application was
supposed to die from the second exception.
Does your trace show the same thing?
--Rob
> Hi!
> If run under winedbg, my app crashes differently than if run
without > it.
> It crashes very soon, probably not in LoadOEMResource.
> It's wrong that I can't C&P from the winedbg window, I would paste
the register and
> stack dumps.
> However, it's a page fault on read access to 0x000001f4 in 32bit code,
> there are 5 stack entries, the last two in
USER32.DLL.GetTaskmanWindow > (in libuser32.so)
> The offending instruction is movl 0x1f4(%eax),%ebx and eax is 0x0,
which explains the
> fault address. I didn't compile with debugging on so I can't supply
the source code
> fragment which makes the crash :-(.
> With regards, Pavel
