https://bugs.winehq.org/show_bug.cgi?id=46638
Bug ID: 46638 Summary: dotnet40 no longer installs using winetricks Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: brendan@redmandi.com CC: julliard@winehq.org Regression SHA1: 9839bb7691a1b1c57a4ca501d03825420c1609d7 Distribution: ---
Created attachment 63554 --> https://bugs.winehq.org/attachment.cgi?id=63554 Log of dotnet40 failing during install
When using the latest from git (currently 9781b5433cd4b708c0f537aa0b5608ff4157f04c), installing dotnet40 using 'winetricks dotnet40' fails. It was working in 4.1.
A git bisect highlighted commit 9839bb7691a1b1c57a4ca501d03825420c1609d7 as the first commit that introduced this failure.
Reverting just this commit allows dotnet40 to install again.
Attached are two logs: 1. for when dotnet40 installs successfully; and 2. for when it fails
Both logs use WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+module.
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #1 from Brendan McGrath brendan@redmandi.com --- Created attachment 63555 --> https://bugs.winehq.org/attachment.cgi?id=63555 Log of dotnet40 installing successfully
Log created after reverting just commit 9839bb7691a1b1c57a4ca501d03825420c1609d7
https://bugs.winehq.org/show_bug.cgi?id=46638
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=46638
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46638
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46638
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |msi CC| |z.figura12@gmail.com
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- That's an MSI issue, caused by the Wow64DisableWow64FsRedirection() call added in 540c48b91175b11c7b8646d0a036b20c46425080. This breaks the loading of sxs.dll triggered by ACTION_CostInitialize.
Either the redirection should be disabled only for certain actions, or the dlls would have to be loaded beforehand.
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #3 from Brendan McGrath brendan@redmandi.com --- Confirming that removing Wow64DisableWow64FsRedirection fixes this issue for me (but also appears to reintroduce bug 30713).
https://bugs.winehq.org/show_bug.cgi?id=46638
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alexandre Julliard from comment #2)
Either the redirection should be disabled only for certain actions, or the dlls would have to be loaded beforehand.
None of fusion/sxs/mscoree have load-time overhead (except that which is inherent from the loader), so I guess all other things being equal I'd favor loading them ahead of time (and perhaps just linking directly. Or do we not want to depend on them [mscoree in particular?] being present?)
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #5 from Hans Leidekker hans@meelstraat.net --- (In reply to Zebediah Figura from comment #4)
(In reply to Alexandre Julliard from comment #2)
Either the redirection should be disabled only for certain actions, or the dlls would have to be loaded beforehand.
None of fusion/sxs/mscoree have load-time overhead (except that which is inherent from the loader), so I guess all other things being equal I'd favor loading them ahead of time (and perhaps just linking directly. Or do we not want to depend on them [mscoree in particular?] being present?)
Linking mscoree directly would break native .net, which requires a native-only dll override.
Native fusion should be loaded through LoadLibraryShim. There's one version for each .net major release and it's part of the framework install (it's not in the system directory on windows). Builtin fusion might be good enough now though.
sxs could probably be linked directly.
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- Created attachment 63565 --> https://bugs.winehq.org/attachment.cgi?id=63565 patch
Here's a patch that moves cache initialization to ACTION_PerformAction, i.e. the first opportunity before ACTION_HandleStandardAction disables redirection.
It looks somewhat out of place here but we can't do it any earlier. Some installers drive the install sequence themselves via MsiDoAction.
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #7 from Brendan McGrath brendan@redmandi.com --- Confirming I could complete install of dotnet40 with this patch applied
https://bugs.winehq.org/show_bug.cgi?id=46638
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=46638
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #8 from Hans Leidekker hans@meelstraat.net --- (In reply to Hans Leidekker from comment #6)
Created attachment 63565 [details] patch
Here's a patch that moves cache initialization to ACTION_PerformAction, i.e. the first opportunity before ACTION_HandleStandardAction disables redirection.
I've submitted that patch as well as a patch to link sxs directly. Note that there's a name clash here; both sxs and fusion export CreateAssemblyCache, so we can only link one of these dlls directly.
https://bugs.winehq.org/show_bug.cgi?id=46638
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a70ece68b7fa98e55e62eaed100 | |6ceea961666ce Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #9 from Hans Leidekker hans@meelstraat.net --- Fixed by a70ece68b7fa98e55e62eaed1006ceea961666ce.
https://bugs.winehq.org/show_bug.cgi?id=46638
--- Comment #10 from Brendan McGrath brendan@redmandi.com --- Confirming this is fixed in 4.2
https://bugs.winehq.org/show_bug.cgi?id=46638
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.3.
-
wine-bugs＠winehq.org