Possible issue where .NET Framework 4 setup reports success but fails to update mscoree.dll behind the scenes
I have heard from a few customers since the release of the .NET Framework 4 who have installed the .NET Framework 4 on Windows Vista or higher and setup reported success, but they see an error when running the .NET Framework setup verification tool. I wanted to describe this scenario in a bit more detail, including how to diagnose whether or not your computer is running into this issue based on the setup log files.
How to quickly tell if this blog post might apply to you
Before reading this whole post, here is a quick way you can check whether or not you are likely to be encountering the issue described below:
- Your OS was Windows Vista, Windows Server 2008 or Windows 7. This particular issue does not affect Windows XP or Windows Server 2003.
- You installed the .NET Framework 4 and setup reported success, but you cannot use .NET Framework 4 applications on your computer afterwards.
- The file %windir%\system32\mscoree.dll and/or %windir%\syswow64\mscoree.dll has a file version of 2.0.* instead of 4.0.* (and you have rebooted your computer after installing the .NET Framework 4 to make sure that any files that were in use during installation have had a chance to be updated).
Symptoms of the problem
In the cases I’ve seen so far, the .NET Framework setup verification tool reported an error like the following when it tried to run a .NET Framework test application that is bundled with it:
****ERROR**** Process 'Netfx40TestApplication.exe' exited with return code -2146232576
This return code translates to 0x800131700, which is a .NET Framework common language runtime (CLR) error code that means “Failed to load the runtime.” In other words, this return code means that this version of the .NET Framework runtime failed to load at all on this computer.
Further investigation on the computers that exhibited this behavior showed that the file mscoree.dll (which is located in %windir%\system32 and/or %windir%\syswow64) had a version number of 2.0.*. This file is shared by all versions of the .NET Framework, and it should always have a version of at least 4.0.* after installing the .NET Framework 4. If this file is not updated to version 4.0.*, the CLR loader will be unable to load the .NET Framework 4, and it will cause the type of failure in the .NET Framework verification tool that I described above.
Gathering more detailed information from .NET Framework setup log files
I wasn’t sure how a computer could be in a state where .NET Framework 4 setup reported a successful installation but yet mscoree.dll was still versioned 2.0.*. I had the customers use the instructions in this blog post to gather their .NET Framework setup log files, and I started looking at the logs to narrow this issue down further.
In the cases I’ve seen so far, I found an error like the following in the log file named Microsoft .NET Framework 4 Setup_*.html:
Exe (C:\Users\myusername\AppData\Local\Temp\Microsoft .NET Framework 4 Setup_4.0.30319\Windows6.1-KB958488-v6001-x64.msu) failed with 0x80240017 - (null).
The .msu file listed in the above error message is one of the ones that are responsible for updating mscoree.dll to version 4.0.* on Windows Vista and later versions of Windows. Return code 0x80240017 means that the .msu file is not applicable on the computer it is being installed on. This type of return code can occur for several different reasons:
- The .msu is for an earlier or later OS version or service pack level than what is currently on the computer
- The .msu is for a different processor architecture than the OS running on the computer
- The .msu is already installed
- The OS update installation engine is in a broken state that prevents the installation of any OS updates (.msu files)
- The OS is a pre-release version of Windows Vista, Windows Server 2008 or Windows 7. See this blog post for more details about this case.
.NET Framework 4 setup prevents cases #1 and #2 from happening behind the scenes, but it cannot prevent cases #3, #4 or #5. To complicate things further, it is not possible to reliably distinguish from this return code which of the cases is the actual cause of the return code. Even worse, case #3 is a case that should be treated the same as a successful installation of this .msu as opposed to a failure.
As a result, the .NET Framework 4 setup ignores this error and treats it as a successful installation of this .msu (case #3). This is why you will see information like the following later in the log file:
Error 0x80240017 is mapped to Custom Error: Success
Narrowing down the root cause based on the log files
Because mscoree.dll was not updated like it should have been on the affected computers, I made an educated guess that the customers who contacted me were running into case #4 on their computers. I was able to confirm this in the following ways:
- Looking at the log files named %windir%\WindowsUpdate.log and %windir%\logs\cbs\cbs.log (both of which are collected by the log collection tool linked above). In the cases I’ve seen so far, one or both of these logs showed errors while trying to evaluate applicability and/or install OS updates. These errors affected the .NET Framework 4 .msu file as well as other OS updates that the customer had attempted to install.
- Trying to manually install an OS update from Windows Update or by downloading it and running it directly. In the cases I’ve seen so far, attempting to install any OS update failed just like the .NET Framework 4 .msu file failed.
Possible solutions for this type of error
In some cases, it can help to run SFC to repair the files that are installed as a part of Windows. You can find steps that explain how to do this in this knowledge base article.
If SFC does not help, the System Update Readiness Tool might help repair the computer so that OS updates will install again. I’ve posted a set of steps I’ve had success using with this tool in some cases in the past in this blog post.
Peter Marcu has posted a few additional suggestions on his blog for this type of issue as well.
Unfortunately, if the above suggestions do not help, the only other way that I've found to solve this type of OS update installation error is to repair Windows.
<update date="12/30/2010"> Added a note about pre-release versions of Windows causing this error as well. </update>
<update date="7/27/2011"> Added a note about using SFC to repair Windows files, as suggested in Peter Marcu's blog. </update>
<update date="11/8/2011"> Added a direct link to Peter Marcu's blog post about this issue. </update>
<update date="6/6/2012"> Fixed broken link in the "Gathering more detailed information" section. </update>