How to fix “The update is not applicable to your computer” error.

How to fix “The update is not applicable to your computer” error.

It’s not often one will have this issue with an update, and it’s not easy to find a solution.
Because of that, I’ll share one example of how to do it and hopefully you can extrapolate this method to your case.


You need to install a single patch, out of your regular patch cycle. Maybe it is to enable some functionality (my case). Maybe it is some hotfix specific to your case.
You download the patch, run it and then …
… What do you mean is not applicable. It’s not in any list of existing patches …
And here is when this method might just come in very handy.

Step 1 – Logs

The first step has to be the logs.
Patching logs in Windows are kept in %systemroot%\Logs\CBS\CBS.log.
Open the log file and search for the KB number of your patch.
You can use any text editor you like. I like notepad++
Having found the KB reference, one can follow it to understand what is happening in the background.
As a little side note, more often than not, a patch is composed of multiple components and each one is tested for applicability
In this case, the first component was already marked as Superseded, as you can see highlighted. It might not always be the case, but it is here.
As we scroll through the log file we will see a sequence of log events going from the component to be updated until the evaluation of applicability and the result of Superseded. (Image below)
Note the component name and versions. The first version, ending in 23444 is the version we are trying to install of that component. The second version number is the existing lower version holder. That is to say, the current version of the component lower than the one we are trying to install.
At this point the log file will not help much more, so …

Step 2 – The source of all knowledge. The Windows Registry.

Disclamer: As usual, changes done to the registry can damage the Windows installation. Use some form of backup before starting and be very careful while navigating the registry
That’s right. If it’s not in the registry, Windows does not know about it. Or something of the sort.
At this point we open the registry editor (as Administrator) and we start digging.
The first piece of the puzzle is to search for the component we found in the CBS.log. In this example amd64_netfx-system_b03f5f7f11d50a3a.
The find function in the registry editor will lead you to something like the image below.
You can see the component selected, but we’re not there yet.
Scroll down and find the latest version of that component.
Now that we’ve found the latest version for this component, note the termination from arrow 1. .23744. And not the termination of the one before, pointed with the arrow 2. .23369.
What this means is that we have one version of this component higher than the one we are trying to install, and, at least in this case higher that the one the update we’re trying to install needs.
At some point, a patch was installed with the higher version and now, it’s up to us to find out which one.
So let’s jump onto the right hand pane and select the first binary key. The one that looks like a long GUID.
We need that value name to continue digging. So let’s modify and double click the value name to select it and copy it.

Step 3 – Digging deeper

Having copied the value name, we need to search for it in HKLM\COMPONENTS\CanonicalData\Catalogs (where Windows stores it’s component catalog).
Registry should find the value name inside a key, without any additional information, however, the key will help us get to the solution, because that key is present in yet another catalog.
So let’s select the key on the left pane. Right click and Rename, just so we can copy it.
Note: Don’t use the Copy Key Name functionality. For some reason beyond my understanding it does not work for the next search.
Once again, having copied the key name, we need to find it, this time under HKLM\COMPONENTS\CanonicalData\Deployments.
Once the search is done, we are presented with a list of packages and their KB numbers.
These packages have updated the component and will need to be uninstalled, in order to install the desired package.

Step 4 – Uninstall the superseding packaged

The next step is the easy one. Uninstall the 2 packages identified. Reboot if needed and then install our original patch.
And we’re done, or are we …

Step 5 – Back to the top

At this point, one would think we could just install the original patch and that was the end of it, but …
You see, Windows Registry was created in a time where efficiency was very needed. Windows registry allows application to share DLL’s rather than keeping multiple copies wasting space. It also keeps it’s catalogs so that application can know if they need to install new DLL’s or if they already exist, and as a consequence of that, Windows Registry also keeps records of what patches are installed or were attempted to install and what was the result. that way, it will not need to validate the applicability of a patch twice, because it already knows the result. It’s all about efficiency.
And so we go back to the CBS.log and find out patch number.
Select the highlighted Package_for_KB<insert your KB number here> and back to the registry editor.
Once in the registry edit (as Administrator), search for the above string and delete it.
This is the only registry change in the whole process and it is safe to do as it is only the record for the applicability evaluation.
This will make Windows evaluate your patch installation again and hopefully allow it’s installation.


There you have it folks. The not so easy fix, but very valuable in machines you can’t just rebuild (also a lot faster once you know where to look).
Do note that other components in a patch might also be superseded and you might have to repeat this process a few times.
Hope this can help someone.


  1. This blog post was built from a real life example using Windows 2008 R2 machines.
  2. As much as I would like to take credit for the discovery of the process, I must admit that I’ve learned this from a wise colleague of mine, Robert de Tulio, that collated some scattered information on the web using his expert knowledge and then taught me the process.