Can't install our driver on ARM-based systems

NTDEV
1

Our UMDF (2.25) virtual display driver fails to install on an ARM-based Windows 11 system. My understanding from Microsoft is that Kernel-mode drivers and printer drivers need to be compiled for ARM, but other drivers can run emulated (whether running emulated is a good idea for a display driver is another question).

Have you folks run into something like this with UMDF drivers on ARM systems?

Our production build process signs the driver with an Extended Validation (EV) Code Signing Certificate, but our local dev builds just use self-signing. I only just got my AMD hardware, so I'll be checking to see whether this only happens on self-signed builds or either one.

Outwardly, this looks a lot like an issue we were having with Windows 11 Preview Edition, where our EV-signed driver would fail validation during install. It only happened to users with Win 11 Preview Edition, and only to a small percentage of them. It was consistent for those who were affected, though.

Cheers,

--Scott

2

Can you elaborate on what you mean by failed to install? A lot snippet from %windir%\inf\setupapi.dev.log would be helpful as well

3

Here's the error:

             .
             .
             .
     sto:      {DRIVERSTORE IMPORT VALIDATE} 12:34:22.475
     sig:           Driver package catalog is valid.
     sig:           {_VERIFY_FILE_SIGNATURE} 12:34:22.493
     sig:                Key      = Immersed-display-driver.inf
     sig:                FilePath = C:\WINDOWS\System32\DriverStore\Temp\{23218fd0-74e9-2c4a-8fc8-df2ed2312d6a}\Immersed-display-driver.inf
     sig:                Catalog  = C:\WINDOWS\System32\DriverStore\Temp\{23218fd0-74e9-2c4a-8fc8-df2ed2312d6a}\Immersed-display-driver.cat
!    sig:                Verifying file against specific (valid) catalog failed.
!    sig:                Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
     sig:           {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 12:34:22.526
     sig:           {_VERIFY_FILE_SIGNATURE} 12:34:22.526
     sig:                Key      = Immersed-display-driver.inf
     sig:                FilePath = C:\WINDOWS\System32\DriverStore\Temp\{23218fd0-74e9-2c4a-8fc8-df2ed2312d6a}\Immersed-display-driver.inf
     sig:                Catalog  = C:\WINDOWS\System32\DriverStore\Temp\{23218fd0-74e9-2c4a-8fc8-df2ed2312d6a}\Immersed-display-driver.cat
!    sig:                Verifying file against specific Authenticode(tm) catalog failed.
!    sig:                Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
     sig:           {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 12:34:22.542
!!!  sig:           Driver package catalog file certificate does not belong to Trusted Root Certificates, and Code Integrity is enforced.
!!!  sig:           Driver package failed signature validation. Error = 0x800B0109
     sto:      {DRIVERSTORE IMPORT VALIDATE: exit(0x800b0109)} 12:34:22.542
!!!  sig:      Driver package failed signature verification. Error = 0x800B0109
!!!  sto:      Failed to import driver package into Driver Store. Error = 0x800B0109
     sto: {Stage Driver Package: exit(0x800b0109)} 12:34:22.542
<<<  Section end 2024/05/15 12:34:22.542
<<<  [Exit status: FAILURE(0x800b0109)]

Our app installer is an MSI created by a WiX 3.11 project in our solution. We're using difx:Driver to install our app along with the driver. This same .msi file installs everything without issues on an x64-based system.

4

Mmmmm... is this driver package signed by MSFT, or is it test-signed? Because, if it's test signed, then it looks like you haven't added the cert you used to sign the driver into the Trusted Root Certification Authority on the test machine.

1 Like
5

This was from me testing our official .msi (currently in production) on an ARM-based Windows 11 machine. Our build process signs the driver and msi with our EV code signing certificate from DigiCert.

The same was true back when we saw this issue (or a similar issue) with Windows 11 Preview Edition. It seemed like there was a missing intermediate cert on some user's machines, because at some point I saw a message or error code that said something to the effect that validation had failed due to an invalid or missing intermediate(?) cert in the chain of trust.

6

That is not enough to allow you to install a driver though, right? The EV Code Signing Certificate is required to allow you to submit the driver to MSFT for attestation (or Logo) signing. But, by itself, it's no different from an ordinary test-signing certificate: You need to put cert in the Trusted Root Certification Authorities cert store for the machine (btw, NOT the user).

7

Checking on this with our build guy...

8

From our build guy:

Yeah, we do that. This is the command we use to sync the DigiCert certificate into the Windows Store: Windows store and KSP commands

Apologies, this is a build detail that I wasn't aware of.