Scp Virtual Bus Driver not signed on Windows 10 x64 build 14316

[psyke83]

OS: Windows 10 x64 Build 14316
Release: v1.7.277.16103-BETA
Upgrade procedure: updated from v1.6.238.16010 using the procedure listed on releases page (ran cleanup utility before new driver installer).

Issue: Service fails to start due to dependency error. Checking device manager, Scp Virtual Bus Driver shows caution icon with the following status:

"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)"

Booting with driver signature enforcement disabled allows the driver/service to function as expected.

[sylveon]

Maybe that the Certum root CA is not in your certificate store. Can you check?
Also, did you approved the dialog box that should show up when installing the VBus? The one that looks like that:

[psyke83]

I would have definitely allowed installation, but I don't recall with 100% certainty seeing that dialog during installation. However, the certificate does appear to be installed, so it seems that I did. Here's all certificates related to Certum:

[sylveon]

Can you try a manual removal and then reinstall?

[psyke83]

I followed the manual removal steps precisely with no problems encountered (taking into account the libusbK -> WinUSB changes), uninstalled the package, then reinstalled the package and ran the driver installer. Unfortunately, no change.

Upon reinstallation/installing the VBus driver, I wasn't prompted to accept installing the VBus driver - but I probably did accept it on the first install, considering that the author's cert is listed in my Trusted Publishers.

I have a fallback Windows 8.1 x64 USB-bootable installation; I'll try to install the package there and see if I encounter the same problem on the older version of Windows.

Edit: the driver installs correctly with no signature issues on Windows 8.1 x64. Back on the troublesome Windows 10 install, clicking on the author's cert shows the certificate path (Certum Trusted Network CA -> Certum Code Signing CA SHA2) and says "This certificate is OK.". The certificate was issued recently, so I double-checked that my system time was set correctly. Anything else I can do to help diagnose the issue?

[psyke83]

I tried uninstalling and manually removing the author's certificate, and reinstalled. I was shown the Windows Security dialog box and made sure to click "Install" as well as leaving the checkmark to indicate that the software from the author is trusted. No change.

I checked C:\Windows\System32\drivers\ScpVBus.sys. The properties for the file show that the digital signature is OK

Here's the relevant event log:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 14/04/2016 16:24:46
Event ID: 5038
Task Category: System Integrity
Level: Information
Keywords: Audit Failure
User: N/A
Computer: satellite
Description:
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\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys
Event Xml:



5038
0
0
12290
0
0x8010000000000000

5182


Security
satellite



\Device\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys

[psyke83]

I've captured the relevant parts of setupapi.dev.log from Windows 8.1 (working) vs Windows 10 (not). Apart from timestamps, a quick diff doesn't show any obvious difference that would explain the problem...

vbus10.txt
vbus81.txt

[nefarius]

In none of my Test-Virtual-Machines ranging from Windows 7 to Windows 10 I had any problems with the signature. I'm downloading Windows 10 Client Insider Preview - Build 14295 English right now to see if I can somehow re-create this behavior.

Sadly there's like a million advice posts on Google related to mysterious driver signature issues so I'm kinda at a loss to what I should recommend you to do...

[psyke83]

Thanks, nefarius. Tomorrow I'll try installing this build (14316) in a VM to see if I can replicate the issue from a clean install state.

[nefarius]

I tested it on a clean installation of Windows 10 build 10586:

