http://bugs.winehq.org/show_bug.cgi?id=58747
Bug ID: 58747 Summary: Directory opus fails start. Product: Wine Version: 10.15 Hardware: x86-64 URL: https://cdn2.gpsoft.com.au/files/Opus13/DOpusInstall-1 3.18.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: xerox.xerox2000x@gmail.com Distribution: Debian
It throws a messagebox "Unable to load gdi32"
This turns out to come from: 0024:Call KERNEL32.GetProcAddress(6fffff810000,141a2a166 "GetEnhMetaFilePixelFormat") ret=140196bb1 0024:Ret KERNEL32.GetProcAddress() retval=00000000 ret=140196bb1 0024:Call KERNEL32.GetLastError() ret=140196bbf 0024:Ret KERNEL32.GetLastError() retval=0000007f ret=140196bbf 0024:Call KERNEL32.RaiseException(c06d007f,00000000,00000001,7ffffe1ffa40) ret=140196be6 0024:Call ntdll.RtlUnwindEx(7ffffe1ffa70,14019617b,7ffffe1ff880,c06d007f,7ffffe1fec50,7ffffe1ff170) ret=1414284de 0024:Call user32.MessageBoxA(00000000,7ffffe1ffd00 "Unable to load "gdi32.dll"",1416483e8 "Directory Opus",00000000) ret=1401968d8
After adding GetEnhMetaFilePixelFormat to gdi32.spec, the story coninues with ordinal "716" from shell32, and GetThemeBitmap + GetThemeStream from uxtheme.
After that it still doesn't start in wine, but it does in Staging --> It also needs the "comctl32-version-6" patch.
I'll send a patch for the shell32 issue first.
http://bugs.winehq.org/show_bug.cgi?id=58747
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |uxtheme
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Here's some observation for the crash in current wine:
I filtered out the ordinals the program is looking for from a +relay log (like 061c:Call KERNEL32.GetProcAddress(6ffffdfd0000,0000002f) ret=140196bb1 where 6ffffdfd0000 = uxtheme)
I got ordinals: 47 49 61 74 104 115 132 133 135 136
Of these 49,74 and and 115 look strange as they are not present in current uxtheme.spec
If I put "49 stub some_function" in uxtheme.spec, the program (mysteriously) starts
If I put "74 stub some_function" in uxtheme.spec, no change in crash is observed (crashes same way)
If I put "115 stub some_function" in uxtheme.spec, I actually get a crash into "unimplemented call to some_function"...
As already mentioned on gitlab: just removing some (stub) ordinals from uxtheme.spec also makes the program start. I don't know what to make of it...
Crash log below does not reveal anything that springs out to me:
061c:Ret KERNEL32.lstrcmpiW() retval=ffffffff ret=6ffffdfdab50 061c:Call KERNEL32.lstrcmpiW(7ffffe1fe250 L"LISTVIEW",7ffffe287df0 L"Menu") ret=6ffffdfdab50 061c:Ret KERNEL32.lstrcmpiW() retval=ffffffff ret=6ffffdfdab50 061c:Call KERNEL32.lstrcmpiW(7ffffe1fe250 L"LISTVIEW",7ffffe283a40 L"ListView") ret=6ffffdfdab50 061c:Ret KERNEL32.lstrcmpiW() retval=00000000 ret=6ffffdfdab50 061c:Call user32.IsWindow(000900fc) ret=6ffffdfe2fb5 061c:Ret user32.IsWindow() retval=00000001 ret=6ffffdfe2fb5 061c:Call user32.SetPropW(000900fc,0000c018,7ffffe2839b0) ret=6ffffdfe30d6 061c:Ret user32.SetPropW() retval=00000001 ret=6ffffdfe30d6 061c:Ret uxtheme.OpenThemeData() retval=7ffffe2839b0 ret=1402fcae3 061c:Call ntdll.RtlAcquireSRWLockExclusive(141ac6f80) ret=1402d60b2 061c:Ret ntdll.RtlAcquireSRWLockExclusive() retval=00000002 ret=1402d60b2 061c:Call user32.GetDC(000900fc) ret=140dc4d0f 061c:Ret user32.GetDC() retval=12010061 ret=140dc4d0f 061c:Call gdi32.CreateCompatibleDC(12010061) ret=140dc4c5b 061c:Ret gdi32.CreateCompatibleDC() retval=3f410053 ret=140dc4c5b 061c:Call gdi32.CreateCompatibleBitmap(12010061,00000014,00000014) ret=140dc4c7e 061c:Ret gdi32.CreateCompatibleBitmap() retval=0a09011a ret=140dc4c7e 061c:Call gdi32.GetCurrentObject(3f410053,00000007) ret=140dc4bff 061c:Ret gdi32.GetCurrentObject() retval=01890034 ret=140dc4bff 061c:Call gdi32.SelectObject(3f410053,0a09011a) ret=140dc4caf 061c:Ret gdi32.SelectObject() retval=01890034 ret=140dc4caf 061c:Call user32.ReleaseDC(000900fc,12010061) ret=140dc4d39 061c:Ret user32.ReleaseDC() retval=00000001 ret=140dc4d39 061c:Call uxtheme.GetThemeBackgroundExtent(7ffffe2839b0,3f410053,00000000,00000000,7ffffe1feb50,7ffffe1feb40) ret=1402f91b6 061c:Call KERNEL32.lstrcmpiW(6ffffdff7ea4 L"IMAGEFILE",7ffffe1fe8d0 L"BorderFill") ret=6ffffdfdbe9c 061c:Ret KERNEL32.lstrcmpiW() retval=00000001 ret=6ffffdfdbe9c 061c:Call KERNEL32.lstrcmpiW(6ffffdff7ecc L"BORDERFILL",7ffffe1fe8d0 L"BorderFill") ret=6ffffdfdbe9c 061c:Ret KERNEL32.lstrcmpiW() retval=00000000 ret=6ffffdfdbe9c 061c:Ret uxtheme.GetThemeBackgroundExtent() retval=00000000 ret=1402f91b6 061c:Call user32.GetPropW(7ffffe2839b0,0000a910) ret=1402f77f9 061c:Ret user32.GetPropW() retval=00000000 ret=1402f77f9 061c:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00000001402FC983
http://bugs.winehq.org/show_bug.cgi?id=58747
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
--- Comment #2 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 79512 --> http://bugs.winehq.org/attachment.cgi?id=79512 Add a stub at ordinal 49.
On Wine, ordinal 49 happens to be DrawThemeBackground(). On Windows, the exported function at 49 is not DrawThemeBackground(). So if the application calls the function at ordinal 49, the stack might get corrupted. We can fill ordinal 49 with a stub in this case. Could you try the attached patch?
http://bugs.winehq.org/show_bug.cgi?id=58747
--- Comment #3 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Zhiyi Zhang from comment #2)
Created attachment 79512 [details] Add a stub at ordinal 49.
On Wine, ordinal 49 happens to be DrawThemeBackground(). On Windows, the exported function at 49 is not DrawThemeBackground(). So if the application calls the function at ordinal 49, the stack might get corrupted. We can fill ordinal 49 with a stub in this case. Could you try the attached patch?
Hi Zhyi,
Yes, the patch fixes the bug, and allows the program to start. I guess you'll send this fix upstream, so this bug can be closed,right?
http://bugs.winehq.org/show_bug.cgi?id=58747
--- Comment #4 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to Louis Lenders from comment #3)
(In reply to Zhiyi Zhang from comment #2)
Hi Zhyi,
Yes, the patch fixes the bug, and allows the program to start. I guess you'll send this fix upstream, so this bug can be closed,right?
Yes, I will send a patch. Thanks for the help.
http://bugs.winehq.org/show_bug.cgi?id=58747
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #5 from Zhiyi Zhang zzhang@codeweavers.com --- Fixed by f00052fb5dc807acb7e5cf5ca6b6d605a8bd449a
http://bugs.winehq.org/show_bug.cgi?id=58747
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f00052fb5dc807acb7e5cf5ca6b | |6d605a8bd449a