共用方式為

Troubleshooting Error 800B0100, TRUST_E_NOSIGNATURE, during Service Pack 1 installation on Windows 7 or Windows 2008 R2

  • 發行項

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:

    

clip_image002

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:

clip_image004

 

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 (https://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

2011-08-24 09:28

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Summary:

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~~6.1.1.1.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~~6.1.1.1, 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~~6.1.1.1.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:

  • Download and Install the System Update Readiness/Checksur tool from https://support.microsoft.com/kb/947821. Run the tool initially in an attempt to have the tool repair the corruption on the installation.
  • If the CheckSUR utility does not fix the corruption, download the .MSU patch for the update you're having issues with from the Microsoft Update catalog website or the Microsoft Support site and then put that file under the C:\Windows\CheckSur\Packages folder. NOTE: The \Packages folder does not natively exist and will need to be created
  • Run the System update readiness tool again, it will attempt to replace any corrupt/missing files from the downloaded package automatically.
  • You may want to view the %SYSTEMROOT%\Logs\CBS\Checksur.log to verify if the corrupt/missing files have been replaced.

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~~6.1.1.1.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

Comments

  • Anonymous
    January 01, 2003
    Hello Himanshu,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~~6.1.1.0.cat.Can I simply remove the file from C:WindowsServicingPackages and try to reinstall ?Thanks
    • Anonymous
      June 08, 2016
      Tanks for the detailed write-up.it contact some Good tips and advice
  • Anonymous
    December 14, 2011
    Himanshu,Thanks for the detailed write-up.  It contains some good tips and advice.
  • Anonymous
    January 07, 2012
    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!
  • Anonymous
    March 12, 2012
    The comment has been removed
  • Anonymous
    May 12, 2012
    Can u help me ?
  • Anonymous
    January 23, 2013
    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!
  • Anonymous
    January 24, 2013
    Super glad to have found this.. I suspected that I needed to do something like this but was unsure of syntax / command. THANKS!
  • Anonymous
    April 05, 2013
    The comment has been removed
  • Anonymous
    November 04, 2013
    Dear Himanshu,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).
  • Anonymous
    August 25, 2014
    Hey I have faced the same problem against this issue but i resolved this issue with the help of this linkhttp://www.microsoftliveassist.com/error-0x800b0100-when-you-try-to-install-windows-updates-or-microsoft-updates/
  • Anonymous
    December 24, 2016
    I am getting the same error 800b0100 in my windows phone lumia 930 when trying to update to windows 10. How to troubleshoot this problem in windows phone?