Doctor Deploys Blog

I’m curious to hear from people that are hitting or have hit this issue.

 

Im particularly curious if trustedinstaller.exe is present under %windir%\servicing\trustedinstaller.exe. This appears to be the main root cause of this issue (at least on the machines I’ve seen). This will help better understand if this is the root cause of all the issues I’ve been hearing about or if there are other root causes.

 

If this is the root of your issue. I would recommend following the steps in this article to try to get trustedinstaller.exe put back http://support.microsoft.com/kb/929833 .
For anyone who hit this and trustedinstaller.exe is present, I’d love to get in touch with you to hopefully find potential other root causes of this issue.

Below are more details about the issue for those of you that are interested.

.NET 4 depends on a Windows Update which is documented in these KB articles:
Win7 = http://support.microsoft.com/kb/958488
Vista = http://support.microsoft.com/kb/956250

Aaron Stebner did a good job in root causing this down to an issue with Windows Update on the machine. He documented his analysis here: http://blogs.msdn.com/b/astebner/archive/2010/12/29/10110053.aspx

The issue here is the .NET 4 is trying to install the update it depends on but Windows Update is, in error, telling the .NET 4 installer that the update is not applicable to the machine. The .NET 4 installer treats this response to mean that is not needed and moves on. In general, if Windows update is returning “not applicable” for and update one of wo things is true. Either its not applicable, or something is really wrong with Windows Update and no updates including critical security updates are able to install.

I took Aaron’s investigation a step further and was able to find a concrete example of where I could get Windows Update to return “not applicable” on a machine where an update should have been applicable. On this machine TrustedInstaller.exe was not present on the machine which is critical for correct behavior of Windows Update.

I then found that there are numerous places on the web that are telling people to disable, remove, or in other ways kill trusted installer. This is a bad idea and appears to be the root cause of a lot of these issues. Products that depend on your copy of Windows being up to date will all exhibit weird behaviors if the update cannot be applied. The workarounds I’m seeing for this issue are scary and likely have unintended consequences such as future updates failing to install and putting your machine in a state that Microsoft can’t support. I dont recommend taking ownership of system files, hacking files out of installer packages and manually updating them.

I’m curious to hear from people that are hitting or have hit this issue. Leave a comment or contact me directly through my blog.

 

The issue here is often that %windir%\system32\mscoree.dll is not updated as part of the install. Behing the scenes of the installer, .NET 4 is trying to install an update to the OS and that it depends on but Windows Update. Windows update is telling the .NET 4 installer that the update is not applicable to the machine. The .NET 4 installer treats this response to mean that is not needed and moves on. In general, if Windows update is returning “not applicable” for and update one of wo things is true. Either its not applicable, or something is really wrong with Windows or Windows Update and no updates including critical security updates are able to install.

 

 

 

I’m curious to hear from anyone experiencing this issue. I’d like to know which of this issues it wascor if there is a root cause of this that I have not found.

 

 

 

If this is the root of your issue. I would recommend following the steps in this article to try to get trustedinstaller.exe put back http://support.microsoft.com/kb/929833 .
If anyone has any idea what would have removed trustedinstaller.exe from their machine, I’d love to hear about it.

 

 

You can check this by looking at the version of %windir%\servicing\trustedinstaller.exe or looking in %windir%\logs\CBS\CBS.log. In the log you should see logging lines that look something like this: “Loaded Servicing Stack v6.1.7601.17592″.

 

For Windows 7, I would expect to see a version of at least v6.1.7600.16385. If you see a number lower than this on Windows 7, the only way I know of to fix this issue is to do an upgrade to a supported released version of Windows 7. The more important thing in this case is that pre-release OS’s do not get updated with critical security patches from Microsoft. Thats not a really good situation to be left in, especially if you dont know it.

 

I’ve seen many reports of people having a build number of v6.1.7600.16384 which is one number below the released build. I’m really curious how people would have gotten this build of the OS. The fact that its so close to the final build makes me wonder if it could have been accidentally released somehow. Please let me know if you got it through an official supported channel and its the wrong version.

I’d like to thank Mike Lewis for contacting me and helping me find the 2nd root cause. I’d love to hear from anyone else hitting this issue to make sure I can write down all the causes of this for people.