https://bugs.winehq.org/show_bug.cgi?id=41727
Bug ID: 41727 Summary: rundll32.exe error after upgrading wine staging Product: Wine-staging Version: 1.9.23 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: ToddAndMargo@zoho.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Created attachment 56162 --> https://bugs.winehq.org/attachment.cgi?id=56162 run dll error
Dear Wine Staging,
wine --version (it is 32 bit) wine-1.9.23 (Staging)
Every time I upgrade Wine Staging, on first run, I get the following inconsequential error pop up:
rundll32.exe - .NET Framework Unable to find a version of the runtime to run this application
This started after using Wine Tricks to install .NET
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #1 from Todd Chester ToddAndMargo@zoho.com --- Dear Staging,
After upgrading to staging 2.3, I noticed that instead of getting this error, I got a prompt about missing Wine Mono. It gave me an option to install it, which I and it did.
Did you guy fix yet another one by chance?
-T
https://bugs.winehq.org/show_bug.cgi?id=41727
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|rundll32.exe error after |rundll32.exe error during |upgrading wine staging |wine prefix update when | |native .NET is installed Component|-unknown |-unknown Product|Wine-staging |Wine
--- Comment #2 from Sebastian Lackner sebastian@fds-team.de --- No, I don't think this issue was fixed. Wine and Wine Staging 2.3 ship a new version of Wine Mono, which is probably the reason why the installer is triggered again.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Sebastian Lackner from comment #2)
No, I don't think this issue was fixed. Wine and Wine Staging 2.3 ship a new version of Wine Mono, which is probably the reason why the installer is triggered again.
Actually, the last statement is wrong, the update was merged shortly after the release. You could try if the issue still exists by installing .NET in a fresh prefix and then running "wineboot -u" which is similar to what happens when installing a new version.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #4 from Todd Chester ToddAndMargo@zoho.com --- No trouble at all running "wineboot -u"
https://bugs.winehq.org/show_bug.cgi?id=41727
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Summary|rundll32.exe error during |rundll32.exe reports 'This |wine prefix update when |application could not be |native .NET is installed |started' during WINEPREFIX | |update with .NET Framework | |4.0 installed only | |(unmanaged processes | |trigger legacy CLR 2.0 | |activation policy) Resolution|--- |INVALID CC| |focht@gmx.net Keywords| |dotnet
--- Comment #5 from Anastasius Focht focht@gmx.net --- Hello folks,
the issue is by design if you have only .NET Framework 4.x installed in the WINEPREFIX. Every time a WINEPREFIX update is triggered (due to Wine upgrade), 'regsvr32 mscoree.dll' is run. Two times if you have a 64-bit prefix which is the default nowadays.
It's quite easy to reproduce even without WINEPREFIX update:
--- snip --- $ rm -rf ~/.wine
$ winetricks -q dotnet40
$ WINEDEBUG=+msgbox wine "c:\windows\system32\regsvr32.exe" "c:\windows\system32\mscoree.dll"
0024:trace:msgbox:MSGBOX_OnInit L"Unable to find a version of the runtime to run this application." regsvr32: Failed to register DLL 'c:\windows\system32\mscoree.dll'
$ WINEDEBUG=+msgbox wine "c:\windows\syswow64\regsvr32.exe" "c:\windows\syswow64\mscoree.dll"
0024:trace:msgbox:MSGBOX_OnInit L"Unable to find a version of the runtime to run this application." regsvr32: Failed to register DLL 'c:\windows\syswow64\mscoree.dll' --- snip ---
https://source.winehq.org/git/wine.git/blob/HEAD:/loader/wine.inf.in#l2554
--- snip --- 2554 [RegisterDllsSection] 2555 ;;some dlls have to be registered first ... 2564 11,,mscoree.dll,1 --- snip ---
64-bit part:
--- snip --- 002c:Call KERNEL32.CreateProcessW(0021e930 L"C:\windows\system32\rundll32.exe",00715e80 L"C:\windows\system32\rundll32.exe setupapi,InstallHinfSection DefaultInstall 128 \\?\Z:\home\focht\projects\wine\mainline-install-x86_64\bin\..\share\wine\wine.inf",00000000,00000000,100000000,00000000,00000000,00000000,0021e8c0,0021e8a8) ret=140006464 ... 002c:trace:process:CreateProcessInternalW started process pid 00a4 tid 00a8 ... 002c:Ret KERNEL32.CreateProcessW() retval=00000001 ret=140006464 ... 00a8:Call user32.MessageBoxW(00000000,0021a1b8 L"This application could not be started.\n\nDo you want to view information about this issue?",0021a818 L"rundll32.exe - This application could not be started.",00000014) ret=0277d73b --- snip ---
32-bit part:
--- snip --- ... 002c:Call KERNEL32.CreateProcessW(0021e930 L"C:\windows\syswow64\rundll32.exe",00ad8630 L"C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \\?\Z:\home\focht\projects\wine\mainline-install-x86_64\bin\..\share\wine\wine.inf",00000000,00000000,100000000,00000000,00000000,00000000,0021e8c0,0021e8a8) ret=140006464 ... 002c:trace:process:CreateProcessInternalW started process pid 0110 tid 0114 ... 002c:Ret KERNEL32.CreateProcessW() retval=00000001 ret=140006464 ... 0114:Call user32.MessageBoxW(00000000,0031b2e0 L"This application could not be started.\n\nDo you want to view information about this issue?",0031acb0 L"rundll32.exe - This application could not be started.",00000014) ret=0245fb3c --- snip ---
The error message is misleading at best. In this case it means that the CLR bootstrapper can't find the needed CLR version. 'regsvr32' is an unmanaged process that is not supposed to host a .NET runtime. .NET Framework 4.x 'mscoree' and it's shim dlls fall back to legacy v2 CLR hosting behaviour when they detect that the hosting process is unmanaged and the (calling) main PE not even a mixed-mode assembly.
It's kind of in between the lines in these articles:
* https://web.archive.org/web/20091206135954/http://msdn.microsoft.com/en-us/m... ("In-Process Side-by-Side")
* http://web.archive.org/web/20130128072944/http://www.marklio.com/marklio/Per... ("What is useLegacyV2RuntimeActivationPolicy for?")
* https://stackoverflow.com/questions/1604663/what-does-uselegacyv2runtimeacti... ("What does 'useLegacyV2RuntimeActivationPolicy' do in the .NET 4 config")
There are multiple ways to work around these annoying message boxes when the WINEPREFIX gets updated:
1) install .NET Framework 2.0 before .NET Framework 4.0 (via 'winetricks)
2) create app.config for Wine builtin 'regsvr32' when you have .NET Framework 4.0 or higher only installed:
--- snip --- ... 00a8:Call KERNEL32.CreateFileW(00bcd800 L"C:\windows\system32\rundll32.exe.config",80000000,00000001,00000000,00000003,00000080,00000000) ret=02747847 .... 00a8:Ret KERNEL32.CreateFileW() retval=ffffffffffffffff ret=02747847 ... --- snip ---
* 'C:\windows\system32\rundll32.exe.config' * 'C:\windows\syswow64\rundll32.exe.config'
Content:
--- snip --- <?xml version="1.0" encoding="utf-8" ?> <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" /> <supportedRuntime version="v2.0" /> </startup> </configuration> --- snip ---
3) Export specific environment variables or set registry keys:
https://github.com/kosmos-zhang/dotnet.coreclr/blob/master/Documentation/pro...
* OnlyUseLatestCLR (big hammer/red knob)
* COMPlus_NoGuiFromShim (not really solution as there is still internal error, just causes no UI dialogs to be displayed)
* ErrorDialog ((not really solution as there is internal error, causes no error dialogs to be displayed)
For the environment variable approach you need to add 'COMPLUS_' prefix to variables:
--- snip --- ... 00a8:Call KERNEL32.GetEnvironmentVariableW(0021bd70 L"COMPLUS_OnlyUseLatestCLR",00000000,00000000) ret=027469f9 00a8:trace:process:GetEnvironmentVariableW (L"COMPLUS_OnlyUseLatestCLR" 0000000000000000 0) ... 00a8:Ret KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=027469f9 --- snip ---
This works:
--- snip --- $ COMPlus_OnlyUseLatestCLR=1 wine "c:\windows\syswow64\regsvr32.exe" "c:\windows\syswow64\mscoree.dll"
regsvr32: Successfully registered DLL 'c:\windows\syswow64\mscoree.dll' --- snip ---
But that's not really feasible because you would need to persist this environment variable permanently in Wine environment to be visible during prefix update.
The better way is to add 'OnlyUseLatestCLR' registry key with DWORD value '1'
-- 00a8:Call advapi32.RegOpenKeyExW(ffffffff80000002,027a7a00 L"Software\Microsoft\.NETFramework",00000000,00020019,0021be58) ret=02747db4 ... 00a8:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=02747db4 00a8:Call advapi32.RegQueryValueExW(000000a4,027a8808 L"OnlyUseLatestCLR",00000000,0021bee0,0021bed0,0021bec8) ret=0274bfe4 ... 00a8:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=7b03bd38 00a8:Ret advapi32.RegQueryValueExW() retval=00000002 ret=0274bfe4 --- snip ---
--- snip --- $ wine reg add "HKLM\Software\Microsoft\.NETFramework" /v OnlyUseLatestCLR /t REG_DWORD /d 0001 /f
With that registry key in place the registration succeeds:
--- snip --- $ wine "c:\windows\system32\regsvr32.exe" "c:\windows\system32\mscoree.dll"
regsvr32: Successfully registered DLL 'c:\windows\system32\mscoree.dll'
$ wine "c:\windows\syswow64\regsvr32.exe" "c:\windows\syswow64\mscoree.dll"
regsvr32: Successfully registered DLL 'c:\windows\syswow64\mscoree.dll' --- snip ---
Summarizing: There is nothing to fix in Wine here, it behaves correctly.
To prevent these annoying message boxes which require user interaction to unblock the WINEPREFIX update we could change the 'dotnet40' recipe to add 'OnlyUseLatestCLR' setting by default.
$ wine --version wine-5.7-256-g1976685a0f
Regards
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
in my previous comment #5, 'OnlyUseLatestCLR' setting was mentioned with "big hammer/red knob" in the list of possible workarounds.
The potential danger/impact of this global setting is mentioned in this StackOverflow thread:
https://stackoverflow.com/questions/2094694/how-can-i-run-powershell-with-th... ("How can I run PowerShell with the .NET 4 runtime?")
--- quote --- Please be VERY careful with using the registry key approach. These are machine-wide keys and forcibily migrate ALL applications to .NET 4.0.
Many products do not work if forcibily migrated and this is a testing aid and not a production quality mechanism. Visual Studio 2008 and 2010, MSBuild, turbotax, and a host of websites, SharePoint and so on should not be automigrated. --- quote ---
Providing 'rundll32.exe.config' would be an optimal solution with minimal impact but Windows doesn't have this. Also by default Wine-Mono is installed/used which doesn't require this mechanism at all.
Regards
https://bugs.winehq.org/show_bug.cgi?id=41727
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #8 from Anastasius Focht focht@gmx.net --- Hello folks,
for documentation: The 'OnlyUseLatestCLR' registry tweak is added by default in recent 'winetricks' (master, v20201206, v20200910).
* https://github.com/Winetricks/winetricks/commit/1131bf0b2235628fdec050983a96... ("dotnet40: use OnlyUseLatestCLR registry setting instead of dotnet20 to avoid WINEPREFIX update popup")
* https://github.com/Winetricks/winetricks/commit/7368a55d7e434bf840210164f516... ("dotnet45: use OnlyUseLatestCLR registry setting to avoid WINEPREFIX update popup")
You don't see the message boxes anymore upon WINEPREFIX update if .NET Frameworks 4.x were installed by these winetricks versions.
Regards
https://bugs.winehq.org/show_bug.cgi?id=41727
Michael McGuire spoon0042@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spoon0042@hotmail.com
--- Comment #9 from Michael McGuire spoon0042@hotmail.com --- Is this actually fixed? I seem to get a different popup now, saying 'Unable to find a version of the runtime to run this application.'
Installed dotnet40 with 6.0, fresh wineprefix and updated winetricks, switching to for ex 6.0-rc4 staging and back gets the popup each time.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #10 from Michael McGuire spoon0042@hotmail.com --- Additionally installing dotnet20 makes it go away too. hm.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #11 from Michael McGuire spoon0042@hotmail.com --- er, I guess that is the same error as the original report anyway.
Additionally installing dotnet20 makes it go away too. hm.
https://bugs.winehq.org/show_bug.cgi?id=41727
--- Comment #12 from Michael McGuire spoon0042@hotmail.com --- Filed an issue over on the winetricks github: https://github.com/Winetricks/winetricks/issues/1695
https://bugs.winehq.org/show_bug.cgi?id=41727
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
-
wine-bugs＠winehq.org -
WineHQ Bugzilla