I?ve written a Windows 7 64-bit kernel mode driver with Visual Studio 2012 that I was able to debug and test on a provisioned target computer. After I was successfully able to communicate with the hardware for my driver I acquired a code signing certificate from Entrust and was able to sign the driver with it. However, when I tried to install the driver Windows indicated it was not signed. Eventually Entrust had to issue a different code signing certificate that I used to sign the driver with. It is at this point I tried to manually install my driver through the Device Manager after disabling the Test Mode on the target computer. Windows indicated that the driver successfully installed and the Driver tab on the Device properties window indicated that it was in fact signed. It was at this point I tried to install the driver on a computer that had not been provisioned nor was in Test Mode.
This attempted installation immediately indicated that Windows encountered a problem trying to install the driver. It said ?The system cannot find the file specified.? Looking at the setupapi.dev.log file revealed the file it was looking for was WdfCoInstaller01011.dll. Windows was trying to copy the file from the directory ?Win7Release? and not the ?Win7Release\Digitizer Package? directory in which the coinstaller resides. I tried adding an entry to my inf file directing Windows to the proper directory. This did not work. Windows continued looking for the coinstaller in the Win7Release directory. However I was able to install the driver manually by pointing the driver update dialog to Win7Release\Digitizer Package instead of Win7Release. This caused Windows to warn me the driver was not signed and I had to tell it to install anyway. After installation I was able to communicate with the hardware.
I?m a lot confused as this is my first driver. I thought signing the driver would be the easy part. I thought not having the driver signed would prevent a driver from being installed unless Windows was put into Test Mode and the driver was signed with a test certificate. Why did Windows allow me to install the driver and communicate with the hardware if the driver was not signed?
I went to the setupapi.dev.log on the provisioned target computer, where the driver installation had succeeded, to look for clues. I was shocked to find problems with the signature such as:
Error 0x800b0109: A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider.
and
Error 0xe0000242: The publisher of an Authenticode ™ signed catalog has not yet been established as trusted.
Why did the installation ?succeed? on the target computer, no longer in Test Mode, if there was a problem with the certificate used to sign the driver?
Is the problem still with my code signing certificate or my inf file? Maybe both? I can post my inf file and the relevant parts of the setupapi.dev.log file if that helps.
Thanks for any help or pointers you can provide.
xxxxx@wyle.com wrote:
This attempted installation immediately indicated that Windows encountered a problem trying to install the driver. It said ?The system cannot find the file specified.? Looking at the setupapi.dev.log file revealed the file it was looking for was WdfCoInstaller01011.dll. Windows was trying to copy the file from the directory ?Win7Release? and not the ?Win7Release\Digitizer Package? directory in which the coinstaller resides. I tried adding an entry to my inf file directing Windows to the proper directory. This did not work. Windows continued looking for the coinstaller in the Win7Release directory. However I was able to install the driver manually by pointing the driver update dialog to Win7Release\Digitizer Package instead of Win7Release. This caused Windows to warn me the driver was not signed and I had to tell it to install anyway. After installation I was able to communicate with the hardware.
Your INF file should not refer to any subdirectory names at all. The
INF simply refers to file names. Device Manager will look in whatever
directory contains the INF file. That directory should contain the CAT
file, the INF file, your SYS file, and the KMDF co-installer.
I?m a lot confused as this is my first driver. I thought signing the driver would be the easy part.
Sadly, no. Driver signing is a difficult and complicated topic, in part
because there are two separate signing stages with different sets of
requirements.
I was shocked to find problems with the signature such as:
Error 0x800b0109: A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider.
and
Error 0xe0000242: The publisher of an Authenticode ™ signed catalog has not yet been established as trusted.
Remember that the signed CAT file contains a checksum of all of the
files in the package, at the location they were in when the CAT file was
created. If you had to override a file location, then that invalidates
the CAT file, and your signature is discarded.
Do you want to post your INF file here, and we can critique it?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes. Is it odd to have the inf and sys files in both the Win7Release and Win7Release\Digitizer Package directories?
inf file content, note i altered the ManufacturerName field to protect the guilty:
; Digitizer.inf
;
[Version]
Signature=“$WINDOWS NT$”
Class=Media ; TODO: edit Class
ClassGuid={4d36e96c-e325-11ce-bfc1-08002be10318} ; TODO: edit ClassGuid
Provider=%ManufacturerName%
CatalogFile=Digitizer.cat
DriverVer=05/29/2013 ; TODO: set DriverVer in stampinf property pages
;[DestinationDirs]
;DefaultDestDir = 12
; ================= Class section =====================
;[ClassInstall32]
;Addreg=SampleClassReg
;[SampleClassReg]
;HKR,0,%ClassName%
;HKR,Icon,-5
[SourceDisksNames]
1 = %DiskName%,“”
;[SourceDisksFiles]
;Digitizer.sys = 1,
;*****************************************
; Install Section
;*****************************************
[Manufacturer]
%ManufacturerName%=Standard,NT$ARCH$
[Standard.NT$ARCH$]
%Digitizer.DeviceDesc%=Digitizer_Device, PCI\VEN_10E8&DEV_816A ; TODO: edit hw-id
[Digitizer_Device.NT]
CopyFiles=Drivers_Dir
[Drivers_Dir]
Digitizer.sys
;-------------- Service installation
[Digitizer_Device.NT.Services]
AddService = Digitizer,%SPSVCINST_ASSOCSERVICE%, Digitizer_Service_Inst
; -------------- Digitizer driver install sections
[Digitizer_Service_Inst]
DisplayName = %Digitizer.SVCDESC%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 0 ; SERVICE_ERROR_IGNORE
ServiceBinary = %12%\Digitizer.sys
;
;
AddReg = DigitizerParameters.AddRegistry
;
;
;LoadOrderGroup = Extended Base
;
;
[DigitizerParameters.AddRegistry]
HKLM,%RegistryPath%,“AheadBufferLen”,0x00010001,“65535”
HKLM,%RegistryPath%,“MaxChannelPairs”,0x00010001,“0”
;
;
;
;— Digitizer_Device Coinstaller installation ------
;
[DestinationDirs]
DefaultDestDir = 12
Digitizer_Device_CoInstaller_CopyFiles = 11
[Digitizer_Device.NT.CoInstallers]
AddReg=Digitizer_Device_CoInstaller_AddReg
CopyFiles=Digitizer_Device_CoInstaller_CopyFiles
[Digitizer_Device_CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll,WdfCoInstaller”
[Digitizer_Device_CoInstaller_CopyFiles]
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll
[SourceDisksFiles]
Digitizer.sys = 1,
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll=1 ; make sure the number matches with SourceDisksNames
[Digitizer_Device.NT.Wdf]
KmdfService = Digitizer, Digitizer_wdfsect
[Digitizer_wdfsect]
KmdfLibraryVersion = $KMDFVERSION$
[Strings]
SPSVCINST_ASSOCSERVICE= 0x00000002
ManufacturerName=“XXXX” ; TODO: add ManufacturerName
;ClassName=“Samples” ; TODO: edit ClassName
DiskName = “Digitizer Installation Disk”
Digitizer.DeviceDesc = “Digitizer Device”
Digitizer.SVCDESC = “Digitizer Service”
RegistryPath = “SYSTEM\CurrentControlSet\Services\Digitizer\Parameters”
xxxxx@wyle.com wrote:
Yes. Is it odd to have the inf and sys files in both the Win7Release and Win7Release\Digitizer Package directories?
No. The project for your driver builds into the Win7Release directory.
Then, when you run the project for your driver package (which is a
separate project), it collects the files into the Digitizer Package
directory, copies in the co-installer, and creates the CAT file. You
should use the files from “Digitizer Package” directory when you copy
your package to another computer to be installed.
I don’t see anything fundamentally wrong with your INF. I’m guessing
your troubles were caused by copying your release files from the wrong
directory, so that you missed the co-installer DLL.
; Digitizer.inf
;[Version]
Signature=“$WINDOWS NT$”
Class=Media ; TODO: edit Class
ClassGuid={4d36e96c-e325-11ce-bfc1-08002be10318} ; TODO: edit ClassGuid
Provider=%ManufacturerName%
CatalogFile=Digitizer.cat
DriverVer=05/29/2013 ; TODO: set DriverVer in stampinf property pages
Why media-class? I think I would have expected this in mice and
pointing devices.
[DigitizerParameters.AddRegistry]
HKLM,%RegistryPath%,“AheadBufferLen”,0x00010001,“65535”
HKLM,%RegistryPath%,“MaxChannelPairs”,0x00010001,“0”
You don’t need to include the whole registry path here. Each AddReg has
a default location (noted by HKR); in the case of an AddReg in a service
section (as you have here), the default location is the Services key for
the service. Also, 0x00010001 is a REG_DWORD value, which expects an
integer, not a string. Don’t use quotes around a numeric value.
So, this:
HKR,Parameters,“AheadBufferLen”,0x00010001,65535
HKR,Parameters,“MaxChannelPairs”,0x00010001,0
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I tried using just the Digitizer Package to manually install the driver. When I do I get a Windows Security pop-up window stating ?Windows can?t verify the publisher of this driver software.? I?m given two choices in this window ?Don?t install this driver software? and ?Install this driver software anyway.? The subtext under the install anyway option says ?Only install driver software obtained from your manufacturer?s website or disc. Unsigned software from other sources may harm your computer or steal information.? Is it safe to assume at this point that there is something wrong with my code signing certificate?
As for media-class it may have something to do with the PCI chipset that is used in the hardware. My driver is a rewrite of a driver that predates Windows XP. The original driver, which predates my time, was ported to XP with many deprecated functions left in place. These deprecated functions are now obsolete, such as HalGetBusData.
Also thanks for the tips on how to clean up my inf file, much appreciated.
xxxxx@wyle.com wrote:
I tried using just the Digitizer Package to manually install the driver
How did you try to manually install it?
When I do I get a Windows Security pop-up window stating ?Windows can?t verify the publisher of this driver software.? I?m given two choices in this window ?Don?t install this driver software? and ?Install this driver software anyway.? The subtext under the install anyway option says ?Only install driver software obtained from your manufacturer?s website or disc. Unsigned software from other sources may harm your computer or steal information.? Is it safe to assume at this point that there is something wrong with my code signing certificate?
No. Have you verified that the package is actually being signed with
your certificate? In a VS2012 command line, change to your package
directory and do this:
signtool verify /v /kp Digitizer.sys
signtool verify /v /kp Digitizer.cat
If you aren’t comfortable with that, zip up the contents and send them
to me by email, timr at probo dot com. I’ll take a quick look.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I install the driver manually through the Device Manager. Under the Device Manager there is a Multimedia Controller listed under Other Devices. I right click the Multimedia Controller and select Properties. In the Multimedia Controller Properties that appear I select the Update Driver button. In the next dialog I choose to “Browse my Computer for driver Software.” In the following window I browse to my Digitizer Package. I then hit the next button. It is at this point I’m greeted with the previously mentioned Windows Security pop-up window.
Digitizer.sys and Digitizer.cat both appear to be signed, see below.
Verifying: Digitizer.sys
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 527FDD4509B82C8BB587DAAF8A2C533D84039EE9
Signing Certificate Chain:
Issued to: Entrust.net Certification Authority (2048)
Issued by: Entrust.net Certification Authority (2048)
Expires: Tue Jul 24 10:15:12 2029
SHA1 hash: 503006091D97D4F5AE39F7CBE7927D7D652D3431
Issued to: Entrust Code Signing Certification Authority - L1D
Issued by: Entrust.net Certification Authority (2048)
Expires: Fri Nov 12 04:51:52 2021
SHA1 hash: D0D7578B7317228E31D42EDF356A7C64F1050473
Issued to: XXXX Inc
Issued by: Entrust Code Signing Certification Authority - L1D
Expires: Tue Jun 09 21:57:22 2015
SHA1 hash: 90FA39EBFE6F32559F9D01FF16F6FEE55E075276
File is not timestamped.
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 09:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Entrust.net Certification Authority (2048)
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 16:02:17 2021
SHA1 hash: 00A3E6009EAA739B3DEEF4B506649D8A1A7AD33A
Issued to: Entrust Code Signing Certification Authority - L1D
Issued by: Entrust.net Certification Authority (2048)
Expires: Fri Nov 12 04:51:52 2021
SHA1 hash: D0D7578B7317228E31D42EDF356A7C64F1050473
Issued to: XXXX Inc
Issued by: Entrust Code Signing Certification Authority - L1D
Expires: Tue Jun 09 21:57:22 2015
SHA1 hash: 90FA39EBFE6F32559F9D01FF16F6FEE55E075276
File has page hashes.
Successfully verified: Digitizer.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
and
Verifying: digitizer.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 3AF4F862E048151FB54DDA7C91B384C748F2DF13
Signing Certificate Chain:
Issued to: Entrust.net Certification Authority (2048)
Issued by: Entrust.net Certification Authority (2048)
Expires: Tue Jul 24 10:15:12 2029
SHA1 hash: 503006091D97D4F5AE39F7CBE7927D7D652D3431
Issued to: Entrust Code Signing Certification Authority - L1D
Issued by: Entrust.net Certification Authority (2048)
Expires: Fri Nov 12 04:51:52 2021
SHA1 hash: D0D7578B7317228E31D42EDF356A7C64F1050473
Issued to: XXXX Inc
Issued by: Entrust Code Signing Certification Authority - L1D
Expires: Tue Jun 09 21:57:22 2015
SHA1 hash: 90FA39EBFE6F32559F9D01FF16F6FEE55E075276
File is not timestamped.
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 09:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Entrust.net Certification Authority (2048)
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 16:02:17 2021
SHA1 hash: 00A3E6009EAA739B3DEEF4B506649D8A1A7AD33A
Issued to: Entrust Code Signing Certification Authority - L1D
Issued by: Entrust.net Certification Authority (2048)
Expires: Fri Nov 12 04:51:52 2021
SHA1 hash: D0D7578B7317228E31D42EDF356A7C64F1050473
Issued to: XXXX Inc
Issued by: Entrust Code Signing Certification Authority - L1D
Expires: Tue Jun 09 21:57:22 2015
SHA1 hash: 90FA39EBFE6F32559F9D01FF16F6FEE55E075276
Successfully verified: digitizer.cat
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
xxxxx@wyle.com wrote:
I install the driver manually through the Device Manager. Under the Device Manager there is a Multimedia Controller listed under Other Devices. I right click the Multimedia Controller and select Properties. In the Multimedia Controller Properties that appear I select the Update Driver button. In the next dialog I choose to “Browse my Computer for driver Software.” In the following window I browse to my Digitizer Package. I then hit the next button. It is at this point I’m greeted with the previously mentioned Windows Security pop-up window.
Your signature chains are correct. Now, until your driver is signed by
WHQL, you will get a security pop-up window, but it should be the “Do
you trust this publisher?” dialog. If that’s the dialog you’re
getting, then everything is A-OK.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The Windows Security dialog that displays has a red banner with the text “Windows can’t verify the publisher of this driver software” and has two options “Don’t install driver software” and “Install this driver software anyway.” There is also a “See details” button on this dialog. Clicking this button reveals the following text “The driver software you’re attempting to install does not have a valid digital signature that verifies who published it, and could potentially be malicious software. You should only install driver software from publishers you trust. How can I decide which device software is safe to install?”
xxxxx@wyle.com wrote:
The Windows Security dialog that displays has a red banner with the text “Windows can’t verify the publisher of this driver software” and has two options “Don’t install driver software” and “Install this driver software anyway.” There is also a “See details” button on this dialog. Clicking this button reveals the following text “The driver software you’re attempting to install does not have a valid digital signature that verifies who published it, and could potentially be malicious software. You should only install driver software from publishers you trust. How can I decide which device software is safe to install?”
Zip up your package and email it to me privately. I’ll take a look.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi,
I was also facing same problem in some time before.
- verify that certificate successfully installed or not. You can verify the certificate status in certmgr.msc.
- Verify that certificate status is ok or not.
- Verify that Certificate issue date expired or not.
If everything is ok, then need to delete the certificate from the certmgr.exe and again istalled. It may be helpful for you.
The problem installing the driver appears to have been due to the fact that the root certificate, as listed in the “Signing Certificate Chain” from the signtool verify listing, was not present. The computer I was trying to install the computer was not connected to the internet. After some digging around it sounded like the Microsoft Root Certificate Program would acquire the missing certificate for me should it not be present. After connecting the computer to the internet and trying to install the driver the certificate failed to materialize and the driver failed to install. After some more digging it turns out that my company?s IT department blocks the Microsoft Root Certificate Program. I then try using a colleague’s hotspot to get around the IT department but still the certificate would not download nor would the driver install. When those attempts failed I export the root certificate from the computer I?d used to sign the driver and had a colleague write a simpler installer that imports the certificate before installing the driver. This worked like a charm. Is it normal to have to provide the root certificate yourself in this manner?
The driver works but programs that use it exhibit a minor quirk. These programs must run as administrator. The user account I installed the driver under is an admin capable account. Is this happening because the driver is reading a couple of values from the register, AheadBufferLen and MaxchannelPairs? Or reading from a location that is not the expected default location, as pointed out in the response to my inf listing? Maybe there is a preferred way to read from the registry that doesn?t run afoul of Windows User Access Control? I used RtlQueryRegistryValues().
xxxxx@wyle.com wrote:
The problem installing the driver appears to have been due to the fact that the root certificate, as listed in the “Signing Certificate Chain” from the signtool verify listing, was not present. The computer I was trying to install the computer was not connected to the internet. After some digging around it sounded like the Microsoft Root Certificate Program would acquire the missing certificate for me should it not be present. After connecting the computer to the internet and trying to install the driver the certificate failed to materialize and the driver failed to install. After some more digging it turns out that my company?s IT department blocks the Microsoft Root Certificate Program.
That is counter-productive.
Is it normal to have to provide the root certificate yourself in this manner?
The root certificates all eventually expire. When they expire, they
have to be refreshed, and that requires Internet access.
The driver works but programs that use it exhibit a minor quirk. These programs must run as administrator. The user account I installed the driver under is an admin capable account. Is this happening because the driver is reading a couple of values from the register, AheadBufferLen and MaxchannelPairs? Or reading from a location that is not the expected default location, as pointed out in the response to my inf listing? Maybe there is a preferred way to read from the registry that doesn?t run afoul of Windows User Access Control? I used RtlQueryRegistryValues().
The user’s permissions do not affect the driver’s activities in any
way. You do have to have appropriate permission to open a handle to the
driver. You can change that by using a different security descriptor
when you install the device.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>After some more digging it turns out that my company?s IT department blocks the Microsoft Root Certificate Program.
The root certificate updates are available as a single update file. In a larger organization, individual computers may not get their updates directly from Microsoft servers on the Internet, they may get them from a local Windows update server than has cached copies.
I’d suggest you communicate with the IT dept about why they aren’t including the root certificate updates. It’s reasonable to not let every system in a datacenter have outbound access to the Internet, but you still need to be applying important updates, which is exactly what a local Windows Update server accomplishes.
Is it normal to have to provide the root certificate yourself in this manner?
No its not normal, and is inappropriate for an installer to be trying to add a root certificate. If the security policy allows random programs to add new root certificates, there is nothing to stop some random malware from adding its own self-signed root. In a large environment, it’s also very common for the domain controller to automatically update the set of certificates on a machine. This is actually really nice for internal use drivers, as the DC can automatically add your code signing certificate, which eliminates any first time device use dialog asking if your certificate is trusted.
One solution is to sign your driver with a certificate from a root that that’s widely used. My guess is you have a less popular brand of certificate, and it’s root is not widely preinstalled, causing your current problem.
It’s also not uncommon for a product to require a specific Microsoft Update as a prerequisite, like say the revised root certificate update.
The driver works but programs that use it exhibit a minor quirk. These programs must run as administrator.
You as a driver developer get to control what the security on devices are. A common setting is to only allow a user account with Administrator privileges or higher to open the device. If it’s a PnP device, which includes a root enumerated PnP device, you can use full SDDL strings in the INF to describe the desired device security. From the driver, you can use a an SDDL subset, or write code to set more complex security on a device.
I’m not sure why but I was not able to fix my run as admin problem by specifying SDs in the inf file as described in
http://www.osronline.com/article.cfm?article=508
I could only resolve the issue by specifying the SDs in the driver code itself as described in the above mentioned article. Is it not possible to specify SDs in an inf file for a kernel mode driver? Defining class-wide access control looked super easy but failed to work for me.
Is your driver a PnP driver or a legacy driver (i.e. it creates a device in DriverEntry). My past experience is INF defined SDs for devices only are usable on PnP drivers.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@wyle.com
Sent: Thursday, June 26, 2014 1:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem Signing Driver
I’m not sure why but I was not able to fix my run as admin problem by specifying SDs in the inf file as described in
http://www.osronline.com/article.cfm?article=508
I could only resolve the issue by specifying the SDs in the driver code itself as described in the above mentioned article. Is it not possible to specify SDs in an inf file for a kernel mode driver? Defining class-wide access control looked super easy but failed to work for me.
It’s a PnP driver. The device is created in my function DigitizerEvtDeviceAdd() which calls WdfDeviceCreate().