I have been talking to some folks inside of Microsoft, looking at a few failures that have been reported internally and externally and read some newsgroup posts and it appears that there are 3 major points where setup has been failing for the .NET Framework 1.0 SP3 and 1.1 SP1:
- Installing the SP hangs and has to be killed because it never completes successfully
- Installing the SP triggers a repair that asks for the source location of netfx.msi
- Setup throws a TargetInvocationException almost immediately after launching the installer
I wanted to talk about each of these in a little more detail….
Installing the SP hangs
In nearly all of the cases where SP setup hangs (such as the case described at http://www.gotdotnet.com/community/messageboard/Thread.aspx?id=260442) the underlying problem is that one of the IIS services fails to respond when setup tries to stop it. This should only happen on platforms that support ASP.NET (Windows 2000 and higher) and that have IIS installed, configured and started at the time setup is run. When the .NET Framework detects that IIS exists and is started, it attempts to stop the IIS Admin service in order to update ASP.NET configuration settings. .NET Framework setup uses a custom action to stop and start this service (because we want to only start the service at the end of setup if it was running prior to setup), but within that custom action it uses a standard Win32 API (ControlService). In most cases, opening a cmd prompt and running sc query iisadmin or sc query w3svc will show that one of these services is in the “stopping” state.
So far, the instances I’ve seen this behavior has been mostly on Windows XP with SP2 (and also one or 2 cases on Windows 2000 with SP4). I haven’t been able to figure out any specific root causes for this unfortunately. The workaround that I have been recommending is to kill the service pack setup, manually stop the IISAdmin service by using the Services control panel (run services.msc from a cmd prompt) or by running net stop iisadmin from a cmd prompt, and then running the service pack setup again.
Installing the SP triggers a repair
This is probably the most common issue I’ve heard of from customers who have had issues installing a .NET Framework service pack. The underlying cause for this is that Windows Installer has determined that one or more components in the version of the .NET Framework being patched is broken and needs to be repaired before installing the patch. I’ve talked a little bit in a previous blog entry about how Windows Installer’s resiliency feature works, and the workaround for this issue is straightforward, though a bit painful:
- Locate the original install package named dotnetfx.exe or re-download it – make sure that you download the version that matches the one you are trying to apply the service pack for
- Open a cmd prompt and run dotnetfx.exe /t:c:\temp /c (or some other path of your choosing other than c:\temp)
- Re-run the service pack setup and when prompted for the source location of netfx.msi, browse to the folder c:\temp that you used in the previous step to extract the contents of dotnetfx.exe
Now – the thing that is more interesting to me here is trying to figure out a root cause (or more likely, different classes of root causes). When diagnosing why the .NET Framework fails the resiliency check and triggers a repair, I usually look at the application event log on the computer by running eventvwr.exe from a cmd prompt. From there I look for log entries where the source name is MsiInstaller. Resiliency repairs usually create pairs of warnings in the application event log that contain GUIDs for the component that triggered the resiliency check, and the component that failed the check and requests the repair. Generally, I can take that information from the event log and cross-reference it against the MSI data in Orca (ctrl+c in event viewer, ctrl+f in Orca, ctrl+v in the Orca find dialog and away we go)
I have been playing around with some of the event log Win32 APIs to try to write a little app that would mine this data to make it easier for us to gather data from customers who are hitting this. So far I have figured out how to create a copy of the application event log and zip it to send in email. I also figured out how to parse the application event log and find all of the entries where the source is MsiInstaller. The thing I’ve been having trouble with is converting the warnings into readable strings. The warnings are strings loaded from msi.dll that have tokens (%1, %2, etc) to replace, and I haven’t figured out yet how to pull the tokens out of the event log entry and plug them into the string I load from msi.dll. So if anyone has any pointers or sample code for manipulating event logs, I’d appreciate it….
This error is something new with this round of service packs (1.0 SP3 and 1.1 SP1). The wrapper EXE for the .NET Framework service packs is new compared to 1.0 SP2, and it is written in managed code this time around. Because of that, if there is something broken in the version of the .NET Framework on the machine, it may fail. From what I have heard so far, a major cause of this error is applying a previous service pack or QFE for the .NET Framework and then attempting to install 1.0 SP3 / 1.1 SP1 without a reboot in between (because the previous SP or QFE may need to update in-use assemblies and be unable to do so without a reboot). So, the first thing to try to workaround this issue is to reboot and re-run the service pack.
If the reboot does not help, it may help to examine the log file from the service pack wrapper setup. The wrapper creates a log file in the %temp% directory named netfxsl.log. In many cases, the exception occurs before any useful data can be written to the log, but it is good to check just in case. In addition, if you run the wrapper with the switch /l:logfile it will generate a log in the location you specify – but this will not happen if the exception is thrown while the setup package is being extracted. I have not yet encountered a machine that is failing with this error, so I don’t know what level of detail is provided by this log file. If anyone gets a chance to try this out, please send me a mail and attach the log file so I could take a look.
As a workaround, I suggest trying to manually extract the setup package on a different machine by running the package with the /Xp:<path>. This will extract the Windows Installer patch package (named *.msp) to the path you specify. Then you can copy that MSP file to the machine where you are seeing the failure and right-click on it and try to install it directly. There will likely be some later failure, but hopefully the error is more easily understandable and diagnosable when that happens. Again, if anyone has a machine in a failing state that they try this on, I would like to know the results.
I’ll post more as we learn more about other points of failure, additional workarounds and diagnoistic tools, etc….