Driver digital signature error

[aboryczko]

The drivers code signing certificate has expired

[duncanthrax]

No, it should be good. 8 April 2018 is the signing date, not the expiry date. Click "View Certificate" to see the expiration date. Should be 5th July 2020.

[aboryczko]

yes you're right, I've jumped to conclusions to fast because the driver is giving me the following error in Device Manager: Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)

[duncanthrax]

Which Windows version is this? It could be that it can't handle SHA-2 signatures. I googled and came up with this (different driver, similar problem): https://kb.hilscher.com/display/CIFXDRV/Device+Manager+error+%28Code+52%29+with+cifx+Driver+V1.3.0.0+or+above

[aboryczko]

it's Windows 10 1709 (10.0.16299.371)

[aboryczko]

I did some digging and it looks like a policy issue in newer Windows 10 editions as described here: https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/ basically the driver would have to be cross-signed by Microsoft

[duncanthrax]

Thanks, that makes sense. All the Windows installations I've tested on have been upgraded from Windows 7, so the new policy does not apply. It looks like there's a fuck-ton of red tape involved to pass the new policy, I'll probably need a new cert and sign up to a lot of Microsoft services. Very depressing. I'll see what I can do.

[duncanthrax]

One more question: On that system, is secure boot enabled? If yes, does it help to disable it?

[aboryczko]

Yes, Secure Boot is enabled but I don't want to disable it. I've managed to install a previous version of the driver with changing the clock back one year.

[duncanthrax]

Looks like there's no way to avoid buying an EV cert that would cost me ~1kUSD per year. I don't really feel like that. For the time being, I'll add a note to the README, so that people can turn off secure boot.

[LeonardoCurvelo]

I'm using Windows 7 and the driver wouldn't work, the SHA-2 Windows Update fixed it.

I have been using scream for two weeks now, having my Raspberry Pi as my audio output without any flaw whatsoever. I can't put into words how much this means to me, I've spent over 8 years searching and searching and trying different things to try to have audio sent over network from Windows with no delay and nothing would ever come close... Thank you soooo much!

But that's also why it pains me so much to see it behind this awful wall put up by Micro$oft... This serves nothing but to demotivate brilliant people like you.

[duncanthrax]

Hi Leonardo, you're welcome :)

[Teteros]

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal.

It seems recent Windows 10 users will need to boot with TESTSIGNING ON to make trivial changes like https://github.com/duncanthrax/scream/issues/14.

devcon fails installing the driver unless Windows is in test mode or the developer signed the release with a real EV cert, or the older cross-signed cert (non-EV with secure boot off only)

[masseman]

Looks like there's no way to avoid buying an EV cert that would cost me ~1kUSD per year. I don't really feel like that.

Any chance you could join forces with the creator of Virtual Audio Cable (https://vac.muzychenko.net/en/) to have your driver signed with his certificate?

[duncanthrax]

Thanks for the suggestion, the topic came up again in another issue ... I'll contact the VAC author, but AFAIK the Dev Center signing requires submitting the driver to MS, along with documentation, test reports etc. Not sure if that is possible by proxy.

[afparsons]

This project looks really interesting (great work!) and I am wanting to try it out on a new laptop (arriving today!). I expect the laptop to arrive with Windows 10 Version 1903.

I plan to reinstall Windows immediately. Am I reading this correctly, @duncanthrax?

Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal.

PCs upgrading from a release of Windows prior to Windows 10 Version 1607 will still permit installation of cross-signed drivers.

Could I install Windows 10 Version 1511, install scream, and then update to 1903? Would that work?

The only caveats I can think of:

• the activation key is tied to a minimum version of Windows 10 (ex: 1903) (is it? I don't know)
• perhaps it is superstitious...but my experience with MS tells me that this would introduce "code bloat" for lack of a better term
• ???

I've managed to install a previous version of the driver with changing the clock back one year.

Część, @aboryczko : does this have any negative repercussions? Can I change the date back to the correct year once installed?

(forgive me if I'm totally off—I'm a Linux user, mostly. No activation keys or stupid versioning 😃 ).

[RolandLeFranc]

I was able to install it on a Windows 10 1909 PC today without any issues.

[afparsons]

I was able to install it on a Windows 10 1909 PC today without any issues.

@RolandLeFranc Did you install on a machine that had a been first installed with an older (pre-1607) version of Windows?

[afparsons]

@duncanthrax I googled around some more last night and came across a few good resources.

• https://www.geoffchappell.com/notes/security/whqlsettings/index.htm
• https://forums.mydigitallife.net/threads/windows-10-anniversary-update-digital-signature-question.69970/#post-1272392

Both the blogpost and the forum post corroborate each other. I subsequently added the following registry value on a Windows 10 1909 machine (the same I described back in December 2019; I installed a fresh copy of Windows 10 at the time, so probably version 1903).

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy]
"UpgradedSystem"=dword:00000001

Lo and behold...it worked. Previously, the driver had installed itself and appeared in the Device Manager, albeit with the oft-described "Code 52" warning. Now that error is gone and I can select the Scream audio device as described in the README.md.

Like I wrote before, I'm really not a Windows guru. My previous (naïve) experiences have shown me that modifying the registry can lead to issues, so I don't really know what sort of externalities will follow from adding this registry key. I'll defer instead to Geoff Chappell's blogpost, as he seems to know what he's writing about; it seems like adding this registry value is, at least to date, harmless.

I'm going to append this information to the README.md and submit a pull request.

[lixaotec]

what about windows server 2019? certificate Code 52 still.. latest version

[Tomvkgames]

Is it possible to cross sign kernel drivers in windows 11? For me "UpgradedSystem"=dword:00000001 does not work.

[Dr-Shadow]

For anyone wondering, it doesn't seem that code signing would happen since EV code signing certificates still cost > 300$/year

I can confirm the regedit fix still works under Windows 11 22H2 (just restart the computer once you made the regedit fix)

[k8wu]

I run a Microsoft Surface Pro X with a Microsoft SQ2 (ARM64) processor. OS details:

Edition Windows 11 Pro Version 22H2 Installed on ‎9/‎27/‎2022 OS build 22621.1413 Serial number 003054203353 Experience Windows Feature Experience Pack 1000.22639.1000.0

The ARM64 version of this driver does not install. The batch file, when run as administrator, tells me that devcon-arm64 failed:

Attempting to install this driver directly results in the driver signing error that others have noted in the comments above. Adding the registry key noted earlier does not work, even after rebooting.

I do get a slightly different error message after disabling Secure Boot and attempting to install the driver again (by directly installing the driver by right-clicking on the .inf file and clicking Install):

Has anyone seen this yet? I'm here because Virtual Audio Cable and VB-Audio do not support this platform, and apparently have no plans to do so.

[ZaDarkSide]

You can follow these steps to install:

1. Run Cmd as Administrator Bcdedit.exe -set TESTSIGNING ON
2. Reboot
3. Install Driver by running as Administrator Install-x64.bat from Scream4.0.zip downloaded from Releases
4. Run Cmd as Administrator Bcdedit.exe -set TESTSIGNING OFF
5. Reboot

[ryedunn]

Confirmed the fix from @ZaDarkSide works