DiskDrive KMDF Barebones Driver Causes Installation Failed

I created a new Visual Studio 2022 KMDF driver project changing only the INF file.

I cannot get passed the "Installation Failed" error message with no entries in the setupapi.dev.log file.

I am pretty confident that my INF file is fine. I perused the learning site on Microsoft's website and found the verycrypt filter driver sample on github. That matches almost identically to what I created and what the Microsoft document states that it wants, just I am using a lower-level Disk Drive driver, not an upper-level encryption driver. For good measure, I took the veracrypt inf file changing just the names and I still got the "Installation Failed". Lastly, I ran the inf file through the chkinf.bat utility. Here are the findings, basically nothing.

Line 15: (W22.1.2202) Unrecognized directive: PnpLockdown
Line 35: (W22.1.2083) Section [DEFAULTINSTALL.NTARM64] not referenced
Line 46: (W22.1.2083) Section [DEFAULTINSTALL.NTARM64.SERVICES] not referenced
Line 80: (W22.1.2213) INF files should not set registry entries under 'HKLM,System\CurrentControlSet\Control\Class'.

Notes:

  1. I used the release build
  2. Signed the driver using a DigiCert EV Code Signing Certificate
  3. Started my Win10 VM from scratch, no hold over from a previous install attempt

All the above tells me that I need to do something with the default code. I tried forcefully returning a STATUS_SUCCESS in the off chance that the DriverEntry failed, but no luck.

[Version]
signature   = "$Windows NT$"
Class       = DiskDrive
ClassGuid   = {4D36E967-E325-11CE-BFC1-08002BE10318}; {4D36E967-E325-11CE-BFC1-08002BE10318} is "LowerFilters", which matches the VS10 code
Provider    = %ProviderString%
DriverVer = 02/03/2025,1.26.20.0
CatalogFile = icsflt.cat
PnpLockdown = 1

[DestinationDirs]
DefaultDestDir     = 12
icsflt.DriverFiles = 12            ;%windir%\system32\drivers

;;
;; Default install sections
;;

[DefaultInstall.NTx86]
OptionDesc          = %ServiceDescription%
CopyFiles           = icsflt.DriverFiles
AddReg              = icsflt.AddReg

[DefaultInstall.NTamd64]
OptionDesc          = %ServiceDescription%
CopyFiles           = icsflt.DriverFiles
AddReg              = icsflt.AddReg

[DefaultInstall.NTarm64]
OptionDesc          = %ServiceDescription%
CopyFiles           = icsflt.DriverFiles
AddReg              = icsflt.AddReg

[DefaultInstall.NTx86.Services]
AddService          = icsflt,,icsflt.Service

[DefaultInstall.NTamd64.Services]
AddService          = icsflt,,icsflt.Service

[DefaultInstall.NTarm64.Services]
AddService          = icsflt,,icsflt.Service

;
; Services Section
;

[icsflt.Service]
DisplayName      = %ServiceDescription%
Description      = %ServiceDescription%
ServiceBinary    = %12%\icsflt.sys              ;%windir%\system32\drivers\
ServiceType      = 2                            ;SERVICE_FILE_SYSTEM_DRIVER
StartType        = 0                            ;SERVICE_BOOT_START
ErrorControl     = 1                            ;SERVICE_ERROR_NORMAL
LoadOrderGroup   = "Filter"

;
; Copy Files
;

[icsflt.DriverFiles]
icsflt.sys

[SourceDisksFiles]
icsflt.sys = 1,,

[SourceDisksNames]
1 = %DiskId1%,,,

;
; Registry Entries
;

[icsflt.AddReg]
HKLM, System\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}, LowerFilters, 0x00010008, icsflt
;HKLM, System\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}, LowerFilters, 0x00010008, PartMgr

;;
;; String Section
;;

[Strings]
ProviderString          = "icsflt company name"
ServiceDescription      = "icsflt"
DiskId1                 = "icsflt Device Installation Disk"

Chkinf is just wrong. Use infverif.exe instead. In fact infverif inf file checking is run as part of a standard visual studio driver build. Pnplockdown has been supported since Vista.

1 Like

Thank you. I will search for it and give that a try.

I did not know about your suggested inf verifier. I found a related query and that mentioned chkinf. Yeah, I saw that nobody updated that utility.

I will try it, but although anything is possible until I pass this problem, I do not think the problem is with the inf file, but rather maybe the default visual studio 2022 KMDF project.

Yes, I read yesterday evening that that the pnp lockdown in versions is since Vista and that I really do want 1. I do not want the driver file deleted unexpectedly.

