Microsoft Enterprise Platforms Support: Windows Server Core Team
Hello, My name is Himanshu and I work with the Windows Core Support Team. Recently, I worked on a patch installation issue known internally at Microsoft as a servicing issue. I thought this would be a great customer example as to how a specific error message can sometimes be misleading when troubleshooting based on error text alone. For this issue, my customer explained me that he was getting an error 800B0100 when he trying to install patches using the Windows Update control panel applet. A screenshot of the error is below:
In addition to the Windows Update failure, attempting to open Server Manager on the server would also fail with the same error (0x800B0100) as seen in the screenshot below:
Now, let me first explain, why the error you see in Windows Update and Server Manager is related. When you open the Server Manager it runs a discovery using Role-specific and Component Based Servicing APIs to query CBS and discover which roles, role services, and features are currently available and installed. If CBS is in an error condition, Server Manager will fail to function properly until the error condition is resolved.. You can always look at the %SYSTEMROOT%\Logs\ServerManager.log to find out what server manager is doing at any point of time. Because the ServerManager.log is in use on a running installation of Windows, you will need to copy the log to a different location to open it properly.
The error code 800B0100 maps to “TRUST_E_NOSIGNATURE” which means that the file was not signed or had a signature that was not valid.
A manifest is an XML format document that describes individual elements of installation for a component or package. Below is a sample manifest:
<?xml version="1.0" encoding="utf-8"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0"> <assemblyIdentity name="0e348ebbcfb1d8af965282e6002364f0" version="6.1.7601.21755" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <deployment /> <dependency discoverable="false"> <dependentAssemblydependencyType="install"> <assemblyIdentity name="Microsoft-Windows-OS-Kernel" version="6.1.7601.21755" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> </dependentAssembly> </dependency> </assembly>
The error tells me that either there is no signature on the manifest file or the signature is corrupt. This can occur for a number of reasons such as the downloaded WU package are corrupt. In cases like this, we would recommend the customer attempt to re-download and re-attempt installation from a new package download. In this case, the customer had already attempted to download and install the package locally with similar failure results.
The next step in troubleshooting this issue would be to run the System Update Readiness tool (http://support.microsoft.com/kb/947821) to attempt to resolve the corruption within CBS. (The CheckSUR tool checks for inconsistencies in file data or registry data and detects incorrect manifests and files contained within its payload and attempts to replace them with the proper version. We ran the CheckSUR utility against the machine and the results turned out to be clean as seen in the log output…
Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 13.0
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Component Store
Seconds executed: 757
No errors detected
Next, I looked at the CBS logs (%SYSTEMROOT%\Logs\CBS\CBS.log) in an attempt to determine the root of the problem. The CBS.log is similar to the ServerManager.log in that its in use and needs to be moved to another location to open properly. Note: You can also get around this by using notepad.exe in a command interpreter and typing in notepad.exe CBS.log to open the log...
CBS.log had several entries similar to the ones below:
2011-08-24 13:05:23, Info CBS WinVerifyTrust failed [HRESULT = 0x800b0100 -TRUST_E_NOSIGNATURE]
2011-08-24 13:05:23, Error CBS Failed to verify if catalog file \\?\C:\Windows\Servicing\Packages\Package_for_KB2556532~31bf3856ad364e35~amd64~~188.8.131.52.cat is valid. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:23, Info CBS Failed to initialize internal package [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:23, Info CBS Failed to create package. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:23, Error CBS Failed to internally open package. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:23, Info CBS Session: 30171776_51578712 initialized by client WindowsUpdateAgent.
2011-08-24 13:05:23, Info CBS Read out cached package applicability for package: Package_for_KB2556532~31bf3856ad364e35~amd64~~184.108.40.206, ApplicableState: 112, CurrentState:64
2011-08-24 13:05:26, Info CBS Session: 30171776_82377522 initialized by client WindowsUpdateAgent.
2011-08-24 13:05:26, Info CBS WinVerifyTrust failed [HRESULT = 0x800b0100 -TRUST_E_NOSIGNATURE]
2011-08-24 13:05:26, Error CBS Failed to verify if catalog file \\?\C:\Windows\Servicing\Packages\Package_for_KB2556532~31bf3856ad364e35~amd64~~220.127.116.11.cat is valid. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:26, Info CBS Failed to initialize internal package [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:26, Info CBS Failed to create package. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
2011-08-24 13:05:26, Error CBS Failed to internally open package. [HRESULT = 0x800b0100 - TRUST_E_NOSIGNATURE]
The errors above tell me that the problem is with a particular catalog file of patch KB2556532 (bolded and underlined above for clarity) and it has no signature on it. The best course of action here appeared to be to replace the catalog files with known good files from a working Windows installation.
The file which I want to replace was under C:\Windows\Servicing\Packages\ folder on which a normal user would have access. I have seen that many blogs suggest modifying permission on the C:\windows\servicing\Packages and then copy/replace the files. However, that’s not required. In fact, changing permissions to this directory may result in other errors and is not recommended.. To replace a corrupt file which you know is part of a particular patch, just follow the below steps:
In my case, this didn’t work as CHECKSUR didn’t replace any files.
I looked for the same file (C:\Windows\Servicing\Packages\Package_for_KB2556532~31bf3856ad364e35~amd64~~18.104.22.168.cat) on a working machine and they were exactly same in size, signatures, etc. So, the error looked misleading to me. I decided to find out where exactly we are failing.
Before, I ask my customer to run the SysInternals PROCMON tool to determine which component/registry/file we were failing on. I compared the C:\Windows\servicing\ folder with the working machine and found that the permissions on C:\windows\servicing\packages had been changed. Administrators, SYSTEM, TrustedInstaller and USERS had no permission on the folder. As mentioned previously, modifications to the default permissions can have adverse effects on a servicing operation.
Normally, the NT SERVICE\TrustedInstaller is the owner of the C:\Windows\servicing folder and has FULL Control on it. The SYSTEM, Local Administrators group and the Local USERS group has Read and Execute permission on this folder. The same permission is propagated down the folder to all subdirectories and files. Hence, the C:\windows\servicing\packages directory should have same permission as its parent C:\Windows\servicing.
Since, in this case permission were missing on the C:\windows\servicing\packages folder, we needed to fix the permissions. Icacls is one tool that can be used to reset the permissions on a directory.
The below command was run to add the NT Service\TrustedInstaller as owner of the Packages folder and any files/folders under it:
icacls C:\Windows\Servicing\Packages /setowner "NT SERVICE\TrustedInstaller" /t /c
We ran the below commands to give Read and Execute permission to the SYSTEM, Local Administrators and Local USERS account:
icacls c:\Windows\Servicing\Packages /grant SYSTEM:RX /t /c
icacls c:\Windows\Servicing\Packages /grant domain\administrators:RX /t /c
icacls c:\Windows\Servicing\Packages /grant domain\Users:RX /t /c
After the required permission was given, the installation of the previously failed updated completed successfully and Sever Manager came up fine as well.
In this blog, I have tried to explain the troubleshooting steps used in a typical servicing operation in a chronological order where installations of patch/patches may fail.
Hopefully, this would help you resolve issues similar to this if you are to run into them.
Himanshu Singh Support Engineer Microsoft Enterprise Platforms Support
Thanks for the detailed write-up. It contains some good tips and advice.
Thanks for the quality explanations and detail! I hope people stumble across this and can take some good information away from this article. Vista / Win7's new update framework mystifies most, but this helps clarify some of what's going on. Thanks!
This is great information for techno geeks but does not help simple people resolve the issue. Can you tell me if MS is going to do something to fix it so normal people can actually install SP1 for Windows 7?
Can u help me ?
Been researching on the net for ages to try and find a fix to this. Followed so many articles and this is the one that fixed it for me. Thanks!
Super glad to have found this.. I suspected that I needed to do something like this but was unsure of syntax / command. THANKS!
I'm facing a similar problem when trying to install SP1.
The package thats is causing the problem is, in my case, Package_for_KB2758857~31bf3856ad364e35~amd64~~22.214.171.124.cat.
Can I simply remove the file from C:\Windows\Servicing\Packages and try to reinstall ?
A very good article and I will be trying this out after I get some sleep. I spent around 4-6 hours on this and have done every trick in the book. I even uninstalled every "update" on my machine, which means I'm basically running vanilla windows 7 x64 once again. I put in my 1.9gig windows SP1 CD, and still got the same error message that has been haunting me all day. Honestly, I'm not ready to throw in the towel yet, but I am ready to denounce Microsoft as a company for even letting an issues like this take over. My one buddy ran into this SAME EXACT issue and has since uninstalled Windows from his machine, because 3 hours learning how to use Linux is better than 6 hours working on a clearly flawed automatic-update installer. A multi-billion dollar company should really have this issue fixed by now - not a suggest several "hot fixes" that don't actually fix anything. That being said, I sincerely thank you for your time and effort Himanshu Singh and people like you are the only reason why I haven't given up on this company yet.
Thanks a lot for your helpful post, i had problem with installing win 7 sp1 for almost a year, and finally find your post.
my problem was the KB2454826 update which was preventing from installing sp1 update(kb976932-x64).