Partilhar via

Steps I use to diagnose .NET Framework 3.0 and 3.5 installation failures related to the ServiceModelReg.exe custom action

  • Artigo

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:

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>

Comments

  • Anonymous
    March 29, 2008
    I believe you forgot SP1 somewhere. "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 setup, the verbose log file that contains the error will be named %temp%dd_NET_Framework30_Setup*.txt in this case."

  • Anonymous
    March 29, 2008
    Hi Tanveer - You are correct.  I missed that when I was proof-reading the post yesterday.  I will update the text of the post now.  Thanks for letting me know.

  • Anonymous
    July 11, 2008
    The comment has been removed

  • Anonymous
    July 11, 2008
    Hi MattN - Thank you for posting about your experience with troubleshooting this issue.  I have heard of some cases where there are TypeLoadExceptions being thrown due to assembly mismatches for System.ServiceModel.Install DLLs left behind from 3.0 beta versions.  You're correct that the cleanup tool currently doesn't handle them, but that is something I will look to add to a future version of the cleanup tool. One thing I'm not sure I understand though - the assembly Microsoft.VisualStudio.Diagnostics.ServiceModelSink is a Visual Studio assembly, not a .NET Framework assembly.  I haven't previously heard of any conflicts related to assemblies not shipped within the .NET Framework installer packages.  The cleanup tool only cleans up files that are installed by the .NET Framework, so I am not going to be adding any logic to cleanup that Visual Studio file.  Are you sure that this assembly really caused any problems with .NET Framework installation on your system?  Or were you just looking for anything in the GAC on your system that had ServiceModel or version 3.0.0.0 in the strong name?

  • Anonymous
    July 29, 2008
    Thanks MattN, I was getting the same error and the process you explained worked for me.  I had to delete registry keys for 13 dlls before unregistering but afterward the installation worked!   Much appreciated.

  • Anonymous
    July 30, 2008
    The comment has been removed

  • Anonymous
    August 10, 2008
    The comment has been removed

  • Anonymous
    October 08, 2008
    Great Post, much appreciated! I followed your guides, ended up threw in 3.5 SP1 and everything seems successful. Just wondering if I still need to re-install IIS snice I don't see it anywhere in Services.msc Anyway, thanks a lot

  • Anonymous
    October 08, 2008
    Hi JackySzeto - It sounds like you didn't have IIS installed on your system in the first place, so in that case it is not necessary to install it. One thing for others reading this post in the future - the .NET Framework 3.5 SP1 installs the .NET Framework 3.0 SP2 as a prerequisite behind the scenes.  The .NET Framework 3.0 SP2 setup is configured to allow installation to complete even if the ServiceModelReg custom action fails.  That means that you won't see the errors described in this blog post if you install the .NET Framework 3.5 SP1 on your system.

  • Anonymous
    November 24, 2008
    I have run into a few reports of .NET Framework 3.0 and 3.5 installation failures recently that have

  • Anonymous
    December 12, 2008
    I previously posted a couple of items about how to troubleshoot and work around issues in .NET Framework

  • Anonymous
    March 02, 2009
    More good articles on framework installation issues by Aaron Stebner are available than the ones related

  • Anonymous
    August 01, 2012
    The comment has been removed

  • Anonymous
    August 03, 2012
    Hi Acquiel - Can you please use the tool described at blogs.msdn.com/.../6458047.aspx to collect all of your setup log files, upload the file named %temp%vslogs.cab that this tool will create to a file server (such as http://skydrive.live.com), and then reply back here and provide a link that I can use to download your log files and take a closer look? Also, I noticed that you posted the same comment on several different blog posts.  In the future, you only need to post a comment on one blog post, and I'll see it and respond to it.

  • Anonymous
    August 12, 2012
    Hi Aaron Stebner - This is my vslogs.cab . Hope you can fix this . thanks in advance . By the way  sorry for posting same comments in your different blog post . ^_^ . skydrive.live.com/redir

  • Anonymous
    August 14, 2012
    Hi Acquiel - According to your log files, the XPS installer is failing to run for some reason.  Can you please try to download and run the XPS installer directly from go.microsoft.com/fwlink and see if that works for you?  If it fails, can you please let me know the exact error message it displays, and can you please also check to see if it creates any log files in %temp% or %windir%?  If there are logs, please upload them to your Skydrive site so I can take another look.