[Bug 12079] New: VS.NET 7.x/. NET SDK installers fail if re-executed due to ACTION_StopServices being a stub
http://bugs.winehq.org/show_bug.cgi?id=12079
Summary: VS.NET 7.x/.NET SDK installers fail if re-executed due to ACTION_StopServices being a stub Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net
Hello,
.NET Framework SDK, VS.NET 7.x. etc. install "helper" service(s) which get automagically started. The installers die if executed again (update/change config) because the running service blocks file update.
--- snip --- .. err:msi:ACTION_InstallFiles Failed to copy L"Z:\mnt\iso\Program Files\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll" to L"c:\Program Files\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll" (32) err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 .. --- snip ---
James, if you find the time, please add "stop services" msi action implementation (dlls/msi/action.c:ACTION_StopServices). Although I have a patch, I constantly forget to apply it when tracking down installer problems. You could actually help to reduce my patch orgy :) Thanks.
Regards
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #1 from James Hawkins truiken@gmail.com 2008-03-18 18:18:45 --- Does this happen with the .NET installer (dotnetfx.exe)? If so, can you please provide steps to reproduce the problem.
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-03-19 15:54:55 --- Hello,
--- quote --- Does this happen with the .NET installer (dotnetfx.exe)? If so, can you please provide steps to reproduce the problem. --- quote ---
The .NET 1.1 redistributable package alone doesn't install the local/remote DevStudio Debugging Service. Actually it's a combination of several bugs which lead to this problem.
The installer failure itself can only be simulated with full VS.NET 7.x installer.
I will outline some steps to show at least the "locking" problem - without VS.NET 7.x The .NET 1.1 SDK installer can be used for this purpose.
Prerequisites needed:
Download the .NET 1.1 SDK from: http://www.microsoft.com/downloads/details.aspx?familyid=9B3A2CA6-3647-4070-... (106.2 MB)
You need to apply my patch from bug 11420 -> http://bugs.winehq.org/attachment.cgi?id=10552 to work around another SCM bug. Otherwise the MDM service won't get started correctly and hangs due to named pipe/objects mismatch.
---
1. clean your ~/.wine 2. install .NET 1.1 redistributable (if you use 'sh winetricks dotnet11' make sure winetricks script is up-to-date) 3. install .NET 1.1 SDK with default install settings, takes a bit due to table JOINs ;-)
Wait until the installer hangs while displaying "Creating shortcuts" step... Thats another bug (COM/RPC/race) which needs deeper investigation.
In process list you will now find:
"C:\Program Files\Microsoft.NET\SDK\v1.1\GuiDebug\DbgCLR.exe /setup"
-> Microsoft CLR Debugger self registering for first time
"C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe"
-> "Machine Debug Manager" automagically started as COM service.
Both have "C:\Program Files\Common Files\Microsoft Shared\VS7Debug\msdbg2.dll" a COM proxy/stub dll mapped into their address space. This proxy/stub dll is only mapped on demand (client like DbgClr connects).
Try to overwrite the proxy/stub file with a copy - won't work. Executing the .NET Framework installer a second time doesn't exhibit this problem, because some installer steps are skipped now (need to re-clean your ~/.wine and reinstall or simulate without reinstall by manually executing 'DbgCLR.exe /setup' step).
Within the real VS.NET 7.x installer, the component installations following update this stuff again (.NET SDK is only small part of install). Due to the failing/hanging CLR GUI registration and MDM COM server processes - which lock the proxy/stub dll - the overall installation fails.
Before the later update on this VS7Debug components is done, ACTION_StopService is executed (table contains MDM stop) which would ideally cure the problem away. Granted, it doesn't really solve the other bugs (which require some time to track down) but let the installer go further and finish.
You can simulate this by manually stopping the MDM service (wine net stop mdm). Both processes terminate then, releasing the proxy/stub.
Sorry that I couldn't provide you with a shorter explanation/solution. There are lots of gaps/bugs in various areas which need to be addressed.
If you start implementing the next set of msi actions one day, consider stop services for it.
Regards
http://bugs.winehq.org/show_bug.cgi?id=12079
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #3 from Dan Kegel dank@kegel.com 2008-03-24 00:17:49 --- James, any luck with this yet?
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #4 from James Hawkins truiken@gmail.com 2008-03-24 01:32:13 --- Patch sent, but I can't repro the bug so you should give this a whirl Anastasius:
http://www.winehq.org/pipermail/wine-patches/2008-March/052088.html
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #5 from James Hawkins truiken@gmail.com 2008-03-24 11:56:04 --- Patch committed:
http://winehq.org/pipermail/wine-cvs/2008-March/041580.html
Please retest and resolve as appropriate.
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #6 from Anastasius Focht focht@gmx.net 2008-03-24 15:55:54 --- Hello,
there is a small typo in ControlService() which lets the service action fail.
--- snip dlls/msi/action.c --- static UINT ITERATE_StopService(MSIRECORD *rec, LPVOID param) { .. if (!ControlService(service, SERVICE_STOP, &status)) WARN("Failed to stop service (%s): %d\n", debugstr_w(name), GetLastError()); .. --- snip dlls/msi/action.c ---
SERVICE_STOP (access right type) vs. SERVICE_CONTROL_STOP (control type)
Additional "review" comments ... please don't take it as nitpicking, I acknowledge your work ;-)
SCM connect failure in ITERATE_StopService is WARN. I think SCM connect failures should be always treated as serious, while having a lasterror printout (lasterror printout is missing in ITERATE_StartService SCM connect failure case).
The ITERATE_StopService:OpenServiceW() WARN following the SCM connect is fine because in case of "stop services" actions, non-existing services are expected and service open failures shouldn't be treated as "there is a big problem" (in contrast to ITERATE_StartService where a failing OpenServiceW should be treated serious because it might indicate a previous service install problem).
For stopping services I think it's sufficient to open SCM with SC_MANAGER_CONNECT (currently opened with SC_MANAGER_ALL_ACCESS).
BTW ... I'm eagerly watching your progress on fusion. It seems the importance of fusion and msi publishing assemblies is now generally acknowledged. And ... congratulations on becoming a millionaire. ;-)
"For the record, if I were a millionaire, this is what I would work on" (quote from wine-devel).
Regards
http://bugs.winehq.org/show_bug.cgi?id=12079
--- Comment #7 from Dan Kegel dank@kegel.com 2008-03-24 16:02:55 --- I asked him to work on both issues just because I knew it would keep you chuffed :-)
http://bugs.winehq.org/show_bug.cgi?id=12079
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #8 from Dan Kegel dank@kegel.com 2008-03-25 15:44:07 --- 2nd patch committed, http://winehq.org/pipermail/wine-cvs/2008-March/041642.html Can we mark this fixed now?
http://bugs.winehq.org/show_bug.cgi?id=12079
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #9 from Anastasius Focht focht@gmx.net 2008-03-27 15:58:41 --- Hello,
--- quote --- 2nd patch committed, http://winehq.org/pipermail/wine-cvs/2008-March/041642.html Can we mark this fixed now? --- quote ---
Yes, works as expected.
Regards
http://bugs.winehq.org/show_bug.cgi?id=12079
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2008-04-04 10:06:22 --- Closing bugs fixed in 0.9.59.
http://bugs.winehq.org/show_bug.cgi?id=12079
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
http://bugs.winehq.org/show_bug.cgi?id=12079
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |ddfefc036f3dc734bd0df5f705b | |c67ba1904c0a5
http://bugs.winehq.org/show_bug.cgi?id=12079
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer URL| |http://www.microsoft.com/do | |wnload/en/details.aspx?disp | |laylang=en&id=16217 Version|unspecified |0.9.57.
--- Comment #11 from Anastasius Focht focht@gmx.net 2011-10-12 03:51:49 CDT --- Hello,
filling/correcting fields ...
Regards
https://bugs.winehq.org/show_bug.cgi?id=12079
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.microsoft.com/do |https://web.archive.org/web |wnload/en/details.aspx?disp |/20071012093921/http://down |laylang=en&id=16217 |load.microsoft.com/download | |/5/2/0/5202f918-306e-426d-9 | |637-d7ee26fbe507/setup.exe
-
wine-bugs＠winehq.org -
WineHQ Bugzilla