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". As a reference a filed 2 bugs, and commented another one where you can read the +relay,+seh logs: Bug 3097 Bug 3127 Bug 3139
Some googling around makes me believe that this is a Borland specific error. I tried to install Demo Borland compiler in wine to see if i could reproduce this error, but unfortunately it fails with exactly the same error.
all programs show the same pattern before an exception is thrown: they call LoadstringA() ,with something like L"Failed to get data for '%s'" or L"Access violation at address %p in module '%s'. %s of address %p" See the bugs for more info.
I think this bug is really affecting quite some more apps then the ones mentioned in wine-bugs so would be great if anyone could shine a light on this, as of how to solve the bug. Regards
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Robbert Xerox xerox_xerox2000@yahoo.co.uk writes:
I think this bug is really affecting quite some more apps then the ones mentioned in wine-bugs so would be great if anyone could shine a light on this, as of how to solve the bug. Regards
I tried several of the apps you mention and they all work fine here, so I suspect some sort of glibc/kernel issue. You should provide more details on your setup, and ask other people who see the problem to provide details too so that we can see if there's a correlation with kernel versions etc.
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:shlf...
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.
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@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:shlf...
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@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