Frequent and annoying Wine bug
Robbert Xerox
xerox_xerox2000 at yahoo.co.uk
Mon Aug 15 03:11:41 CDT 2005
Hi, late response, been on holiday :). The patch from
francios gougetdoesn't fix the error. I dug a little
deeper into this:I had a knoppix live cd lying around
and there bug is not present. A program like Neatimage
(www.neatimage.com) startsup just fine there. I also
did some tracing to see where the difference is. I'm
quite noobish in this so correct me plz if i'm wrong:
On knoppix running neatimage fine i see this:
0009:Ret user32.LoadStringA() retval=0000001b
ret=00527b86
0009:Call
kernel32.RaiseException(0eedfade,00000001,00000007,4067f930)
ret=004aefac
0009:Call ntdll.RtlRaiseException(4067f7d8)
ret=404a5393 fs=1007
eax=4067f7d8 ebx=40569244 ecx=00000000 edx=00000018
esi=4067f94c edi=4067f808
ebp=4067f834 esp=4067f7d8 ds=002b es=002b gs=0000
flags=00200216
trace:seh:EXC_RtlRaiseException code=eedfade flags=1
addr=0x404a5300
trace:seh:EXC_RtlRaiseException info[0]=004aefac
trace:seh:EXC_RtlRaiseException info[1]=411d3068
trace:seh:EXC_RtlRaiseException info[2]=411d2fb0
trace:seh:EXC_RtlRaiseException info[3]=411d3058
trace:seh:EXC_RtlRaiseException info[4]=4067f974
trace:seh:EXC_RtlRaiseException info[5]=4067f964
trace:seh:EXC_RtlRaiseException info[6]=4067f94c
trace:seh:EXC_RtlRaiseException eax=4067f7d8
ebx=40569244 ecx=00000000 edx=00000018 esi=4067f94c
edi=4067f808
trace:seh:EXC_RtlRaiseException ebp=4067f834
esp=4067f7d8 cs=0023 ds=002b es=002b fs=1007 gs=0000
flags=00200216
trace:seh:EXC_CallHandler calling handler at 0x538243
code=eedfade flags=1
0009:Call
ntdll.RtlUnwind(4067f990,0053916b,4067f7d8,00000000)
ret=0053916b fs=1007
eax=4067f990 ebx=4067f7d8 ecx=00549d68 edx=4067f7d8
esi=0000001c edi=4067f7d8
ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs=0000
flags=00200206
trace:seh:EXC_RtlUnwind code=eedfade flags=3
trace:seh:EXC_CallHandler calling handler at 0x538243
code=eedfade flags=3
trace:seh:EXC_CallHandler handler returned 1
trace:seh:EXC_CallHandler calling handler at
0x401ae2c0 code=eedfade flags=3
trace:seh:EXC_CallHandler handler returned 1
0009:Ret ntdll.RtlUnwind() retval=00000000
ret=0053916b fs=1007
eax=00000000 ebx=4067f7d8 ecx=00549d68 edx=4067f7d8
esi=0000001c edi=4067f7d8
ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs=0000
flags=00200206
0009:Call advapi32.RegSetValueExA(0000005c,411d3058
"StartCount",00000000,00000004,4067f97c,00000004)
ret=004aef22
Looks to me as if an exception is thrown, wine is
handling the exception and the program continues fine
On my fc3 computer i see this:
000b:Ret user32.LoadStringA() retval=0000001b
ret=00527b86
000b:Call
kernel32.RaiseException(0eedfade,00000001,00000007,7fa9f93c)
ret=004aefac
000b:Call ntdll.RtlRaiseException(7fa9f824)
ret=7fcfe544 fs=003b
eax=7fcec305 ebx=7fd5bacc ecx=00000000 edx=0eedfade
esi=7fa9f958 edi=7fa9f854
ebp=7fa9f880 esp=7fa9f824 ds=007b es=007b gs=0033
flags=00200212
trace:seh:__regs_RtlRaiseException code=eedfade
flags=1 addr=0x7fcfe4e0
trace:seh:__regs_RtlRaiseException info[0]=004aefac
trace:seh:__regs_RtlRaiseException info[1]=7e4c32f4
trace:seh:__regs_RtlRaiseException info[2]=7e4c323c
trace:seh:__regs_RtlRaiseException info[3]=7e4c32e4
trace:seh:__regs_RtlRaiseException info[4]=7fa9f980
trace:seh:__regs_RtlRaiseException info[5]=7fa9f970
trace:seh:__regs_RtlRaiseException info[6]=7fa9f958
trace:seh:__regs_RtlRaiseException eax=7fcec305
ebx=7fd5bacc ecx=00000000 edx=0eedfade esi=7fa9f958
edi=7fa9f854
trace:seh:__regs_RtlRaiseException ebp=7fa9f880
esp=7fa9f824 cs=0073 ds=007b es=007b fs=003b gs=0033
flags=00200212
trace:seh:EXC_CallHandler calling handler at 0x538243
code=eedfade flags=1
000b:Call
kernel32.GetModuleFileNameA(00000000,7fa9f0c8,00000080)
ret=00541424
000b:Call
ntdll.RtlAllocateHeap(7fdb0000,00000000,00000100)
ret=7fd06d22
000b:Ret ntdll.RtlAllocateHeap() retval=7fdef278
ret=7fd06d22
000b:Call
ntdll.LdrLockLoaderLock(00000000,00000000,7fa9efdc)
ret=7fd1638f
000b:Ret ntdll.LdrLockLoaderLock() retval=00000000
ret=7fd1638f
000b:Call
ntdll.LdrFindEntryForAddress(00400000,7fa9efd8)
ret=7fd163a1
000b:Ret ntdll.LdrFindEntryForAddress()
retval=00000000 ret=7fd163a1
000b:Call ntdll.LdrUnlockLoaderLock(00000000,0000000b)
ret=7fd163e5
000b:Ret ntdll.LdrUnlockLoaderLock() retval=00000000
ret=7fd163e5
000b:Call
ntdll.RtlUnicodeToMultiByteN(7fa9f0c8,00000080,7fa9efdc,7fdef278,00000052)
ret=7fcff857
000b:Ret ntdll.RtlUnicodeToMultiByteN()
retval=00000000 ret=7fcff857
000b:Call
ntdll.RtlFreeHeap(7fdb0000,00000000,7fdef278)
ret=7fd06d4a
000b:Ret ntdll.RtlFreeHeap() retval=00000001
ret=7fd06d4a
000b:Ret kernel32.GetModuleFileNameA()
retval=00000029 ret=00541424
000b:Call kernel32.GetVersion() ret=005413a7
000b:Call ntdll.RtlGetVersion(7fa9eef8) ret=7fd3d280
000b:Ret ntdll.RtlGetVersion() retval=00000000
ret=7fd3d280
000b:Ret kernel32.GetVersion() retval=c0000a04
ret=005413a7
000b:Call kernel32.GetCurrentThreadId() ret=005413c6
000b:Ret kernel32.GetCurrentThreadId()
retval=0000000b ret=005413c6
000b:Call
user32.EnumThreadWindows(0000000b,00541388,7fa9f0b8)
ret=005413cc
000b:Call kernel32.94(7f8909a0) ret=7f84adbc
000b:Ret kernel32.94() retval=0000000b ret=7f84adbc
000b:Call
ntdll.RtlAllocateHeap(7fdb0000,00000000,00000080)
ret=7f84b762
000b:Ret ntdll.RtlAllocateHeap() retval=7fdef278
ret=7f84b762
000b:Call
ntdll.RtlFreeHeap(7fdb0000,00000000,7fdef278)
ret=7f8502e6
000b:Ret ntdll.RtlFreeHeap() retval=00000001
ret=7f8502e6
000b:Ret user32.EnumThreadWindows() retval=00000001
ret=005413cc
000b:Call user32.MessageBoxA(00000000,0057ff94
"Assertion failed: !\"bogus context in
_ExceptionHandler()\", file xx.cpp, line
3072",7fa9f0e4 "NeatImage.exe",00012010) ret=0054146f
Looks to me as if an exception is thrown, now the
program itself tries to handle the exception, and the
program exits with a window abnormal termination.
My question really is why the exception is handled in
two different ways, what could be the cause of this?
If this helps: one guy on the buglist got this error
after upgrading from Fedora Core 1 with vanilla kernel
2.6.10 (which worked
fine) to Fedora Core 3 with kernel 2.6.10-1.766_FC3
--- Francois Gouget <fgouget at codeweavers.com> wrote:
> Hi,
>
> Robbert Xerox wrote:
> > Hi , i know this is not a wine-bug channel, but
> this
> > bug is affecting quite some apps, and seems to
> affect
> > more and more ...
> > At least five apps from wine-bug mailinglist throw
> up
> > an exception which either reads: "Assertion Failed
> > !bogus context in Local_Unwind()" or "in
> > Exception_Handler".
>
> I have seen a bug pretty much like this in an
> application and here's
> what Mike Hearn had to say about it:
>
> > There were actually two bugs here:
> >
> > * Despite what the unit tests indicate,
> IShellFolder::BindToObject
> > with a NULL pidl can sometimes work. I guess it
> depends on the exact
> > class implementation. In this case I fixed it
> with an application
> > specific hack, we just return the desktop folder
> (it should probably
> > return an addreffed This).
> >
> > * The app apparently relies on an old Win98
> specific bug where
> > SFGAO_FILESYSTEM is set on My Computer. This bug
> is documented here:
> >
> >
>
http://msdn.microsoft.com/msdnmag/issues/05/06/CAtWork/default.aspx
> >
> > at the bottom. But it's not present in Windows
> NT, as our unit tests
> > actually prove (we should pay more attention to
> 98/NT differences!!):
> >
> >
>
http://test.winehq.com/data/200506231000/98_PaulVriensW98SEFull/shell32:shlfolder.txt
> >
> > It can be fixed with the patch to wine.inf, if
> you then do "make
> > install" in the tools directory and re-run
> wineprefixcreate.
>
> I've attached the patch so you can try it. That's
> not code I can comment
> on but maybe Mike will when he's back from his
> not-quite-vacations.
>
> --
> Francois Gouget
> fgouget at codeweavers.com
>
> > Index: dlls/shell32/shlfolder.c
>
===================================================================
> RCS file: /var/cvs/wine/dlls/shell32/shlfolder.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 shlfolder.c
> --- dlls/shell32/shlfolder.c 20 Jul 2005 10:29:05
> -0000 1.104
> +++ dlls/shell32/shlfolder.c 28 Jul 2005 21:33:11
> -0000
> @@ -272,6 +272,15 @@ HRESULT SHELL32_BindToChild
> (LPCITEMIDLI
> HRESULT hr;
> LPITEMIDLIST pidlChild;
>
> + TRACE("pidlRoot=%p, pathRoot=%s,
> pidlComplete=%p, riid=%s, ppvOut=%p\n",
> + pidlRoot, pathRoot, pidlComplete,
> debugstr_guid(riid), ppvOut);
> +
> + if (!pidlComplete)
> + {
> + SHELL32_CoCreateInitSF(_ILCreateDesktop(),
> pathRoot, NULL, &CLSID_ShellDesktop, riid, ppvOut);
> + return S_OK;
> + }
> +
> if (!pidlRoot || !ppvOut || !pidlComplete ||
> !pidlComplete->mkid.cb)
> return E_INVALIDARG;
>
> Index: tools/wine.inf
>
===================================================================
> RCS file: /var/cvs/wine/tools/wine.inf,v
> retrieving revision 1.37
> diff -u -p -r1.37 wine.inf
> --- tools/wine.inf 27 Jul 2005 15:42:40 -0000 1.37
> +++ tools/wine.inf 28 Jul 2005 21:30:35 -0000
> @@ -100,6 +100,8 @@
> HKCR,TypeLib\{00020430-0000-0000-C000-00
>
>
HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0,,,"OLE
> Automation"
>
>
HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0\0\win32,,,"stdole2.tlb"
>
>
HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0\FLAGS,,,"0"
> +; FIXME: this is to emulate a Windows 98 bug which
> is gone in NT: very few apps need it
>
+HKCR,CLSID\{20d04fe0-3aea-1069-a2d8-08002b30309d}\ShellFolder,"Attributes",0x10001,f0000154
>
> [ControlClass]
>
>
HKLM,System\CurrentControlSet\Control\Class\{4d36e978-e325-11ce-bfc1-08002be10318},,,"Ports
> (COM & LPT)"
>
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
More information about the wine-devel
mailing list