This problem is very frustrating as I could care less what my problem is. Microsoft owes developers a log in setupapi.dev.log on every install attempt which results in a failure and the failure reason. I got nothing.

I got vs22 and infverif.exe to both give zero errors, however like an automated one-trick pony, Win10 still yields "Installation Failed".

Here is the infverif.exe report.

"C:\Program Files (x86)\Windows Kits\10\Tools\10.0.26100.0\x64\infverif.exe" /w /v "C:\ics\Win10\Temp\IM6000_2\x64\Release\icsflt.inf"
Running in Verbose
Running Windows Driver INF check

Validating icsflt.inf
INF is VALID

Checked 1 INF(s) in 0 m 0 s 13 ms

As I have no clue how to edit a post here on OCR, here is the updated INF file.

[Version]
signature = "$Windows NT$"
Class = DiskDrive
ClassGuid = {4D36E967-E325-11CE-BFC1-08002BE10318}; {4D36E967-E325-11CE-BFC1-08002BE10318} is "LowerFilters", which matches the VS10 code
Provider = %ProviderString%
DriverVer = 02/03/2025,1.26.20.0
CatalogFile = icsflt.cat
PnpLockdown = 1

[DestinationDirs]
DefaultDestDir = 13
CopyFiles=13

;;
;; Default install sections
;;

[DefaultInstall.NTx86]
OptionDesc = %ServiceDescription%
CopyFiles = CopyFiles.x86
AddReg = icsflt.AddReg

[DefaultInstall.NTamd64]
OptionDesc = %ServiceDescription%
CopyFiles = CopyFiles.amd64
AddReg = icsflt.AddReg

[DefaultInstall.NTarm64]
OptionDesc = %ServiceDescription%
CopyFiles = CopyFiles.arm64
AddReg = icsflt.AddReg

[DefaultInstall.NTx86.Services]
AddService = icsflt,,icsflt.Service

[DefaultInstall.NTamd64.Services]
AddService = icsflt,,icsflt.Service

[DefaultInstall.NTarm64.Services]
AddService = icsflt,,icsflt.Service

;
; Services Section
;

[icsflt.Service]
DisplayName = %ServiceDescription%
Description = %ServiceDescription%
ServiceBinary = %13%\icsflt.sys
ServiceType = 2 ;SERVICE_FILE_SYSTEM_DRIVER
StartType = 0 ;SERVICE_BOOT_START
ErrorControl = 1 ;SERVICE_ERROR_NORMAL
LoadOrderGroup = "Filter"

;
; Copy Files
;

[CopyFiles.x86]
icsflt.sys,icsflt.sys

[CopyFiles.amd64]
icsflt.sys,icsflt.sys

[CopyFiles.arm64]
icsflt.sys,icsflt.sys

[SourceDisksFiles]
icsflt.sys=1

[SourceDisksFiles.x86]
icsflt.sys,\x86

[SourceDisksFiles.amd64]
icsflt.sys,\amd64

[SourceDisksFiles.arm64]
icsflt.sys,\arm64

[SourceDisksNames]
1 = %DiskId1%,,,

;
; Registry Entries
;

[icsflt.AddReg]
HKR, System\CurrentControlSet\Control\Class{4D36E967-E325-11CE-BFC1-08002BE10318}, LowerFilters, 0x00010008, icsflt
;HKLM, System\CurrentControlSet\Control\Class{4d36e967-e325-11ce-bfc1-08002be10318}, LowerFilters, 0x00010008, PartMgr

;;
;; String Section
;;

[Strings]
ProviderString = "icsflt company name"
ServiceDescription = "icsflt"
DiskId1 = "icsflt Device Installation Disk"

Just for copmleteness, this is NOT actually a plug-and-play INF, so many INF rules don't apply. The use of [DefaultInstall] means this is basically just a user-mode software installer. Everything you're doing here can be done by a simple application (copy file, create service, add registry entry).

Exactly how are you attempting to install this?

This driver will do a lot. I am building it up by first getting a basic driver working and then adding in the pieces. It does not matter. What matters is my question that I cannot get past the "Installation Failed" and that setupapi.dev.log shows no entry whatsoever. I get no feedback as to the why.

To install the driver, I am using the following command line. Not, there is an executable that has this command line built into it and the executable gets called from my Inno Setup utility.

RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 128 "C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf"

That's one of the correct ways of installing this kind of driver (a class filter). However, your service should not be SERVICE_BOOT_START (StartType = 0). As a filter driver, you are not loaded independently, You are loaded when a device of your selected class loads. Thus, you should use SERVICE_DEMAND_START (StartType = 3).

