https://bugs.winehq.org/show_bug.cgi?id=43270
Bug ID: 43270 Summary: Exact Audio Copy does not detect plugins Product: Wine Version: 2.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: redstone@gmail.com Distribution: ---
With a clean wine 2.11 (inited with "WINEARCH=win32 wine wineboot"), on Ubuntu 17.04 Zesty:
After installing Exact Audio Copy 1.3 (http://www.exactaudiocopy.de/en/index.php/resources/download/), EAC does not detect the plugins that it comes bundled with. Specifically, it does not detect CUE Tools DB Plugin, or the AcoustID Plugin.
It looks like this problem existed on older versions of wine/EAC, see comments in https://appdb.winehq.org/objectManager.php?sClass=version&iId=24705.
To reproduce: 1. Install EAC 1.3 2. Start EAC 3. Go to menu -> EAC -> EAC Options -> Audio Plugins
The list there is empty. It should have CUETools and AcoustID listed (which is what I see when I install EAC 1.3 on my Windows 7 machine)
I tried getting some debug info: WINEDEBUG=+relay wine ~/.wine/drive_c/Program\ Files/Exact\ Audio\ Copy/EAC.exe > /tmp/foo 2>&1 but it didn't have anything helpful. Specifically, the DLLs for the plugins don't appear (e.g., CUETools*.dll), nor does PluginHandler.dll appear, so it's like it's not even trying to access them.
Any suggestions on how to debug?
https://bugs.winehq.org/show_bug.cgi?id=43270
Freso bugs.winehq.org@freso.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.winehq.org@freso.dk
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #1 from JRed redstone@gmail.com --- Created attachment 58612 --> https://bugs.winehq.org/attachment.cgi?id=58612 Screenshot of EAC without the plugins recognized
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #2 from JRed redstone@gmail.com --- Created attachment 58624 --> https://bugs.winehq.org/attachment.cgi?id=58624 WINEDEBUG=+all, lightly filtered
WINEDEBUG=+all of EAC.exe starting up, then run through egrep -v 'RtlAllocateHeap|RtlFreeHeap|RtlReAllocateHeap' to get 'xz -9' compressed file below 5MB limit
https://bugs.winehq.org/show_bug.cgi?id=43270
Daniel Kamil Kozar dkk089@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dkk089@gmail.com
--- Comment #3 from Daniel Kamil Kozar dkk089@gmail.com --- The application calls CoCreateInstance() in an early startup stage (i.e. the StartupHelper export from HelperFunctions.dll) in order to initialize an instance of the class defined by PluginHandler.dll. Said DLL has an embedded manifest which declares a CLSID of {c55d92b1-4fdf-4b54-b817-98ab9569f4f4}.
This CoCreateInstance() call fails, leading to function pointers to the plugin functions being set to zero and the plugin functionality being later unavailable in the application.
Tested with wine-3.0, the said call fails with a vanilla Wine installation with CLASS_E_CLASSNOTAVAILABLE and with REGDB_E_CLASSNOTREG after installing dotnet20 from winetricks.
Attached logs from both (with and without winetricks) versions.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #4 from Daniel Kamil Kozar dkk089@gmail.com --- Created attachment 60360 --> https://bugs.winehq.org/attachment.cgi?id=60360 CoCreateInstance() failure without dotnet20
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #5 from Daniel Kamil Kozar dkk089@gmail.com --- Created attachment 60361 --> https://bugs.winehq.org/attachment.cgi?id=60361 CoCreateInstance() failure with dotnet20
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #6 from Daniel Kamil Kozar dkk089@gmail.com --- I looked into this some more, and it appears that the data from the manifest is entirely ignored at the time of the CoCreateInstance() call, leading the function to lookup data inside the registry instead of data which should be available at runtime. Calling CoCreateInstance() with the given CLSID leads to create_monodata() being called, and failing due to the CLSID not being present in the registry.
Here's some additional debugging I've tried : 1. Adding the <File> directive to the manifest embedded inside PluginHandler.dll, since according to https://docs.microsoft.com/en-us/dotnet/framework/interop/configure-net-fram... even embedded manifests should contain a <File> directive. I hoped this might help, seeing how actctx.c calls add_dll_redirect() only when a <File> directive appears inside a manifest file. However, that did not help, and CoCreateInstance() ended up looking for the CLSID inside the registry anyway.
2. Manually creating the registry keys and values that create_monodata() looks for, i.e.
[HKEY_CLASSES_ROOT\CLSID{C55D92B1-4FDF-4B54-B817-98AB9569F4F4}\InprocServer32] "Class"="MetadataPlugIn.PluginHandler" "CodeBase"="C:\Program Files\Exact Audio Copy\PluginHandler.dll"
However, this only led to the following error :
Unhandled Exception: System.Runtime.InteropServices.MarshalDirectiveException: The type `System.Array' layout needs to be Sequential or Explicit
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #7 from Daniel Kamil Kozar dkk089@gmail.com --- Created attachment 61841 --> https://bugs.winehq.org/attachment.cgi?id=61841 Full log of the scenario leading to an unhandled exception +mscoree +actctx
https://bugs.winehq.org/show_bug.cgi?id=43270
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.exactaudiocopy.d | |e/en/index.php/resources/do | |wnload/ Status|UNCONFIRMED |NEW Keywords| |download Ever confirmed|0 |1 CC| |dark.shadow4@web.de
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Confirming and filling in a few fields.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61854 --> https://bugs.winehq.org/attachment.cgi?id=61854 Testcase (source + binaries)
I created a testcase for what I think is what happens here. It does work on windows, but not on wine. Although the error message is different from the one I get when running EAC - do you know what EAC is doing different here?
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #10 from Daniel Kamil Kozar dkk089@gmail.com --- Unfortunately, I have no idea. Interestingly, your example also fails to work with dotnet20 installed... I'll try contacting the author, but he's been under the radar for the past few years now, so I wouldn't get my hopes up too much.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- Well, EAC doesn't work with dotnet20 either, or does it for you?
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #12 from Daniel Kamil Kozar dkk089@gmail.com --- Nope, it doesn't. Thanks for the testcase.
https://bugs.winehq.org/show_bug.cgi?id=43270
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |sxs Keywords| |dotnet
--- Comment #13 from Fabian Maurer dark.shadow4@web.de --- After a few more hours, I think I'm getting to the gist of it.
There are multiple issues here:
1) wine-mono isn't used to handling registration free components, so it fails Workaround: use "winetricks -q dotnet20"
2) My test case doesn't work because it can't find the manifest - because it has a different resource ID because it's "isolation aware" (whatever that means) Workaround: Attached hack for my testcase
3) Then CoCreateInstance calls into mscoree.DllGetClassObject (see updated testcase I attached) and you can get a IClassFactory to create the object. However, behind the scenes mscoree calls sxs, and that doesn't know how to do lookup of the registration free classes either. Workaround: Use native sxs
4) Native sxs crashes due to missing ntdll functions Workaround: Use my hacks to add functions into ntdll
With this knowledge and these hacks, one can get the testcase and even EAC to run. Just note that the hack for MY testcase breaks EAC, and without the hack EAC works but my testcase does not.
I guess we should make this about the sxs issue, so native .NET works.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #14 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61858 --> https://bugs.winehq.org/attachment.cgi?id=61858 Screenshot as Proof of Concept
Attaching screenshot to show Plugins are actually found.
However, since I have no idea how that program works, I can't confirm if that actually makes it work properly.
If you have a native windows to get native sxs.dll, and the knowledge to apply patches and compile from source, could you test?
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #15 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61859 --> https://bugs.winehq.org/attachment.cgi?id=61859 Updated testcase + Hack patches to work around the issue
Attaching the patches didn't work, trying again.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #16 from Daniel Kamil Kozar dkk089@gmail.com --- I can confirm that installing dotnet20, replacing sxs.dll and adding the missing functions to NTDLL does result in EAC plugins working properly. I was able to obtain metadata from Discogs and I got a log with CUETools information - both functionalities are available only via using plugins, and using them isn't possible in the current version of Wine.
Tested with the patch applied on top of the current git master, sxs.dll version is 6.1.7601.17514.
Thank you very much for your help on this. Let me know if there's anything more I can do.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #17 from Daniel Kamil Kozar dkk089@gmail.com --- Created attachment 61896 --> https://bugs.winehq.org/attachment.cgi?id=61896 Preliminary implementation of SxsLookupClrGuid
This is the patch that I was able to cook up. It makes EAC plugins work without having to use native sxs.dll. There is a number of things that irk me code-wise, but I don't have enough knowledge to decide how they should be done in the target implementation. Namely : 1. I just copied the definitions of the structs available under ACTCTX_SECTION_KEYED_DATA.lpData returned by FindActCtxSectionGuid. This makes it possible to then access the real data that SxsLookupClrGuid needs. 2. It seems to me that the SXS_LOOKUP_CLR_GUID_USE_ACTCTX flag of this function cannot be supported without extra work in actctx.c (and perhaps having an internal interface between these two files?), since FindActCtxSectionGuid calls find_guid() internally, which has no way of passing the activation context to use during the lookup.
Let me know what you think, also if the patch is no good.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #18 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Daniel Kamil Kozar from comment #17)
Created attachment 61896 [details] Preliminary implementation of SxsLookupClrGuid
This is the patch that I was able to cook up. It makes EAC plugins work without having to use native sxs.dll. There is a number of things that irk me code-wise, but I don't have enough knowledge to decide how they should be done in the target implementation. Namely :
- I just copied the definitions of the structs available under
ACTCTX_SECTION_KEYED_DATA.lpData returned by FindActCtxSectionGuid. This makes it possible to then access the real data that SxsLookupClrGuid needs. 2. It seems to me that the SXS_LOOKUP_CLR_GUID_USE_ACTCTX flag of this function cannot be supported without extra work in actctx.c (and perhaps having an internal interface between these two files?), since FindActCtxSectionGuid calls find_guid() internally, which has no way of passing the activation context to use during the lookup.
Let me know what you think, also if the patch is no good.
This needs a lot of cleanup, and some tests too.
Issues so far:
- no need for a new source file, use sxs.c; - no reason to use ntdll heap API as far as I can tell; - most of the helpers are unnecessary I think; - SXS_LOOKUP_CLR_GUID_USE_ACTCTX is easy to handle - you simply have to temporary activate given context to be able to access it; - there's no tests.
Please note that patches are not picked up from here, and for a proper review wine-devel@winehq.org list should be used.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #19 from Fabian Maurer dark.shadow4@web.de --- Created attachment 61903 --> https://bugs.winehq.org/attachment.cgi?id=61903 0001-Implement-SxsLookupClrGuid
Since I also worked on the same issue, here's my approach. Also missing tests, I'd work on them, but I'm not sure if you're currently doing that.
How do we go from here?
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #20 from Daniel Kamil Kozar dkk089@gmail.com --- If you're working on this as well, I don't think there's a point in me doing the same work, seeing how you can do it better and faster.
Thanks.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #21 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Fabian Maurer from comment #19)
Created attachment 61903 [details] 0001-Implement-SxsLookupClrGuid
Since I also worked on the same issue, here's my approach. Also missing tests, I'd work on them, but I'm not sure if you're currently doing that.
How do we go from here?
Same way we usually do - by sending it to wine-devel?
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #22 from Fabian Maurer dark.shadow4@web.de --- (In reply to Daniel Kamil Kozar from comment #20)
If you're working on this as well, I don't think there's a point in me doing the same work
Okay, then I'll write some testcases and when I'm done submit the changes to the mailing list.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #23 from Fabian Maurer dark.shadow4@web.de --- Just sent in a few tests for this behavior: https://source.winehq.org/patches/data/149008
I'll add another test for the affected function itself too, and then send an actual fix that will mark the tests as passing.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #24 from Fabian Maurer dark.shadow4@web.de --- New patchset is in queue: https://source.winehq.org/patches/data/149306 https://source.winehq.org/patches/data/149305 https://source.winehq.org/patches/data/149308 https://source.winehq.org/patches/data/149311 https://source.winehq.org/patches/data/149307 https://source.winehq.org/patches/data/149312
Also made wine-mono able to load registration free COM objects. However, this program doesn't work properly in mono, so native .NET is still needed.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #25 from Daniel Kamil Kozar dkk089@gmail.com --- The patch hasn't unfortunately made it to mainline Wine, however here's the last iteration of it in case anybody wants to include it in their own build :
https://source.winehq.org/patches/data/150654
It applies cleanly to the current development version, which at the time of writing is 4.0-rc5, and fixes the issue described here.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #26 from Fabian Maurer dark.shadow4@web.de --- Yes, we're currently in Code-Freeze. I'll resubmit once it's over.
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #27 from Fabian Maurer dark.shadow4@web.de --- First patch is accepted, sent in the patch that finally fixes this issue here: https://source.winehq.org/patches/data/158007
https://bugs.winehq.org/show_bug.cgi?id=43270
Mads mads@ab3.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mads@ab3.no
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #28 from Daniel Kamil Kozar dkk089@gmail.com --- The patch seems to have slipped through the queue once again. Could you resubmit?
https://bugs.winehq.org/show_bug.cgi?id=43270
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #29 from Fabian Maurer dark.shadow4@web.de --- Resent the patch: https://source.winehq.org/patches/data/161980
Still don't know why some patches are seemingly ignored though.
https://bugs.winehq.org/show_bug.cgi?id=43270
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |4c7ffaecaf50cee91e74d509f64 | |f4aecca6e237c
--- Comment #30 from Fabian Maurer dark.shadow4@web.de --- Finally fixed by https://source.winehq.org/git/wine.git/commitdiff/4c7ffaecaf50cee91e74d509f6.... Thanks for being patient. :)
https://bugs.winehq.org/show_bug.cgi?id=43270
--- Comment #31 from Daniel Kamil Kozar dkk089@gmail.com --- Thank *you* for solving it in the first place! I'm waiting for the next release so I can finally give EAC a Gold status. :)
https://bugs.winehq.org/show_bug.cgi?id=43270
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #32 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.6.
https://bugs.winehq.org/show_bug.cgi?id=43270
Stefan de Konink stefan@konink.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@konink.de
--- Comment #33 from Stefan de Konink stefan@konink.de --- I have yesterday opened bug https://bugs.winehq.org/show_bug.cgi?id=47830
The state of play with Wine 4.17 is that. "Unhandled Exception: System.Runtime.InteropServices.MarshalDirectiveException: The type `System.Array' layout needs to be Sequential or Explicit" Still happens.
After installing dotnet20 plugins show up. But networking for CUETools does not work.