I whacked together a small demonstration video (excuse the crude quality, I'm currently testing a new screen capture software) where everything looks fine.

[sylveon]

No problems on build 14295:

[psyke83]

Thanks for testing. I installed the same build I'm running (14316) in a VM, and the driver works without any issue - so my installation must be corrupted somehow. I'll run some SFC/DISM repair operations or find a way to clear the driver store to see if that helps... otherwise I'll wait for the next Insider build and see if the upgrade solves the issue.

Will close the issue since it appears to be an issue on my end only.

[psyke83]

nefarius,

Actually, it looks like it may be an issue with your driver's signing after all. Please check Event Viewer -> Applications and Service Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.

In the Windows 10 VM I set up, the virtual hardware is configured in BIOS mode (VMWare Player default), so event id 3085 was shown: "Code Integrity will disable WHQL driver enforcement for this boot session. Settings %1.".

My actual installation is running in EFI Secure Boot mode, so this event id was not logged. Once I disabled Secure Boot, your driver started working correctly.

There must be something wrong with your driver, as the previous version of ScpVbus.sys signed by another author worked in Secure Boot mode. I suggest that you install the Windows SDK for Windows 10 and check your driver/catalog using the signtool.exe.

[nefarius]

@psyke83 weird, I do have the latest WDK installed and used it to sign, verification also seems fine:

But you do seem to be on the right track here; neither of my systems are running in SecureBoot, I'll investigate.

[sylveon]

I do have Secure Boot enabled on my laptop, and never got this issue.
Secure Boot only concerns the Windows EFI bootloader, kernel and critical system files.

If you try manually editing your Secure Boot database and reput the correct Microsoft public keys, it may do something. WARNING!!! I am not responsible for any damage done to your system by trying the following advice.

[psyke83]

When Secure Boot is enabled, instead of event 3085 (see earlier reply), event 3084 appears in the Microsoft-Windows-CodeIntegrity/Operational log:
"Code Integrity will enable WHQL driver enforcement for this boot session. Settings %1. Exemption %2."

This is followed by event 3004 in the same log (almost identical to the security audit failure logged as event 5038 in the Security log):
"Windows is unable to verify the image integrity of the file \Device\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys because file hash could not be found on the system. 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."

I've ran the obvious checks - chkdsk and SFC found no problems, so it's not a simple matter of a corrupted file.

If you enable Secure Boot, please make sure it's working properly. Make sure to restart Windows and not merely shut down before changing the EFI setting (as the hybrid startup feature will continue using the previous EFI configuration until you do a full restart). Once you've enabled it in the EFI settings, msinfo32 should show "Secure Boot State: On"). I suggest that you see if whether event id 3084 or 3085 is logged on your system afterwards.

By any chance, was the previous version of the driver a user-mode driver, but your version is now a kernel-mode driver? That may be what's causing the incompatibility - see: https://msdn.microsoft.com/library/windows/desktop/hh848062(v=vs.85).aspx

Regarding signtool, the output doesn't show anything wrong with your signature - not even a warning. I captured this output while Secure Boot was enabled and the installed driver was showing the code 52 error (on the slim chance that the running system configuration can somehow influence signtool's parsing of the result):

C:\Users\Conn>"C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe" verify /v /pa /c C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.cat C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys

Verifying: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys
File is signed in catalog: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.cat
Hash of file (sha1): AAF9C4AF0520AF2AFBDF79F70389CE7B443C5507

Signing Certificate Chain:
Issued to: Certum Trusted Network CA
Issued by: Certum Trusted Network CA
Expires: Mon Dec 31 13:07:37 2029
SHA1 hash: 07E032E020B72C3F192F0628A2593A19A70F069E

    Issued to: Certum Code Signing CA SHA2
    Issued by: Certum Trusted Network CA
    Expires:   Wed Jun 09 12:30:29 2027
    SHA1 hash: 905DE119F6A0118CFFBF8B69463EFE5BD0C1D322

        Issued to: Open Source Developer, Benjamin Hoglinger-Stelzer
        Issued by: Certum Code Signing CA SHA2
        Expires:   Sun Mar 12 18:12:30 2017
        SHA1 hash: 61197CF2F78F4B9107667B1FFE4FD7A313EDCF86

The signature is timestamped: Sun Mar 27 12:52:20 2016
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 00:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

    Issued to: Symantec Time Stamping Services CA - G2
    Issued by: Thawte Timestamping CA
    Expires:   Thu Dec 31 00:59:59 2020
    SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

        Issued to: Symantec Time Stamping Services Signer - G4
        Issued by: Symantec Time Stamping Services CA - G2
        Expires:   Wed Dec 30 00:59:59 2020
        SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

Successfully verified: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

[psyke83]

Updated to build 14328 today - same problem with the driver when Secure Boot is enabled, unfortunately.

[sylveon]

@psyke83 Try running this in a admin command prompt: bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS
DDISABLE is not a typo.

This should disable driver signature enforcement, and the driver should work with Secure Boot active.

[psyke83]

charlesmilette,

Thanks, but it's not necessary. I've already confirmed that the driver works fine from the equivalent one-time boot with signature enforcement disabled. I'll keep Secure Boot disabled until the issue is figured out.

You mentioned that you've got Secure Boot enabled, but what version of Windows are you using? I just double-checked my Windows 8.1 USB installation, and the driver definitely works fine with Secure Boot either on or off. Unfortunately, the CodeIntegrity log doesn't have any of the equivalent events related to driver enforcement as present in Windows 10.

