How to Trace what Windows Update a Manifest File Originated From
Warning
This is an advanced method for solving Windows Update issues (outlined in CheckSUR logs). I would highly advise against doing this unless you're sure about what to do!
In CheckSUR logs, you will sometimes see errors about missing manifests. In this tutorial, I will show you how to trace what update that manifest originated from so that we can source a clean copy. Here is an exemplar CheckSUR log with missing manifests:
Code:
Checking System Update Readiness.
Binary Version 6.0.6002.22574
Package Version 15.0
2012-08-03 20:17
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
(f) CSI Manifest Failed Catalog Check 0x00000000 winsxs\Manifests\x86_81a783d915bb6f248faec54858397f60_31bf3856ad364e35_6.0.6000.20895_none_8c1d577eb7f137c2.manifest x86_81a783d915bb6f248faec54858397f60_31bf3856ad364e35_6.0.6000.20895_none_8c1d577eb7f137c2
(f) CSI Manifest Failed Catalog Check 0x00000000 winsxs\Manifests\x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a.manifest x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a
(f) CSI Manifest Failed Catalog Check 0x00000000 winsxs\Manifests\x86_microsoft-windows-w..owsupdateclient-aux_31bf3856ad364e35_7.0.6000.381_none_7e2e53603f89ed2f.manifest x86_microsoft-windows-w..owsupdateclient-aux_31bf3856ad364e35_7.0.6000.381_none_7e2e53603f89ed2f
(f) CSI Manifest Failed Catalog Check 0x00000000 winsxs\Manifests\x86_microsoft-windows-n..xcorecomp.resources_31bf3856ad364e35_6.0.6001.18145_nl-nl_bc686b561b745721.manifest x86_microsoft-windows-n..xcorecomp.resources_31bf3856ad364e35_6.0.6001.18145_nl-nl_bc686b561b745721
(f) CSI Manifest Failed Catalog Check 0x00000000 winsxs\Manifests\x86_microsoft-windows-ieframe_31bf3856ad364e35_6.0.6000.21184_none_62f32a60ca5387bd.manifest x86_microsoft-windows-ieframe_31bf3856ad364e35_6.0.6000.21184_none_62f32a60ca5387bd
Summary:
Seconds executed: 5794
Found 5 errors
CSI Manifest Failed Catalog Check Total count: 5
Unavailable repair files:
winsxs\manifests\x86_81a783d915bb6f248faec54858397f60_31bf3856ad364e35_6.0.6000.20895_none_8c1d577eb7f137c2.manifest
winsxs\manifests\x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a.manifest
winsxs\manifests\x86_microsoft-windows-w..owsupdateclient-aux_31bf3856ad364e35_7.0.6000.381_none_7e2e53603f89ed2f.manifest
winsxs\manifests\x86_microsoft-windows-n..xcorecomp.resources_31bf3856ad364e35_6.0.6001.18145_nl-nl_bc686b561b745721.manifest
winsxs\manifests\x86_microsoft-windows-ieframe_31bf3856ad364e35_6.0.6000.21184_none_62f32a60ca5387bd.manifestFor demonstration purposes, I'll be tracing the origin of the following manifest:
C:\Windows\WinSxS\manifests\x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a.manifest
Looking at the file name, anyone's guess is as good as mine for which update this originated from. Sometimes a simple Google search will tell you, but you might have to trace it manually through the registry. Here's how to do so:
Firstly, open regedit and click on HKEY_LOCAL_MACHINE (I may abbreviate it to HKLM later in this tutorial)
1. By default the COMPONENTS sub-hive isn't loaded. There are ways of forcing it to load when Windows boots, but that's for another day. Click on File > Load Hive... to load another hive.
The COMPONENTS sub-hive is located in %WinDir%\system32\config\COMPONENTS. It has no file extension.
2. Navigate to the above directory and open the file called COMPONENTS.
3. It will prompt you for a name, call it COMPONENTS (I used BasW Components because that's the username of the person I was helping; it made it easier to identify the hive as his).
You should now see it in the left panel.
4. Navigate to HKLM\{Components sub-hive name}\DerivedData\Components then click Edit > Find.
It is crucial that, when searching, you remove the .manifest suffix from the name as the registry keys are just the file name without the extension. Searching for the whole string won't return any results unless you remove the extension from the end. So we are searching for:
x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a
Here are the values for the key that we have found.
5. One of the values will have a name containing the string: 31bf3856ad364e35. If anyone is interested, this is known as a public key - for more information on this, see here
We need the whole string for our next search.
6. Double click on the string that we want to bring up the Edit Binary Value dialog box.
Do not change anything in this menu.
7. Double click on the box titled Value name to select all of the text, then right click and select Copy.
8. Paste this text elsewhere (I would recommend a Notepad window) so that we don't lose it. Here is our string:
db01a593eda..9667a5d431d_31bf3856ad364e35_6.0.6000.21148_710df82209087a42
Don't be alarmed if the first few characters don't copy, this is perfectly normal.
You can now close the Edit Binary Value box.
9. Now we have the string, we will need to find it's corresponding key in CanonicalData. Navigate to the key:
HKEY_LOCAL_MACHINE\{Components sub-hive name}\CanonicalData\Catalogs
10. Then click Edit > Find and search for our string:
db01a593eda..9667a5d431d_31bf3856ad364e35_6.0.6000.21148_710df82209087a42
Our search should find a value named the string that we searched for.
10. We are interested in the name of the key, as we will use it for our next search. To make this text available for copying, right click on the key and select rename. Do so with extreme caution; do not, in any circumstances, rename this key.
11. Right click on the text and select Copy. Then click elsewhere to deselect the text and revoke the ability to rename the key. Paste this string in a Notepad window so that we don't lose it. We will be using this for the next search. Here is our string:
6be66ee4ca8f2a3872499f601565c01501d83f123af5519e5d9be6d505abae16
12. Now navigate to the following key:
HKEY_LOCAL_MACHINE\{Components sub-hive name}\CanonicalData\Deployments
And, once again, click Edit > Find. This time, we will be searching for the string that we just found:
6be66ee4ca8f2a3872499f601565c01501d83f123af5519e5d9be6d505abae16
13. This search should find a key with the same name, but it is in the CanonicalData\Deployments key. This key will have several values inside it. One of the values will be called CatalogThumbprint and its data will be the string that we just searched for. You should see a KB article number in the name of another one of the values. This is the number of the update that this manifest came from.
CBS_package_10_for_kb976325~31bf3856ad364e35~x86~~6.0.1.0.976325_13c20f60bc4ede2f
So, in conclusion, we have found that the manifest
x86_microsoft-windows-ie-htmlactivexcompat_31bf3856ad364e35_6.0.6000.21148_none_15ef6be02bd9d67a.manifest comes from KB976325.
To find the web page of a KB article, just go to:
http://support.microsoft.com/kb/{KB article number}
In this case, the page would be MS09-072: Cumulative security update for Internet Explorer
This leads me to the download location: Download: Cumulative Security Update for Internet Explorer 8 in Windows 7 (KB976325) - Microsoft Download Center - Download Details
This link allows us to download the update which we can then extract the files from
If anyone has any questions then feel free to ask!
Tom
Last edited:
- so not for the faint-hearted - but it does cut down the hassle for 90% of CheckSUR errors - and a similar number of SFC errors.