I doubt this was the cause of your installation failure, however, Are you running this elevated?

I am running the above command line in an administrative command window, yes.

I just tried with type = 3 and no shock, "Installation Failed".

I am happy to send you the sys file. You already have the inf file.

As to boot vs. on demand, the Win7 inf uses boot and I understand why it does. Our driver encrypts the drives on the system inclusive of the Windows drives, e.g. C:, and then decrypts them. That could be on demand, I presume, but the boot makes sense. I did not write the Win7 driver, so I had no hand in any of it.

No, SERVICE_BOOT_START means the driver is started by itself, independently from any device. That's not what you have. This is not an independent driver. Your driver will ONLY be loaded when a disk device is created, as part of the PnP driver stack for the device, and it will be loaded for EVERY disk device.

And I don't understand the comment in the ClassGuid that says the GUID is "LowerFilters". That GUID is the Disk Drive install class.

I am easy going on the on-demand boot. The original developer could have been wrong.

The original Win7 driver chose disk drive, as we encrypt drives.

Either way, none of what you talk about has anything whatsoever to do with the "Installation Failed" error message. Definitely not the on demand, because as I stated I changed it and ran a test, same issue.

I am not opposed to tweaking the INF file. I really could care less at this juncture. I am focused on the main problem of Installation Failed, which we did not tackle. The infverif.exe utility reports no warnings or errors. VS22 indicates no warnings or errors too. That means the problem lies elsewhere.

A side problem is why setupapi.dev.log refuses to have an entry.

I am more than happy to email or somehow transmit the sys file, though you can easily recreate it yourself. Simply name the project icsflt and use the inf in this ticket and presto.

To be fair and upfront, I realized that I forgot to sign the sys file with my EV Code Signing certificate in my last few runs in the quest to get infverif.exe to show no errors/warnings.

I just signed the sys file. The inf file still has on demand. The resulting install attempt still shows "Install Failed" on my Win10 VM, fresh boot/restore and from an admin command prompt.

I really would not mind some help in licking this "Installation Failed" problem.

You have to turn test signing on using bcdedit.

re:logging

What version of Windows are you using to test this? Some older versions would log this to setupapi.app.log instead of setupapi.dev.log, which you may have to enable: Setting the Event Level for a Text Log - Windows drivers | Microsoft Learn

That was very helpful. I finally have some debug information. I did not know about that registry value. Thank you. The default is 0x20004001. I set that to 0x00007070.

The output is the following, which begs the question of what is wrong with the file name?

[Device Install Log]
OS Version = 10.0.19045
Service Pack = 0.0
Suite = 0x0100
ProductType = 1
Architecture = amd64

[BeginLog]

[Boot Session: 2025/04/29 21:57:30.608]

