Issues I’ve seen so far with installing .NET Framework 1.0 SP3 and 1.1 SP1

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 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....



Comments (9)
  1. Regarding the TargetInvocationException:<br><br>I just downloaded the file end started it from cmd prompt with <br><br> NDP1.1sp1-KB867460-X86.exe /l:uwelog.txt OR<br> NDP1.1sp1-KB867460-X86.exe /l:c:uwelog.txt<br><br><br>But unfortunately it did NOT generate any logfile, also the exception occured and was displayed.<br><br>Maybe I’m wrong on one of the following things:<br>- I should not pass the &quot;/l&quot; parametert to NDP1.1sp1-KB867460-X86.exe but rather to some temporary setup file, extracted by NDP1.1sp1-KB867460-X86.exe.<br>- My machine is a development machine and therefore brings up the &quot;use debugger&quot; dialog box instead of writing to a log file.<br>- I use a german Windows XP and .NET. Maybe this only works with native english?

  2. Uwe says:

    Regarding the TargetInvocationException:

    I just downloaded the file end started it from cmd prompt with

    NDP1.1sp1-KB867460-X86.exe /l:uwelog.txt OR

    NDP1.1sp1-KB867460-X86.exe /l:c:uwelog.txt

    But unfortunately it did NOT generate any logfile, also the exception occured and was displayed.

    Maybe I’m wrong on one of the following things:

    – I should not pass the "/l" parametert to NDP1.1sp1-KB867460-X86.exe but rather to some temporary setup file, extracted by NDP1.1sp1-KB867460-X86.exe.

    – My machine is a development machine and therefore brings up the "use debugger" dialog box instead of writing to a log file.

    – I use a german Windows XP and .NET. Maybe this only works with native english?

  3. Another point of failure then. I have 3 Win2003 machines with the 1.0 and 1.1 frameworks on. 1.1 updates perfectly, but when 1.0 tries to update it complains ….

    Product: Microsoft .NET Framework (English) — Error 1706.No valid source could be found for product Microsoft .NET Framework (English). The Windows installer cannot continue.

  4. Regarding the first issue – it is possible that the TargetInvocationException happens before the log file command line is parsed. Could you try to run a simple /? on that package and see if it still throws the exception? Also, you may want to check out the application event log and determine whether or not there are any interesting entries there. One other thing to try would be to take that EXE to a different machine, then run it with /Xp:<path>. This will extract the patch package (*.MSP) to the location you specify. Then you can take that MSP back to the other machine and right click and choose to install.

    For the 2nd issue, that is a repair being triggered because a component is detected as being broken. Extracting the original dotnetfx.exe using /t:c:temp /c and then browsing to that copy of netfx.msi when prompted should let you get past that. You can also look in the application event log for information about why the repair was triggered.

    If the above doesn’t help please email me directly at aaronste "at" microsoft "dot" com and we can look at it in more detail….

  5. nel says:

    i just tried to install Microsoft .NET Framework 1.1 Service Pack 1 on my Windows ME machine and it kept failing without giving me an error. I was finally able to install it successfully when i did a Ctrl+Alt+Del while setup was in progress and noticed two processes Sla325 and Ndp1. I went ahead and KILLED/end Task the Sla325 and setup was able to successfully install the service pack1.

  6. I have posted a couple of previous items about .NET Framework 1.0 SP3 and 1.1 SP1 installation issues

Comments are closed.

Skip to main content