load drivers error 577 with 3.1.14 but not with 3.1.11

[michel]

Since years I'm able to load my drivers in any version of Windows.
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?

Thanks

Michel

[madshi]

I'm not really a big expert on signing problems. That said, it's very confusing that you report different results with 3.1.11 vs 3.1.14. Are you 100% sure that the madCodeHook version makes a difference? I find that pretty hard to believe, to be honest.

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.

[michel]

Me too I don't understand and as I always install the last madCodeHook available build, sign my drivers (and applications) with the same batch file and use the same signtool since my first usage of the library, I first suspected the missing of some certificates in clean Windows 10 versus Windows7 updated to Windows 10; but adding some certificates of my dev machine didn't solve the issue.

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!

[madshi]

Does your clean Windows 10 machine have SecureBoot enabled?

[michel]

Yes, my clean machine is a UEFI one with SecureBoot enabled.

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?

[madshi]

Of course. SecureBoot in Windows 10 requires drivers to be signed with an EV certificate. More information e.g. here:

viewtopic.php?f=7&t=28340

[michel]

Yes I agree but:
- 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.

[madshi]

No, Windows 10 has a grace period for allowing drivers which were signed before a certain date to still be "acceptable", that's all.

[michel]

The grace period I found on the net is 90 days, but my drivers which load were signed 30/05/2016!
Did you know the 'grace period'?

[iconic]

That date was supposed to be January 1, 2016. Any of my drivers signed with Timestamps before that date using SHA-1 still load fine. Microsoft wasn't very clear about the whole SHA-1 phaseout and spoke rather vaguely and cryptically about what will continue to work and for how long

--Iconic

[madshi]

I don't know the exact way the grace period works, I've also seen conflicting information about it.

@michel, if you want to double check, try signing those drivers from 26/10/2014 today. I'm pretty sure they won't load.

[michel]

I'll try when I'll have some spare time and let you know the results.