I've developed a kernel-mode driver for Windows 10. How should I properly sign it? I want my driver to be installable without enabling test-signed drivers installation after sign procedure.
Related
Microsoft Documentation is somewhat unclear about installing print drivers:
For example, apps that have a dependency on installing printer drivers into the host cannot be containerized because driver installation from within a container is unsupported.
I could not install a printer driver in a container, so I assume this quote also means that drivers cannot be installed in windows containers. Some of my confusion comes from the documentation saying that drivers cannot be installed into the host system--rather than container.
Without installing a driver, is it possible to print to postscript file with one of these preinstalled windows drivers?
Name PrinterEnvironment MajorVersion
---- ------------------ ------------
Microsoft XPS Document Writer v4 Windows x64 4
Microsoft Print To PDF Windows x64 4
Microsoft Shared Fax Driver Windows x64 3
Microsoft enhanced Point and Print compatibility driver Windows x64 3
Microsoft enhanced Point and Print compatibility driver Windows NT x86 3
Is it possible to add a network postscript printer and print to file from that printer?
I have tried installing HP Universal Print Driver, and I have tried using Rundll32 printui.dll,PrintUIEntry to install a driver. Neither worked nor had helpful error messages.
I'm trying to develop a simple Windows 10 app and I wanted to simulate a Pedometer for testing. How can I do that? And what about other type of sensors, can I simulate them too?
Ok I found a solution.
Microsoft provides sample drivers here and there you can find sensors folder. So download what you need, compile and deploy.
To compile you need Windows Driver Kit.
If you're deploying to a x64 machine the drivers has to be signed. I had trouble signing the drivers so I booted Windows 10 with no driver signature enforcement and deployed the driver using DevCon. Check the driver INF once compiled to see the installation instructions.
I have an issue while installing drivers for the ATMega 2560. I downloaded the drivers from the ATMEL website, no issues during installation, but once small window pops up it gives me an error that the drivers are not compatible with x64 operating systems, although a lot of my colleagues are using x64. If you need I can take a snip of the error message.
P.S. Forgot to mention I`m using x64 Windows 8.1, with the latest updates installed and Atmel Studio 6.2.1153
I had the same problem recently and many of the driver links on the Atmel and other sites are for old versions of the driver. If you install the Atmel Software Framework you'll find signed drivers in a location similar to the following:
C:\Program Files (x86)\Atmel\Atmel USB Drivers\inf\atmel_devices_cdc\atmel_devices_cdc.inf
C:\Program Files (x86)\Atmel\Atmel USB Drivers\inf\atmel_devices_cdc\atmelinf.cat
Supported Windows versions are listed as Windows 2000, XP, Vista, 7 and 8 (x32 and x64) and I've confirmed it works fine on Windows 8.1 x64 as well. I've assumed you're using a CDC class driver but there are also updated drivers for the DFU bootloader if that's what you're after.
I have tried to run the NONPNP windows driver code. It installs and when I run the nonpnpapp.exe I get a driver signing error.
"windows requires a digitally signed driver"
I am running this on debug mode and release I am test signing it.
Why am I still getting this error?
I do know that x64 machines needs this, I am on windows7 x64.
So we need to do something else.
Visual studio output says that the sys file is successfully signed.
I trace the code. It copies the sys to system32/drivers after it is signed.
Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.+
Note Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, which requires an EV certificate. For details, see Driver Signing Changes in Windows 10. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing
Two options there;
1) allow test signing
2) disable driver signature enforcement
If you are using a dedicated test machine, I recommend the second option since I think it's more error proof.
I have written a device driver for a device but each time I connect the device in windows XP 32 bit, "found new hardware" wizard appears.
I am signing the driver using a Comodo code signing certificate and not using the cross certificate chain to link to microsoft root authority. Nor is the driver wql certified.
So my question is to disable the found new hardware wizard on windows xp:
i) Does my driver needs to be wql certified?
ii) signed with microsoft root certificate using cross certificate from verisign?
iii) or something i missed out in my code which needs to be changed?
did some research and found the answer:
windows XP does not support authenticode driver signing and there are no plans to add it. Only way is to sign using microsoft certificate by using a cross certificate
As far as I know, the only driver signing recognized by Windows XP is a WHQL signature. Cross-signing has nothing to do with it. (Cross-signing allows the Windows Vista kernel driver loader to recognize Authenticode signatures. It has nothing to do with Windows XP driver loading.)
Authenticode signatures, while they would validate with DIFx / DpInst, would fail to validate later when SetupAPI tries to install your device driver out of the driver store.