Software Drivers unable to start : Returning error code 577 on embedded windows-7 system

Hi Team,

We are unable to get the drivers to work on win-7 embedded systems. We have observed the “Organisation cert” is pointing to Microsoft root CA, while the Microsoft cert is pointing to “Global Sign” (actual cert provider) . This issue started happening for all our drivers that are signed using the Microsoft portal from Oct-2021.

We have used EV certs and strictly followed the steps mentioned in https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release, but this hasn’t helped to fix the issue.

Talking to the certificate provider / Microsoft hasn’t helped much.

Can someone please help resolve this issue?

Regards,
Bindu K

What’s does setupapi.dev.log say?

Peter

Error 577 is ERROR_INVALID_IMAGE_HASH. That implies that a driver has been changed since its CAT file was created. Is this WES7 initial release, or is it SP1? The Microsoft Portal is using SHA-256 certs now, which the original Windows 7 release did not support.

" SHA-256 certs now, which the original Windows 7 release did not
support." - this is likely the problem and updating to that kb is
typically a horrible process unless there is a MSFT image for win7 with the
update applied.
Mark Roddy

Hi All,

  1. Win 7 embedded standard system has all the patches updated + KB3033929 has been applied. This has not helped to fix the issue.
  2. When trying to start our drivers, the event logger is logging the below log :

“Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.”

File Name: \Device\HarddiskVolume1\Windows\System32\drivers\RPDriver.sys

  1. The below are the logs from setupapi.dev.log :

[Unstage Driver Updates]
Section start 2021/11/21 03:07:24.826
cmd: C:\Windows\servicing\TrustedInstaller.exe
sto: Driver Update Context:
sto: Image State = Specialized
sto: Image Architecture = x86
sto: Transaction = None
sto: Driver Updates = 2
sto: Unstaging all driver updates.
sto: {Delete Driver Package: C:\Windows\System32\DriverStore\FileRepository\machine.inf_x86_neutral_14cf763c82bf1613\machine.inf} 03:07:25.107
sto: Deleting driver package from Driver Store:
sto: Driver Store = C:\Windows\System32\DriverStore (Online | 6.1.7601)
sto: Driver Package = C:\Windows\System32\DriverStore\FileRepository\machine.inf_x86_neutral_14cf763c82bf1613\machine.inf
sto: Flags = 0x00000001
idb: Unregistered driver store entry ‘machine.inf_x86_neutral_14cf763c82bf1613’.
sto: {Delete Directory: C:\Windows\System32\DriverStore\FileRepository\machine.inf_x86_neutral_14cf763c82bf1613} 03:07:25.123
sto: {Delete Directory: exit(0x00000000)} 03:07:25.154
sto: Deleted driver package from Driver Store. Time = 47 ms
sto: {Delete Driver Package: exit(0x00000000)} 03:07:25.154
sto: {Delete Driver Package: C:\Windows\System32\DriverStore\FileRepository\cpu.inf_x86_neutral_4456b836fa160825\cpu.inf} 03:07:25.201
sto: Deleting driver package from Driver Store:
sto: Driver Store = C:\Windows\System32\DriverStore (Online | 6.1.7601)
sto: Driver Package = C:\Windows\System32\DriverStore\FileRepository\cpu.inf_x86_neutral_4456b836fa160825\cpu.inf
sto: Flags = 0x00000001
idb: Unregistered driver store entry ‘cpu.inf_x86_neutral_4456b836fa160825’.
sto: {Delete Directory: C:\Windows\System32\DriverStore\FileRepository\cpu.inf_x86_neutral_4456b836fa160825} 03:07:25.216
sto: {Delete Directory: exit(0x00000000)} 03:07:25.232
sto: Deleted driver package from Driver Store. Time = 15 ms
sto: {Delete Driver Package: exit(0x00000000)} 03:07:25.232
<<< Section end 2021/11/21 03:07:25.232
<<< [Exit status: SUCCESS]

Hi Team,
Do we need to go through the HLK / HCK testing for the drivers from now on?
Our drivers should be compatible with earlier versions of windows including xp, vista, win-7, win-8, win-10, win-2003 server.

That section of setupapi.dev.log is not relevant. Is there nothing about YOUR device?

My hunch is that driver signing is not the issue here. The log says you’re running Windows 7 32-bit, which doesn’t do KMCS checking at all. If I were in wild brainstorm mode, I’d wonder if your installation medium were damaged in some way. What it’s saying is that the actual hash of the file doesn’t match the hash that’s stored in the CAT file. Either the SYS file or the CAT file has changed. We have, upon rare occasions, seen files with a sector of zeros in the middle because of some disk flaw or some unexpected power failure.