I just created a KMDF Sample driver using Visual Studio 2013 Express with WDK 8.1 on a Windows 7 (64 bit) computer. When I build the solution I get no errors. As I want to check later if my driver is running I inserted the common Debug-Line into my DriverEntry-Routine:
NTSTATUS DriverEntry(...)
{
DbgPrint("Test\n");
// ...
}
By the Windows Device Manager I can install the driver manually, by adding a legacy device. Of course Windows will complain about the fact that the driver is not signed. But anyway later I can see the installed driver in the device manager, preceeded by a warning symbol:
With DebugView (from Sysinternals Suite) I am waiting for my debug message to occur, but nothing happens. The only debug messages I get during driver installation is this:
[1768] WdfCoInstaller: [02/07/2018 12:43.22.162] DIF_INSTALLDEVICE: Pre-Processing
[1768] WdfCoInstaller: [02/07/2018 12:43.22.168] ReadComponents: WdfSection for Driver Service KMDFDriver1 using KMDF lib version Major 1, minor 11
[1768] WdfCoInstaller: [02/07/2018 12:43.22.177] DIF_INSTALLDEVICE: Coinstaller version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.185] DIF_INSTALLDEVICE: KMDF in-memory version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.188] DIF_INSTALLDEVICE: KMDF on-disk version: 1.11.0
[1768] WdfCoInstaller: [02/07/2018 12:43.22.191] Service Wdf01000 is running
[1768] WdfCoInstaller: [02/07/2018 12:43.22.194] DIF_INSTALLDEVICE: Update is not required. The on-disk KMDF version is newer than or same as the version of the coinstaller
[1768] WdfCoInstaller: [02/07/2018 12:43.22.305] DIF_INSTALLDEVICE: Post-Processing
So this leads me to the question why my driver is not running? I guess it has something to do with the signing of the driver, but I also don't know how to sign it. Or maybe DebugView is the wrong tool for this?
Use OSRLOADER to load your device driver for testing purposes. You also may need to perform some registry changes.
You can download OSRLOADER from here: https://www.osronline.com/article.cfm?article=157
Check this question's replies for insight on what to do next regarding DebugView and the registry: No output from DebugView
As for driver signing, go to project properties and choose the Driver Signing tab. You can set the certificate type for testing and then just create a random test certificate. The environment the driver will be tested on however will need to have Test Mode enabled, or be started up with DSE disabled for that session. You can find out more here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-to-test-sign-a-driver-package
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option
Everything is already documented, all you need to do is a simple Google and you'll have all the information. MSDN alone has quite a lot of content about getting into driver development, driver routine documentation, example source code, even videos sometimes.
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.
Since the DIFx Guidelines state that: "the Driver Install Frameworks (DIFx) tools were removed from the Windows 10 Version 1607 WDK" and the WiX Driver Element relies on the WixDifxAppExtension, is the use of the Driver Element still the way to go to install a driver? Or should I use the SetupAPI directly (e.g. as a DLL which is called in the MSI)?
A bit late but I just wanted to state that the WixDifxAppExtension works fine in 2022 on Windows 10.
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.