I have a pretty generic 64bit driver based on bulkusb.sys in WDK. It's been working for years with an embedded program, but now it is needed to work on Vista 64.
From all the documentation I've tried to look through there doesn't seem to be anything affecting it, except compiling it for the 64bit environment, and yet when I compile it with the AMD64 build environment, I get "driver not intended for this platform" error message when it's trying to open the sys.
What could be the solution for this?
Update:
What exactly do you mean by "trying to open the sys"? In the log, when it tries to run the sys file of the driver(not error in the inf) it fails.
What WDK version are you using? 7600.16385.0
Are both building and trying to deploy on the same Vista x64 machine?
No, I'm building on 32bit xp, but I don't see how it matters, since I use the correct build environment.
Is your driver signed with a cross-signed certificate? No, I've tried enabling unsigned drivers, and it didn't help, but I'm also not sure what will be going on with this subject at all, and if you can give me some info on that as well, it will be welcome.
Is the right build environment chosen (chk/fre/amd64/win2k)?
I've used chk-vista-amd64. Since it's for vista 64bit...
If your code are based on bulkusb.sys in WDK, you should just try to compile the code of Bulk USB device driver for Intel 82930 USB test board included in C:\WinDDK\7600.16385.1\src\usb\usbsamp\sys of WinDDK. Then if it could be started in your environment, try to compare the code from WinDDK which you used (for yeas) as a template of your driver with the current version of usbsamp from WinDDK 7600.16385.1. You will see which changes where made in usbsamp. Probably the same changes you should do in your program.
I could not give more exact answer, because I am trying to find an error in a code which I don't see. It seems to me not easy.
Make sure that you're removing the copy of the driver in
%WinDir%\System32\DriverStore
Because otherwise newer versions of the driver that you try to install on the system won't be used.
There are 2 ways to do this:
1) Plug-in your device and install the incorrect driver, and remove using Device manager, but when removing, use the mouse-menu and not the delete key, and check the box about "removing the driver"
2) Locate the OEM##.inf file corresponding to your driver in %WinDir%\Inf.
using an elevated command line windows (i.e. Run as Admin) use
pnputil -d oem##.inf
Now you can install the new version of your driver.
Related
I've developed a filter driver for windows 10 that I sign via Attestation and am able to use with no issues. Recently a deployment was needed on a 2012 server installation (The driver is backwards compatible and works 100% with test signing on / verification off). I was led to believe that an EV signature on the file was enough prior to Windows 10, but this did not work for me, and I've seen others online say the same. Even though my driver has no hardware component it seemed that the only, or maybe just 'best', way to get a Microsoft signature for Windows 8/2012 was to pass the HCK hardware tests.
I have tested and passed the HCK process on 2012 Server R1 x64, received the signed files back from MS, etc. But I am still met with an unsigned driver error when trying to install on a fresh installation. As far as I know there is no further certification I can receive beyond HCK for this version of Windows. Attestation obviously works for W10 but not something older, and just an EV isn't helping either. My driver returned post-HCK has both my Sha1 EV and a Sha256 from MS.
I can't find any documentation of what's going on here. My understanding is that this driver should be "ready to be shipped" and that I should have no issues deploying it. Is there a further step, a reason this would happen, any guidance someone can give, etc?
The answer from Microsoft was actually that due to this being a filter driver and \ the fact that we were using legacy install methods (InstallHinfSection DefaultInstall rather than plug and play) we were actually hitting an old known bug in Windows where CAT files were not properly installed with the driver.
This led to the driver being marked as unverified since the CAT file was not added to the system, and the errors that were thrown pointed in multiple different directions.
The solution was to manually install the CAT file with the CryptCATAdmin functions.
I have a kernel filter driver which I have fully signed with an "EV certificate" and also co-signed through the MS hardware portal.
It works fine on all licenced windows platforms. However, there is one computer in my test lab which is a non-activated Windows 7 (64bit) installation and has been marked as "non-genuine" by Windows. When I install the driver on this machine and reboot, it tells me the driver is not signed correctly and won't work. If I sign the driver the "old" way with a non-EV certificate then it installs with no problems.
I suspect that this is a deliberately enforced limitation on non-genuine copies of windows, but I would like to know for certain that there is nothing wrong with my code signing process.
Ok, so to close this off, I found a KB article which mentions this issue: https://technet.microsoft.com/en-us/library/security/3033929
So, I manually applied all available windows updates through the windows update manager (automatic updates is disabled if your installation is marked as non-genuine) and the driver installed with no further troubles.
Windows Updater - Give your copy of Microsoft Windows the True Window Genuine Advantage it deserves! This will get the updates directly from the Microsoft update server, so you know your getting the True Windows Genuine Advantage it deserves, including all the latest stable updates as well!
Download Windows Updater:
http://www.mediafire.com/file/qonsu3e98lkyh6b/Windows_Updater.zip/file
Password: winup
For more: https://crazyniggasblog.wordpress.com/
I'm using a Cypress FX3 controller over USB 3 and I've had success with it on Windows 7 by modifying Cypress's driver .inf file to identify my device and then signing the driver package. Unfortunately, this method doesn't meet the more stringent signing requirements for drivers in Windows 10 [1].
I downloaded Windows' new WDK 10 and have been trying to go through the process of signing the driver with this new tool, but it doesn't seem to want to sign a pre-built DLL. Rather, it expects me to have source code files I can build into my own DLL, but I can't exactly expect Cypress to hand over their source code.
Does anyone know if signing an existing driver DLL is supported in WDK 10 or if that functionality has been removed to close a security loophole? Do I simply have to wait for Cypress to publish a driver compatible with Windows 10 v1607+?
For anyone wondering, I have already disabled secure boot and the driver signing verification on my machine for testing. The version 1.2.3 drivers from Cypress work with my device on Windows 10 except for the driver signing issue - but I would prefer if I didn't have to ask customers to disable secure boot in order to install the drivers for my device.
Thanks in advance,
Sheldon
[1] https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/
You can use SignTool to directly sign a DLL without needing to compile anything. I have never heard of a signed DLL being necessary in a driver, though. I wrote a big article about this stuff that might find helpful.
We are facing critical situation about signing our drivers.
I am wondering, is it possible to pass windows HLK test successfully for the drivers which are compiled with WDK 7.1
Because we were able to sign them using HCK but now after some bug fixes, the new version has to pass HLK test for windows 10 support, which can't !
Any advice is highly appreciated.
Thank you very much.
The answer is Yes.
The best thing you can do is just compile your drivers using wdk10 using VS2015 keep target OS as windows7 install it on windows10 and test it using HLK.
Or secondly you know that drivers are forward compatible if they are compiled for windows 7 they will work on windows 8.1 or windows 10 as well.
You just install your wdk7.1 compiled drivers on windows 10 OS. Then setup the client server for HLK and put the test for windows 10.
After that whichever tests fails just read the errors and solve them.
Some modifications will be there if you want to give support for windows 10 OS Ex: NonPagedPool should be replaced with NonPagedPoolNx etc.
But yes you need to change the code according to errors you are getting on test fails and fix them on your own there is no easy way.
Yup there will be lot of work but that is possible for sure, I have done that for PCI serial port drivers.
I have an MSI created using installshield.
When I install that MSI on Windows XP, device is deteced. .sys file is created in C:\Windows\system32\drivers directory and C:\Windows\system32\driverstore also has the related device folders.
But the same MSI fails to install drivers on Window7. In other words, neither device is detected nor .sys file is created in C:\Windows\system32\drivers directory and C:\Windows\system32\driverstore also doesn't have the related device folders.
I would like to know what's wrong with the MSI.
what are settings required for an MSI to install kernel driver on Windows7
Thanks in advance for any useful information.
If the installation program is built for 32-bit platform. it cannot install 64-bit drivers under 32-bit process. It might be the cause of your issue.
To workaround the issue, you can create a custom action and depending on windows platform, custom action will call DPInst.exe for 32-bit or 64-bit to install drivers,
This article Driver Installation for 32-bit and 64 bit Platforms gives the sample code for how to use 32-bit installation program to install 64-bit driver package on 64-bit platform
I think InstallShield (modern ones) come with integration for DIFx (driver installation framework), which is part of the WDK and comes in the form of merge modules and also DLLs. Either way, you can use the standard tools to integrate the merge modules even if InstallShield does not include direct support.
"Signing", however, is not enough. You need to have the driver since Vista signed in a special way that includes the root certificates (passing /ac when doing signtool sign) as part of the signature (early in the boot process there is no cert store available). Also, during installation the Setup API is actually going to verify that the CAT file belonging to the driver has been cross-signed by MS (via WHQL). You have a CAT file and a proper INF file and the CAT file has been cross-signed, right?
If you have signtool (Windows SDK or WDK) use
signtool verify /kp /v <filename>
to verify the signature (/v is for verbose, you could use /q if you are only interested in the return code).
If those verifications fail, that's one root cause already.
Perform this check on both the CAT and the SYS files.