-
Notifications
You must be signed in to change notification settings - Fork 538
Scp Virtual Bus Driver not signed on Windows 10 x64 build 14316 #266
Comments
Can you try a manual removal and then reinstall? |
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? |
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 File Name: \Device\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys |
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... |
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... |
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. |
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. |
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. |
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. |
@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. |
I do have Secure Boot enabled on my laptop, and never got this issue. 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. |
When Secure Boot is enabled, instead of event 3085 (see earlier reply), event 3084 appears in the Microsoft-Windows-CodeIntegrity/Operational log: 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): 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 Signing Certificate Chain:
The signature is timestamped: Sun Mar 27 12:52:20 2016
Successfully verified: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys Number of files successfully Verified: 1 |
Updated to build 14328 today - same problem with the driver when Secure Boot is enabled, unfortunately. |
@psyke83 Try running this in a admin command prompt: This should disable driver signature enforcement, and the driver should work with Secure Boot active. |
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. |
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. |
It's my turn to get hit by the bug: 64-bits Windows 10 build 14366 plz fix soon @nefarius |
@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/ |
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 😞 |
Won't that not work, since the driver is still cross-signed? |
I'm having exactly the same problem. Disabling secure boot also fixes the issue for me. |
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. |
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. |
I too have this problem, it only works after disabling driver signature enforcement. |
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. |
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 |
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. |
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.
|
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.) |
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. |
Sorry for replying to a closed issue, but the version v1.6.238.16010 solved it for me. That's all. ^.^ |
@alpharou because it uses an older, buggy build of the ScpVBus not built nor signed by me. |
if u all manged t install the driver as i did, but don |
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.
The text was updated successfully, but these errors were encountered: