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.
Related
I want to install some software on a pre-alpha XP build (codename Windows Whistler). However, 90% of the installers fail to run. I guess it is because of the kernel version, which I suppose is somewhere between 5.0 and 5.1 (as I remember even the software that should run under Windsows 2000 did not succeed to install).
How can I most correctly and efficiently change the values in registry so that I have a chance to test some software (I know there can be bugs because of missing features, I'm doing tests in the VM).
The same question about Windows XP x64 with kernel version 5.2 - where to change it so that basic software designed for Win XP x86 does install as it does on regular Win XP (or maybe there is some compatibility option in properties).
Thanks for your help.
UPD: Java Runtime Environment version 5 update xxx should work on Windows 2000 (and even on Windows 98 SE, I tested it). But it somehow refused to install on Whistler... Maybe they cut something important away during development to make builds faster to compile?
You can try Right Click on .exe -> Properties -> Compatibility -> Run this program in compatibilty mode for.. and then specify compatible versions of OS.
This driver (https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad) works only under MS Windows 10. Did anybody try to move it to early Windows(7 or 8.1)? WDK 10 supports those OS.
Unfortunately my attempts were fail.
Yes, It can be done but you need to exclude lots of features and code, since windows 7 or 8 may not supports new apis that are targeted for win 10.
If you are using Visual Studio simple workaround would be:
Go to property page > Driver setting > Set Target OS version to Winows 7 and Target platform to Dektop.
This will give you lots of error while compiling, now keep on removing code those can't be used targeted for win 7.
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.
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.
we have a small app that doing trivial stuff, no GUI.
we was using Linux, but the library/framework available for Linux is highly less than that for windows, it was such a pain to develop under Linux.
So we want to use windows, but windows is too big for the trivial app, is there any solution that i can use windows and not losing OS's lightweight?
any advices appreciated.
What kind of applications are you building?
1) some older versions of windows have less bloat, but you wouldn't want these running on public networks because they don't get security updates. Plus, the latest/greatest libraries may not run on them
2) If you're running command-line server utilities, you could try Windows 2008 Server Core, which is a console-only installation
3) You might want to try Wine or Mono to run your windows/.NET framework-based application.
You should try a "Windows PE" (sometimes also called "minint") installation (installation guide here), which is a trimmed-down version based on Windows XP or Vista.
This does not make sense, sorry. If you have a CLI program under Linux why shouldn't you be able to write on CLI program on Windows?