LoadOEMResource crash [Was: Re: Problem report: SHRINKER.ERR, fix to DEVICE_Open/CreateFileA? ]

Pavel Troller patrol at sinus.cz
Sat Dec 8 16:40:49 CST 2001 

> 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

More information about the wine-users mailing list