https://bugs.winehq.org/show_bug.cgi?id=56493
Bug ID: 56493 Summary: PresentationFontCache.exe crashes during .Net 3.51 SP1 installation Product: Wine Version: 9.5 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: msi Assignee: wine-bugs@winehq.org Reporter: dmitry@baikal.ru CC: hans@meelstraat.net Regression SHA1: 2c450fd6215c0da4685143f97ece8b6db0f54a0b Distribution: ---
Starting from commit 2c450fd6215c0da4685143f97ece8b6db0f54a0b installing .Net 3.51 SP1 with 'winetricks -q dotnet351sp1' leads to a crash in drive_c/windows/Microsoft.NET/Framework/v3.0/WPF/PresentationFontCache.exe
0448:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub 0448:fixme:advapi:ReportEventW (CAFE4242,0x0001,0x0000,0x000003e8,00000000,0x0008,0x00000100,3009B09C,014CDB08): stub 0448:err:eventlog:ReportEventW L"presentationfontcache.exe" 0448:err:eventlog:ReportEventW L"0.0.0.0" 0448:err:eventlog:ReportEventW L"488f1424" 0448:err:eventlog:ReportEventW L"kernelbase.dll" 0448:err:eventlog:ReportEventW L"0.0.0.0" 0448:err:eventlog:ReportEventW L"660521cd" 0448:err:eventlog:ReportEventW L"0" 0448:err:eventlog:ReportEventW L"00012162" 0448:fixme:advapi:DeregisterEventSource (CAFE4242) stub wine: Unhandled exception 0xe0434f4d in thread 43c at address 7BC72162 (thread 043c), starting debugger...
Note that window with the debugger prompt may not actually appear.
PresentationFontCache.exe is a demand starting service, and once installation has finished executing 'wine sc start FontCache3.0.0.0' doesn't lead to a crash. The crash happens after the check GetFileAttributesW("C:\windows\assembly\GAC_32\PresentationCore\3.0.0.0__31bf3856ad364e35\PresentationCore.dll") which returns 0xffffffff and GetLastError()=3. Before the offending commit PresentationCore.dll exists and the service doesn't crash.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #1 from Hans Leidekker hans@meelstraat.net --- I can't reproduce this with current Wine (old wow64 build) and current winetricks.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #1)
I can't reproduce this with current Wine (old wow64 build) and current winetricks.
With up to date wine.git and a wow64 (old style) build I get:
$ rm -rf ~/.wine $ WINEARCH=win32 wine winver $ WINEARCH=win32 winetricks -q dotnet35sp1 &>winehq_dotnet351.log $ grep -A 10 fontcache winehq_dotnet351.log 0458:err:eventlog:ReportEventW L"presentationfontcache.exe" 0458:err:eventlog:ReportEventW L"0.0.0.0" 0458:err:eventlog:ReportEventW L"488f1424" 0458:err:eventlog:ReportEventW L"kernelbase.dll" 0458:err:eventlog:ReportEventW L"0.0.0.0" 0458:err:eventlog:ReportEventW L"66067216" 0458:err:eventlog:ReportEventW L"0" 0458:err:eventlog:ReportEventW L"00012162" 0458:fixme:advapi:DeregisterEventSource (CAFE4242) stub wine: Unhandled exception 0xe0434f4d in thread 43c at address 7BC72162 (thread 043c), starting debugger... 045c:err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 00000000 in module L"kernelbase"
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #3 from Hans Leidekker hans@meelstraat.net --- I can reproduce it with a 32-bit prefix. I see that the failure is ignored and the installer returns success:
Info 2009.Failed to generate font cache data file - Couldn't start FontCache service., Error Code: 1053. Info 2021.Setup Log Information: Call to GenerateFontCacheData failed. Ignoring failure..
So the first question is whether this happens on 32-bit Windows.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #3)
I can reproduce it with a 32-bit prefix. I see that the failure is ignored and the installer returns success:
Info 2009.Failed to generate font cache data file - Couldn't start FontCache service., Error Code: 1053. Info 2021.Setup Log Information: Call to GenerateFontCacheData failed. Ignoring failure..
Before the commit service starts up and gracefully terminates. However after the commit service crashes because of missing dependency - PresentationCore.dll. Apparently missing dependency is a real regression.
So the first question is whether this happens on 32-bit Windows.
How are you suggesting to test this? Is this actually doable?
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #5 from Hans Leidekker hans@meelstraat.net --- (In reply to Dmitry Timoshkov from comment #4)
(In reply to Hans Leidekker from comment #3)
I can reproduce it with a 32-bit prefix. I see that the failure is ignored and the installer returns success:
Info 2009.Failed to generate font cache data file - Couldn't start FontCache service., Error Code: 1053. Info 2021.Setup Log Information: Call to GenerateFontCacheData failed. Ignoring failure..
Before the commit service starts up and gracefully terminates. However after the commit service crashes because of missing dependency - PresentationCore.dll. Apparently missing dependency is a real regression.
It's likely a regression but it's not certain because the installer ignores it and returns success anyway. And as you mentioned, starting the service afterwards works fine. I don't want to spend time chasing this if I don't have to ;-)
So the first question is whether this happens on 32-bit Windows.
How are you suggesting to test this? Is this actually doable?
There should be a log file somewhere.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #5)
It's likely a regression but it's not certain because the installer ignores it and returns success anyway. And as you mentioned, starting the service afterwards works fine. I don't want to spend time chasing this if I don't have to ;-)
The problem is that the crash sometimes leads to creation of the debugger prompt window that breaks an unattended install. Before the problematic commit there were no any debugger windows that needed a user response during the installation.
So the first question is whether this happens on 32-bit Windows.
How are you suggesting to test this? Is this actually doable?
There should be a log file somewhere.
I haven't found one.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #6)
(In reply to Hans Leidekker from comment #5)
It's likely a regression but it's not certain because the installer ignores it and returns success anyway. And as you mentioned, starting the service afterwards works fine. I don't want to spend time chasing this if I don't have to ;-)
The problem is that the crash sometimes leads to creation of the debugger prompt window that breaks an unattended install. Before the problematic commit there were no any debugger windows that needed a user response during the installation.
Also the regression may indicate that the installation process after that commit has changed, and now some components could be instaled in wrong order, that potentially may break other installers.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #8 from Hans Leidekker hans@meelstraat.net --- (In reply to Dmitry Timoshkov from comment #7)
(In reply to Dmitry Timoshkov from comment #6)
(In reply to Hans Leidekker from comment #5)
It's likely a regression but it's not certain because the installer ignores it and returns success anyway. And as you mentioned, starting the service afterwards works fine. I don't want to spend time chasing this if I don't have to ;-)
The problem is that the crash sometimes leads to creation of the debugger prompt window that breaks an unattended install. Before the problematic commit there were no any debugger windows that needed a user response during the installation.
Also the regression may indicate that the installation process after that commit has changed, and now some components could be instaled in wrong order, that potentially may break other installers.
Sure but the installer doesn't show this behavior in a 64-bit prefix. It could be a bug in the installer too. I hope you understand that I want to verify this.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #9 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #8)
It's likely a regression but it's not certain because the installer ignores it and returns success anyway. And as you mentioned, starting the service afterwards works fine. I don't want to spend time chasing this if I don't have to ;-)
The problem is that the crash sometimes leads to creation of the debugger prompt window that breaks an unattended install. Before the problematic commit there were no any debugger windows that needed a user response during the installation.
Also the regression may indicate that the installation process after that commit has changed, and now some components could be instaled in wrong order, that potentially may break other installers.
Sure but the installer doesn't show this behavior in a 64-bit prefix. It could be a bug in the installer too. I hope you understand that I want to verify this.
Your comments seem to imply that the state of the .Net 3.51 SP1 installer in a 32-bit prefix has been broken for years. I already pointed out that the source of the breakage is that PresentationCore.dll no longer gets installed at the time the installer calls StartService("FontCache3.0.0.0"), and that's very unlikely an intended (or unnoticed) behaviour of the installer. It's expected that the installer may behave differently in a 64-bit prefix since 64-bit OS may have different set of components installed, or the service could not be installed at all. It's completely up to you what you are planning to do with this, but it's clearly a regression, and it seems a pretty serious one because of the changed oder of components being installed.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #10 from Hans Leidekker hans@meelstraat.net --- A wine build before that commit also shows an exception in this custom action and failure return from the GenerateFontCacheData() call, which is ignored.
I don't get a debugger window but I don't get one after this commit either.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #10)
A wine build before that commit also shows an exception in this custom action and failure return from the GenerateFontCacheData() call, which is ignored.
I don't get a debugger window but I don't get one after this commit either.
As I mentioned already the debugger window appears not at every run, probably because the process terminates before the debugger is able to attach. Besides the unhandled exception leading to the debugger invocation starts to appear only after the identified commit, which in turn happens because of missing PresentationCore.dll. Probably it's better to investigate the missing dependency regression due to the MSI logic changes.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #12 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 76275 --> https://bugs.winehq.org/attachment.cgi?id=76275 Hack to turn on +relay only for PresentationFontCache.exe
Just in case it would be helpful I'm attaching the hack I was using to investigate the crash in PresentationFontCache.exe since running with +relay the whole .Net 3.51 SP1 installation process leads to unmanageable log sizes.
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #13 from Hans Leidekker hans@meelstraat.net --- I think I see the problem. The custom action is a deferred action that starts the FontCache3.0.0.0 service which depends on certain .NET assemblies. .NET assemblies can't be installed before native fusion.dll is installed (we accidentally depended on builtin being loaded instead, which no longer works after the PE conversion).
Installing assemblies was moved into InstallFinalize to fix that but these deferred custom actions (the commit variety at least) still need to be run after that because they may depend on it.
https://bugs.winehq.org/show_bug.cgi?id=56493
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com Status|NEW |RESOLVED Fixed by SHA1| |7f0ca9c284d15d03f14a8fefefa | |c834990d622cd Resolution|--- |FIXED
--- Comment #14 from Vijay Kamuju infyquest@gmail.com --- Fix merged - https://source.winehq.org/git/wine.git/commit/7f0ca9c284d15d03f14a8fefefac83...
https://bugs.winehq.org/show_bug.cgi?id=56493
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru --- Confirming that with todays's wine.git 'winetricks -q dotnet351sp1' installs without crashes. Thanks Hans.
https://bugs.winehq.org/show_bug.cgi?id=56493
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.7.
https://bugs.winehq.org/show_bug.cgi?id=56493
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |9.0.x
http://bugs.winehq.org/show_bug.cgi?id=56493
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|9.0.x |---
--- Comment #17 from Michael Stefaniuc mstefani@winehq.org --- Removing the 9.0.x milestone from bug fixes included in 9.0.1.
-
WineHQ Bugzilla