I was asked recently to look at a couple of support cases that had been logged where installations of our Application Manager and Performance Manager products were failing. The logs from the failed installations, obtained from invoking msiexec with the /l*vx syntax, gave the following error:
(Error code 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)
A web search for the error gave many matches which didn’t really help so I then tried to reproduce the error in a Windows Server 2003 x86 virtual machine but the installation worked fine, as it usually does. Analysis of the msiexec log from the failing system indicated that the error was occurring when installing our signed device drivers. So next I ran the great Process Monitor tool from SysInternals, now Microsoft, to try and understand what was happening, file system and registry wise, during the installation, particularly around the area where the msiexec process installs the device drivers.
What this showed me was immediately before our driver catalog (.cat) file was read, the “State” registry value in the following key was being read:
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
Given the error text from the failed installation, this looked relevant. A quick web search threw up a number of interesting articles, namely:
which led me to try changing the “state” value in the registry in my test VM from 0x23c00 to 0x40000 (WTPF_ALLOWONLYPERTRUST as per the MSDN link above and the wintrust.h header file so effectively much more restrictive than what was in this value by default).
Retrying the previously successful installation in my test VM then gave exactly the same error that our customers had been experiencing. On passing this information on, both customers confirmed that their “state” registry values were either not as per the default or were missing, due to the parent key being absent, and that setting the “state” value to the default allowed the drivers to be successfully installed.
Case(s) solved! But this leaves me with the desire to know what caused this to happen, particularly as we have had two cases from different customers logged so closely together, given that I stopped believing in coincidences many years ago. This is the main reason for me blogging about this issue – I hope that by the power of search engine indexing that if others suffer this issue then they will be brought here and their problem solved.
10th Feb 2010