I often get questions from fellow employees or customers who find my blog regarding how to troubleshoot .NET Framework installation errors.  I want to outline the process that I use to narrow down one of the most common errors that I see that can cause the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the .NET Framework 3.5 to fail in the hopes that it will help some folks who read this post in the future be able to narrow down and resolve this issue on their system if they encounter it.

This particular error occurs when a custom action that runs an EXE named ServiceModelReg.exe during .NET Framework 3.0 setup fails.  This custom action is inside of the Windows Communication Foundation (WCF) MSI in the .NET Framework 3.0, and it also is run during .NET Framework 3.5 setup because the .NET Framework 3.5 requires the .NET Framework 3.0 SP1 as a prerequisite.  I use the following process to narrow down the root cause of the error and attempt to identify useful workarounds:

Step 1 - Find the exact component that is failing

I start the investigation process by looking at the .NET Framework 3.0 setup log files or the .NET Framework 3.5 setup log files, depending on what setup is failing.

If the error occurs during .NET Framework 3.0 setup, the main .NET Framework 3.0 setup error log file (named %temp%\dd_dotnetfx3error.txt) will show an error like the following in this case:

[03/25/08,11:11:11] Windows Communication Foundation: [2] Error: Installation failed for component Windows Communication Foundation. MSI returned error code 1603

If the error occurs during .NET Framework 3.5 setup, then the main .NET Framework 3.5 setup error log file (named %temp%\dd_dotnetfx35error.txt) will show an error like the following in this case:

[03/25/08,11:11:11] Microsoft .NET Framework 3.0a: [2] Error: Installation failed for component Microsoft .NET Framework 3.0a. MSI returned error code 1603

Step 2 - Find the verbose MSI log for the failing component

From here, I proceed to locate the verbose MSI log file for the specific component that is failing.  As I described in this blog post, the .NET Framework 3.0 and 3.5 installers create their own verbose log files by default, so there is no need to enable logging and re-run setup to produce verbose logs.

If the error occurs during .NET Framework 3.0 setup, the verbose log file that contains the error will be named %temp%\dd_wcf_retMSI*.txt in this case.

If the error occurs during .NET Framework 3.0 SP1 setup, the verbose log file that contains the error will be named %temp%\dd_NET_Framework30_Setup*.txt in this case.

Step 3 - Find the error causing the failure within the verbose MSI log

Once I have located the appropriate verbose MSI log file, I use the technique described in this blog post to narrow down the root cause of the failure.  Searching for the string return value 3 in the case of this particular error shows that the last action being run prior to setup failing is the following:

MSI (s) (B4:D0) [11:11:11:011]: Executing op: CustomActionSchedule(Action = DD_CA_InstallXwsRegExe_X86.3643236F_FC70_11D3_A536_0090278A1BB8, ActionType=3073, Source=BinaryData, Target=QuietExec, CustomActionData=c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe /r /x /y /v; dummy; c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\)

Note that you cannot search for the string return value 3 if you are installing on a non-English OS.  Windows Installer translates the string "return value" into the OS language when it creates entries in a verbose MSI log file, so you will need to search for a translated version of this message if you are installing on a non-English OS.

Step 4 - Find the root cause of this custom action failure

In this case, the verbose MSI log file shows that the custom action that runs ServiceModelReg.exe is failing in this case.  This custom action is designed to create its own log file named %temp%\dd_wcf_retCA*.txt, so the first thing I try when I see this type of error is to find that file and look for errors, warnings, or exceptions.  Most of the time, if that log is created, the error listed there is fairly self-explanatory and it is straightforward to determine how to work around the problem.

However, I have also seen many cases where ServiceModelReg.exe fails but does not create this additional log file.  In that case, the next step is to go look at the application event log to see if any exceptions were logged by this action that will help narrow down the root cause.  You can do the following to locate this type of error in the application event log:

1. Click on the Start menu, choose Run, type eventvwr and click OK
2. Click on the Application log on the left side of the Event Viewer
3. Locate the application event log entries with time stamps that match the time stamps of the custom action listed in the verbose MSI log files described above
4. Look for errors with the source value set to System.ServiceModel.Install 3.0.0.0 (this is the assembly that is loaded by ServiceModelReg.exe to perform the registration that it needs to do)

In most cases that I've seen of this issue in the past, the exception listed in the application event log looks like the following:

System.TypeInitializationException: The type initializer for 'System.ServiceModel.Install.IisHelper' threw an exception. ---> System.ApplicationException: ServiceModelReg.exe has detected a possible corruption in the IIS metabase that prevents the registration of the ServiceModel IIS scriptmaps.  Please either fix the IIS metabase corruption, or, if you do not desire ServiceModel WebHost funtionality, disable the IISAdmin service and reregister ServiceModel. ---> System.Runtime.InteropServices.COMException (0x8009000F): Object already exists.

Step 5 - Try to fix the underlying issue

Typically, the above error means that there is something wrong with the installation of IIS on the system.  What I normally suggest to try to fix this type of error is to try to uninstall and then re-install IIS using the Add/Remove Windows Components control panel, reboot, and then try to install the .NET Framework 3.0 or 3.5 again.  If that does not help, it should also be possible to disable the IISAdmin service on the system prior to installing the .NET Framework 3.0 or 3.5 (assuming that you do not plan on using Windows Communication Foundation WebHost functionality after installing the .NET Framework 3.0 or 3.5).  To do that, you can use these steps:

1. Click on the Start menu, choose Run, type services.msc and click OK
2. Find the service named IIS Admin Service, right-click on it and choose Properties
3. Change the Startup type drop-down to Disabled 
4. Click the button to stop the service
5. Click OK to dismiss the Service Properties dialog

If the above steps do not work, it can also be helpful to try to install the .NET Framework 3.5 SP1 (which will install the .NET Framework 3.0 SP2 and 2.0 SP2 behind the scenes).  As described in this blog post, there are some changes in .NET Framework 3.5 SP1 setup that can allow it to succeed in cases where .NET Framework 3.0 or 3.5 setup would otherwise fail.

What to do if steps 4 and 5 do not match what you see on your system

This blog post is intended to demonstrate how I approach narrowing down the root cause of a particularly common installation problem that affects the .NET Framework 3.0 and 3.5.  However, there are several possible causes of installation failures in the .NET Framework, so that means that these steps will not work for all cases.  If you do not see the specific types of entries in your log files, then the workaround in step 5 will likely not help, but steps 1 through 4 can still be helpful in finding the root cause.

I have posted about other possible causes of ServiceModelReg.exe custom action failures in the following blog post:

• .NET Framework 3.0 and 3.5 ServiceModelReg.exe custom action failure related to files in the temporary directory 

I also suggest consulting the .NET Framework setup troubleshooting guide for links to other possible installation issues and workarounds, links to log file locations, links to readme files, etc.

<update date="11/24/2008"> Added a link to a new blog post I wrote about another possible cause of ServiceModelReg.exe custom action failures in the .NET Framework 3.0 and 3.5. </update>

<update date="8/10/2009"> Added a suggestion to try installing the .NET Framework 3.5 SP1 as a possible workaround to this type of install failure. </update>