Robert Baruch
2001-Dec-08 15:36 UTC
LoadOEMResource crash [Was: Re: Problem report: SHRINKER.ERR, fix to DEVICE_Open/CreateFileA? ]
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
Pavel Troller
2001-Dec-08 16:40 UTC
LoadOEMResource crash [Was: Re: Problem report: SHRINKER.ERR, fix to DEVICE_Open/CreateFileA? ]
> 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:My first exception comes about 74k lines and it looks like 0806ea10:Call kernel32.VirtualFree(41428000,00004000,00004000) ret=004016fb 0806ea10:trace:virtual:VirtualFree 0x41428000 00004000 4000 0806ea10:trace:virtual:VIRTUAL_SetProt 0x41428000-0x4142bfff ----- View: 0x41420000 - 0x4151ffff (valloc) 0x41420000 - 0x41427fff c-rW- 0x41428000 - 0x4151ffff ----- 0806ea10:Ret kernel32.VirtualFree() retval=00000001 ret=004016fb 0806ea10:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 0806ea10: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=414243b0,ecx=004464f8,edx=41426424,esi=414243b0,edi=00000000,ebp=405e5c54,eip=00462533,esp=405e5bd4,eflags=00010246,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=0x462533,params={0,1f4}} ) 0806ea10: queue_exception_event() = 0 { handle=0 } 0806ea10:trace:seh:EXC_CallHandler calling handler at 0x46257b code=c0000005 flags=0 0806ea10:Call user32.LoadStringA(00400000,0000ffd3,404d4358,00000400) ret=00404c19 0806ea10:trace:resource:LoadStringA instance = 400000, id = ffd3, buffer = 404d4358, length = 1024 0806ea10:trace:heap:HeapAlloc (40390000,00000002,00000800): returning 403fd838 0806ea10:trace:resource:LoadStringW instance = 400000, id = ffd3, buffer = 403fd838, length = 1024 0806ea10:trace:resource:RES_FindResource2 (00400000, 00000006, 00000ffe, 0000, W, PE) 0806ea10:trace:resource:RES_LoadResource (00400000, 00472ac0, PE) 0806ea10:trace:resource:LockResource (00476b48) 0806ea10:trace:resource:LoadStringW strlen = 4 0806ea10:trace:resource:LoadStringW L"Read" loaded ! 0806ea10:trace:resource:LoadStringA "Read" loaded ! 0806ea10:trace:heap:HeapFree (40390000,00000002,403fd838): returning TRUE 0806ea10:Ret user32.LoadStringA() retval=00000004 ret=00404c19 0806ea10:Call kernel32.VirtualQuery(00462533,404d48c0,0000001c) ret=0040a6e8 0806ea10:Ret kernel32.VirtualQuery() retval=0000001c ret=0040a6e8 0806ea10:Call kernel32.GetModuleFileNameA(00400000,404d47bb,00000105) ret=0040a70a 0806ea10:trace:string:lstrcpynA (0x404d47bb, "D:\\setup.exe", 261) 0806ea10:trace:module:GetModuleFileNameA D:\setup.exe 0806ea10:Call user32.LoadStringA(00400000,0000ffdf,404d4350,00000400) ret=00404c19 0806ea10:trace:resource:LoadStringA instance = 400000, id = ffdf, buffer = 404d4350, length = 1024 0806ea10:trace:heap:HeapAlloc (40390000,00000002,00000800): returning 403fd838 0806ea10:trace:resource:LoadStringW instance = 400000, id = ffdf, buffer = 403fd838, length = 1024 0806ea10:trace:resource:RES_FindResource2 (00400000, 00000006, 00000ffe, 0000, W, PE) 0806ea10:trace:resource:RES_LoadResource (00400000, 00472ac0, PE) 0806ea10:trace:resource:LockResource (00476b48) 0806ea10:trace:resource:LoadStringW strlen = 63 0806ea10:trace:resource:LoadStringW L"Access violation at address %p in module '%s'. %s of address %p" loaded ! 0806ea10:trace:resource:LoadStringA "Access violation at address %p in module '%s'. %s of address %p" loaded ! 0806ea10:trace:heap:HeapFree (40390000,00000002,403fd838): returning TRUE 0806ea10:Ret user32.LoadStringA() retval=0000003f ret=00404c19 The program catches it and tries to inform the user that something wrong happened.> > > Then comes another exception, about 900 lines later: >My second one is about 2500 lines later: 0806ea10:Call ntdll.RtlLeaveCriticalSection(004665e8) ret=00419d5a 0806ea10:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=00419d5a 0806ea10:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 0806ea10: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=00462580,ecx=00413358,edx=41424394,esi=400fcd5d,edi=405e5bd4,ebp=405e5c54,eip=00462808,esp=405e5bec,eflags=00010246,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=0x462808,params={0,284}} ) 0806ea10: queue_exception_event() = 0 { handle=0 } 0806ea10:trace:seh:EXC_CallHandler calling handler at 0x462c68 code=c0000005 flags=0 0806ea10:trace:seh:EXC_CallHandler handler returned 1 0806ea10:trace:seh:EXC_CallHandler calling handler at 0x41f723 code=c0000005 flags=0 0806ea10:trace:seh:EXC_CallHandler handler returned 1 0806ea10:trace:seh:EXC_CallHandler calling handler at 0x41f734 code=c0000005 flags=0 0806ea10:Call user32.LoadStringA(00400000,0000ffd3,404d4358,00000400) ret=00404c19 0806ea10:trace:resource:LoadStringA instance = 400000, id = ffd3, buffer = 404d4358, length = 1024 0806ea10:trace:heap:HeapAlloc (40390000,00000002,00000800): returning 403f9898 0806ea10:trace:resource:LoadStringW instance = 400000, id = ffd3, buffer = 403f9898, length = 1024 0806ea10:trace:resource:RES_FindResource2 (00400000, 00000006, 00000ffe, 0000, W, PE) 0806ea10:trace:resource:RES_LoadResource (00400000, 00472ac0, PE) 0806ea10:trace:resource:LockResource (00476b48) 0806ea10:trace:resource:LoadStringW strlen = 4 0806ea10:trace:resource:LoadStringW L"Read" loaded ! 0806ea10:trace:resource:LoadStringA "Read" loaded ! 0806ea10:trace:heap:HeapFree (40390000,00000002,403f9898): returning TRUE 0806ea10:Ret user32.LoadStringA() retval=00000004 ret=00404c19 0806ea10:Call kernel32.VirtualQuery(00462808,404d48c0,0000001c) ret=0040a6e8 0806ea10:Ret kernel32.VirtualQuery() retval=0000001c ret=0040a6e8 0806ea10:Call kernel32.GetModuleFileNameA(00400000,404d47bb,00000105) ret=0040a70a 0806ea10:trace:string:lstrcpynA (0x404d47bb, "D:\\setup.exe", 261) 0806ea10:trace:module:GetModuleFileNameA D:\setup.exe 0806ea10:Ret kernel32.GetModuleFileNameA() retval=0000000c ret=0040a70a 0806ea10:Call user32.LoadStringA(00400000,0000ffdf,404d4350,00000400) ret=00404c19 0806ea10:trace:resource:LoadStringA instance = 400000, id = ffdf, buffer = 404d4350, length = 1024 0806ea10:trace:heap:HeapAlloc (40390000,00000002,00000800): returning 403f9898 0806ea10:trace:resource:LoadStringW instance = 400000, id = ffdf, buffer = 403f9898, length = 1024 0806ea10:trace:resource:RES_FindResource2 (00400000, 00000006, 00000ffe, 0000, W, PE) 0806ea10:trace:resource:RES_LoadResource (00400000, 00472ac0, PE) 0806ea10:trace:resource:LockResource (00476b48) 0806ea10:trace:resource:LoadStringW strlen = 63 0806ea10:trace:resource:LoadStringW L"Access violation at address %p in module '%s'. %s of address %p" loaded ! 0806ea10:trace:resource:LoadStringA "Access violation at address %p in module '%s'. %s of address %p" loaded ! 0806ea10:trace:heap:HeapFree (40390000,00000002,403f9898): returning TRUE 0806ea10:Ret user32.LoadStringA() retval=0000003f ret=00404c19 It looks very similar to the previous one...> Finally, about 2000 lines later, our friend the LoadOEMResource > exception occurs.Here too, but after the LoadOEMResource there comes many many many recursive exceptions until the hard segfault (out of stack ?)> > 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?So, in principle, the same opera but different actors :-) It seems to me that the app crashes when it tries to open its window, so it wants to report it but crashes again when it tries to open the popup and also catches it and tries to report it... Then it catches an exception in LoadOEMResource and it's so much out of order that it catches new exceptions just in the beginning of exception handling and this probably exhausts the stack up to the final hard segfault. With regards, Pavel