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.