[Install INF Section (InstallHInfSection) - icsflt.inf"]
Section start 2025/04/29 22:11:33.085
cmd: RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 128 "C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf"
inf: INF - "C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf"
inf: Section - DefaultInstall
inf: Mode - 128
! inf: Unable to load INF: 'C:\Users\ICS\Downloads\icsflt_c_2"C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf"'(0000007b)
! inf: Error 123: The filename, directory name, or volume label syntax is incorrect.
!!! inf: Failed to open INF file '"C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf"'. Error = 0x0000007B
<<< Section end 2025/04/29 22:11:35.160
<<< [Exit status: FAILURE(0x0000007b)]

Try removing the quotes around the INF path in the command line

That helped and got me to 2 new errors. Thanks! Progress

Issue 1: Certificate Chain
I am not sure that I understand this problem, as I signed the icsflt.sys file using my DigiCert EV Code Signing Certificate and testing on my Hyper-V Manager Win10 VM. It seems to complain about signing the inf file, which is not possible. I will possibly have to contact DigiCert support on this error.

Here is the failed fragment.

 sto:                {DRIVERSTORE IMPORT VALIDATE} 21:29:38.846
 sig:                     Driver package catalog is valid.
 inf:                     Opened INF: 'C:\Windows\System32\DriverStore\Temp\{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.inf' ([strings])
 sig:                     {_VERIFY_FILE_SIGNATURE} 21:29:38.909
 sig:                          Key      = icsflt.inf
 sig:                          FilePath = C:\Windows\System32\DriverStore\Temp\{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.inf
 sig:                          Catalog  = C:\Windows\System32\DriverStore\Temp\{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.cat

! sig: Verifying file against specific (valid) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 21:29:38.924
sig: {_VERIFY_FILE_SIGNATURE} 21:29:38.924
sig: Key = icsflt.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.cat
! sig: Verifying file against specific Authenticode(tm) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 21:29:38.924
sig: Code Integrity State: Enforced
inf: Opened INF: 'C:\Windows\System32\DriverStore\Temp{daf281cd-6426-3e40-9587-a7343cca1def}\icsflt.inf' ([strings])
!!! sig: Driver package catalog file certificate does not belong to Trusted Root Certificates, and Code Integrity is enforced.
!!! sig: Driver package failed signature validation. Error = 0xE0000247
sto: {DRIVERSTORE IMPORT VALIDATE: exit(0xe0000247)} 21:29:38.924
!!! sig: Driver package failed signature verification. Error = 0xE0000247
!!! sto: Failed to import driver package into Driver Store. Error = 0xE0000247
sto: {Stage Driver Package: exit(0xe0000247)} 21:29:38.924
ump: Driver store add process exited with code 0xe0000247 21:29:38.940
cpy: Deleted 'C:\Users\ICS\AppData\Local\Temp{eca1bc5f-00b1-2340-8b2f-826ad34f866c}\icsflt.cat'.
cpy: Deleted 'C:\Users\ICS\AppData\Local\Temp{eca1bc5f-00b1-2340-8b2f-826ad34f866c}\icsflt.inf'.
cpy: Deleted 'C:\Users\ICS\AppData\Local\Temp{eca1bc5f-00b1-2340-8b2f-826ad34f866c}\icsflt.sys'.
dvs: {Driver Setup Import Driver Package - exit (0xe0000247)} 21:29:39.018
!!! dvs: Failed to import driver packages under 'C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf'. Error = 0xe0000247
dvs: {DrvSetupInstallDriver - exit(e0000247)}
! inf: Unable to process as primitive driver, processing as legacy. Error = 0xE0000247
inf: Installing section [DefaultInstall.NTamd64] from 'C:\Users\ICS\Downloads\icsflt_c_2\icsflt.inf'.
inf: {Install Inf Section [DefaultInstall.NTamd64]}

Issue #2: Service Binary

ServiceBinary=%13%\icsflt.sys seems to expand to .\icsflt.sys, which is weird and an error.

 inf:      {Install from INF Section - exit(0x00000000)} 22:06:49.127
 inf: {Install Inf Section [DefaultInstall.NTamd64] exit (0x00000000)}
 inf: {Install Inf Section [DefaultInstall.NTamd64.Services]}
 inf:      AddService=icsflt,,icsflt.Service  (icsflt.inf line 44)
 inf:      ServiceType=2  (icsflt.inf line 57)
 inf:      StartType=3  (icsflt.inf line 58)
 inf:      ErrorControl=1  (icsflt.inf line 59)
 inf:      ServiceBinary=.\icsflt.sys  (icsflt.inf line 56)

!!! dvi: Driver Path not in system root
inf: {Install Inf Section [DefaultInstall.NTamd64.Services] exit(0xe0000217)}
inf: Error 0xe0000217: A service installation section in this INF is invalid.
!!! dvi: Error while installing services.
!!! dvi: Error 0xe0000217: A service installation section in this INF is invalid.
<<< Section end 2025/04/30 22:06:50.463
<<< [Exit status: FAILURE(0xe0000217)]

I was right. HKR was a mistake. It really needs to be HKLM to avoid an error.

Assuming that I need DigiCert support and that they help, then I am down to this one error, but like anything layered, I will not know that until I resolve these two errors.

Hi Mark, would you like to elaborate about testing signing using bcedit?

Setuapi complained about certificate (one of two problems).

If I go to icsflt.sys properties I see the digital certificate just fine, but that is not following a chain. I am thinking that I might have to get DigiCert involved. I hope not. I am using their EV Digital Code Signing certificate.

! sig: Verifying file against specific (valid) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

All kernel drivers either have to be signed using Microsoft’s signing cert or you have to turn test signing on using bcdedit.

Your ev cert is not broken, it just isn’t sufficient for installing kernel drivers.

2 Likes

Correct, HKR doesn't map to a location filters get loaded from, unless you're in a *.HW section (which doesn't exist in DefaultInstall-based INFs).

This line is indicating that because something fell over already, we're going down a legacy codepath that doesn't support %13% in case that helps (which it might if this was a really old driver). If you resolve your signing issue, that wouldn't happen and you'd be fine.

It has not been possible to load self-signed drivers since the second update of Windows 10. Your code-signing certificate is only used to enable submissions to the Hardware Dashboard to get Microsoft's signature.