The last working build of my drivers, created with 3.1.11 signed with SHA 1 only, the drivers load fine in any version of Windows (Win10 from Win7, Win7, Win 8, fresh Win10, in Virtual machines or computers...).
Two new builds using 3.1.12 signed with SHA 1 and 3.1.14 double signed (SHA 1 then SHA 256) encounter error 577 in some cases:
- for Windows 10 updated from Windows 7 (that is without drivers signing enforcement) the drivers are loaded
- for Virtual windows 7 the drivers are not loaded (error 577) but are loaded when booting in 'Disable Driver Signature Enforcement'
- for fresh Win10 the drivers are not loaded (error 577) but are loaded when booting in 'Disable Driver Signature Enforcement'
REM: when I say Windows 10 updated from Windows 7 I mean Windows 10 1607 as I don't yet updated it to 1703.
Did you have any idea about this issue: 3.1.11 SHA 1 signed drivers load everywhere, 3.1.14 double signed drivers load only in 'Disable Driver Signature Enforcement'?
How to solve it?
Is it possible that you've also switched the signtool version, maybe? signtool is supposed to write a proper checksum into the PE header. And error 577 suggests that the PE checksum is not set correctly.
I confirm (I just verified and tested this) that build (done with the madCodeHook available at this date):
- in May 2016: loads the drivers on any versions of Windows
- in January 2017: doesn't load the drivers in clean Windows 10
- in June 2017 (with double signing and an updated signtool as the previous one doesn't support double signing): doesn't load the drivers in clean Windows 10
This issue is reported by a lot of users of our product, is reproduced in our main office and also on one of my computers.
I tested your distributed PrintMonitor on different machines:
- on my Win10 dev machine and some other ones it loads the drivers (no error message)
- on my clean Win10 machine the drivers are not loaded (pop up "error...", "loading driver failed") and, when the PrintMonitor is closed, are, as expected, not stopped ("error...", "stopping driver failed")
So your PrintMonitor driver behaves exactly as my drivers. They can't be loaded in clean windows 10!
After I disable it I tested these two configurations:
- the current one with PrintMonitor on a network shared directory: the driver is not loaded
- a new one with the directory copied on the machine desktop: the driver is loaded
If I enable SecureBoot and disable Driver Signature Enforcement the behavior is the same (loaded for local folder, not loaded for network folder).
Disabling the Driver Signature Enforcement on some machines is what I was doing to have my drivers loaded but I'm not sure that my company will ask a lot some of its customers to disable SecureBoot or disable Driver Signature Enforcement as nearly all of them are lambda user afraid by doing simple computer management task (I have a lot of them in my family).
Is there a mean to have drivers loaded in SecureBoot enabled and Driver Signature Enforcement enabled?
- the madCodeHook drivers version 26/10/2014 load fine in any Windows including Windows 10 with SecureBoot enabled and Driver Signature Enforcement enabled
- the madCodeHook drivers version 29/04/2016 don't load in Windows 10 with SecureBoot enabled and Driver Signature Enforcement enabled
- the madCodeHook drivers version 29/03/2017 single or double signed them too don't load on these machines
So they must be a difference between the 26/10/2014 drivers and the next versions.
Did you know the 'grace period'?
@michel, if you want to double check, try signing those drivers from 26/10/2014 today. I'm pretty sure they won't load.