It seems to be a problem unique to (at least certain versions of) Windows 10.

[sylveon]

I have Windows 10 build 14295 (That needs a reinstall, cause the guy who took care of my computer for problems f*cked it up more than anything else.)

If the driver won't work after a reinstall, I'll say it.

[sylveon]

It's my turn to get hit by the bug:

64-bits Windows 10 build 14366

plz fix soon @nefarius

[sylveon]

@nefarius This article might contain the cause of the problem: https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

[nefarius]

This is getting absurdly ridiculous 😠 But some good news; I'm in contact with a company to acquire a certificate from GlobalSign which should still work without this "send-to-M$" BS. Since I don't own a company I can't buy directly from them myself 😞

[sylveon]

Won't that not work, since the driver is still cross-signed?

[sclarke81]

I'm having exactly the same problem. Disabling secure boot also fixes the issue for me.

[meihkv]

The problem is that the drivers are not signed. If you do advanced startup and select option 7, "Disable Driver Signature Enforcement", the problem goes away, and there is no caution under SCP Virtual Bus Driver in Device manager. When you reset the computer and clear your special startup, it reverts back to the same issue.

[wishAI]

I had the exactly the same problem. It runs fine on my old pc with latest windows 10, but the driver is not signed on my new surface pro 4.

[Kvamms]

I too have this problem, it only works after disabling driver signature enforcement.

[alpharou]

Got a clean installation of Windows 10 Pro With the latest Creators Update, build 15063.332. The VirtualBus Driver signature could not be verified. Tried to install it with the advanced startup feature, disable Device signature verification and works absolutely fine. Rebooted, and problem persisted.

At the same time, I have a windows 10 Home PC in which I had absolutely no issues installing and running the service.

The differences between the two are that in the Pro version I have BitLocker Activated, and I am positive that I have Secure Boot enabled in both of them, with the Windows FastBoot feature.

Not a clue what could be happening, but it seems that this issue has been recurrent for the past months.

[sylveon]

Yeah the new signature requirements only applies to fresh installs since Windows 10 Anniversary Update.

Older installs use the old requirements in a effort not to break them because of unsigned drivers.

You can use bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS to disable that requirement

[alpharou]

I already tried that just after my first clean install. Did not work. Decided to reinstall again and do the startup disable device signature verification method.

But just to make sure, how can I revert that command in the event it doesn't make a difference? Gonna give it a try.

[sylveon]

Then you can probably enable test signing and use universal watermark disabler to remove the watermark. De : Alpharou Envoyé le :4 juin 2017 12:55 À : nefarius/ScpToolkit Cc : Charles Milette; Comment Objet :Re: [nefarius/ScpToolkit] Scp Virtual Bus Driver not signed onWindows 10 x64 build 14316 (#266) I already tried that just after my first clean install. Did not work. Decided to reinstall again and do the startup disable device signature verification method. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[alpharou]

The TESTSIGNING Value is protected by the SecureBoot Policy, such a breach in the system is not really a fix in the long term. I just want to know why does this happen, when my recently wiped Windows 10 Home computer doesn't have any issue? (When I reinstalled Windows in the machine where SCP works, It installed with the Anniversary Update already, so I don't know if that's the issue, both of them are clean windows installs.)

[psyke83]

The change is explained from the horse's mouth here: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

As to why a recently wiped install doesn't have the issue, I suppose it depends on how Microsoft implemented the check for a "clean" install to apply the new or old driver policy. Perhaps a "Refresh" or whatever it's called doesn't clobber the old driver policy OR you're using a pre-1607 build.

The only way as an end-user to continue using ScpToolkit is to disable test-signing or Secure Boot. I think nefarius has already submitted (and had accepted) his FireShock/Vigem drivers for verification, so that will work on Windows 10 with Safe Boot.

I'll close this issue since the issue is known and not really in the developer's direct control.

[alpharou]

Sorry for replying to a closed issue, but the version v1.6.238.16010 solved it for me. That's all. ^.^

[nefarius]

@alpharou because it uses an older, buggy build of the ScpVBus not built nor signed by me.

[handoman123]

if u all manged t install the driver as i did, but dont see the controller in devices in control panel, install kinoconsole, it adds a virtual xbox controller which u can keymap using UCR. And yes im using windows 10.