Hello, I’m having some trouble passing attestation of my legacy driver. I’ve got a WFP Callout driver that uses KMDF 1.9, without a coinstallation dll. This driver is built using WinDDK 7600.16385.1
Each time I submit to the portal, or use inf2cat, I get a not-so-useful error: “No installation INF found in the root path of the driver…” The error makes it sound as if I have no inf file, though clearly I do, because you don’t get that far on the portal without having one, and having it in the right place. In the INI file itself, I have the Default Installation lines according to the page above.
If not clear by my question already - I’m fairly new to the Windows world. I’ve done embedded work for 15+ years, but Windows for only 1, and this is my first foray into Windows driver development when our drivers stopped working on Windows 10. I did add the coinstaller lines from an example, just to see if I get a different error - the answer is no.
Thanks for the reply.
That is true (I made that mistake first - and was kicked out during the scanning state in the portal) but it’s now in a subfolder inside of the cab file. The error on the portal specified that it failed running inf2cat. I also get this error locally when I try to run inf2cat on the folder containing the sys and inf file.
Thanks for the reply. That is true (I made that mistake first - and was kicked out during the scanning state in the portal) but it’s now in a subfolder inside of the cab file. The error on the portal specified that it failed running inf2cat. I also get this error locally when I try to run inf2cat on the folder containing the sys and inf file.
The full message is: Errors:
No installation INF found in the root path of the driver. For the driver to be digitally signed, and for it to install properly the installation inf must be in the root of each driver path you have provided. If you have separate folders with different driver packages for different languages, operating systems or device categories then specify each driver set as a separate driver. Each driver package must be selected separately and must contain an installation INF.
The full message is: Errors:
No installation INF found in the root path of the driver. For the driver to be digitally signed, and for it to install properly the installation inf must be in the root of each driver path you have provided. If you have separate folders with different driver packages for different languages, operating systems or device categories then specify each driver set as a separate driver. Each driver package must be selected separately and must contain an installation INF.
To answer your question: no. I attempted and get a dialog box that says "The file (myDriver.sys) on %DiskName% is needed.
Perhaps I’ve got a formatting issue, I’ll dig into that. The reason I hadn’t tried this, is that to use my driver, normally my application calls a dll file which loads it at run time. (via the DriverEntry)
The full message is: Errors: No installation INF found in the root path of the driver. For the driver to be digitally signed, and for it to install properly the installation inf must be in the root of each driver path you have provided. If you have separate folders with different driver packages for different languages, operating systems or device categories then specify each driver set as a separate driver. Each driver package must be selected separately and must contain an installation INF.
So, perhaps I’ve taken a wrong turn, and ended up with a problem I don’t need to solve. So, first. I have a .sys file that I submitted -> Originally got errors that a required INF file did not exist. (After further inspection, perhaps I didn’t need a INF file - the error description I got was that it was either a missing INF file, or having the files at the root of the cab (as your first response described) - I had both issues, so by the time I moved it into a subdirectory, I added the INF file.) After getting through the Scanning session with a few invalid INF files, I’ve got something that’s valid (at least syntax wise), and now the portal fails in the Catalog Creation State with the error:
We found INF policy violations in your submission. You can download and run INF2Cat to check for violations. Please fix the INF violations, create a new submission package, and resubmit it.
You can download your full error report here for more information about what went wrong and how to fix the issue.
(The full error report that I downloaded matches the error from INF2Cat posted earlier)
The goal would be to get something akin to Matt
Assuming now that I do need the INF file, would I need to include the .dll file which accesses and loads the driver? It’s not a “co-installer”, as I think that has a distinct meaning and use, but a dll (user mode driver) which interfaces with the kernel mode driver. So, I’ve got my application which makes calls to the usermode dll, which talks to the kernel mode driver. (Apologies for my rudimentary understanding of what’s going on under the hood) I get that idea after perusing other active threads in this forum.
So, perhaps I’ve taken a wrong turn, and ended up with a problem I don’t need to solve. So, first. I have a .sys file that I submitted -> Originally got errors that a required INF file did not exist. (After further inspection, perhaps I didn’t need a INF file - the error description I got was that it was either a missing INF file, or having the files at the root of the cab (as your first response described) - I had both issues, so by the time I moved it into a subdirectory, I added the INF file.) After getting through the Scanning session with a few invalid INF files, I’ve got something that’s valid (at least syntax wise), and now the portal fails in the Catalog Creation State with the error:
We found INF policy violations in your submission. You can download and run INF2Cat to check for violations. Please fix the INF violations, create a new submission package, and resubmit it.
You can download your full error report here for more information about what went wrong and how to fix the issue.
(The full error report that I downloaded matches the error from INF2Cat posted earlier)
You do need a fake INF so the attestation process can create and sign a
fake CAT file. There are lots of ways to get an INF file wrong. Can
you show us the entire INF file?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Ah okay, I see why your using Inf2Cat now, thanks. You do need to submit an INF file with the driver package for attestation signing. If Microsoft is asking you to run this to validate the INF file. There is something wrong with the INF file. You should be able to install the driver with the INF. If that fails the attestation signing is going to fail.
Assuming now that I do need the INF file, would I need to include the .dll file which accesses and loads the driver? It’s not a “co-installer”, as I think that has a distinct meaning and use, but a dll (user mode driver) which interfaces with the kernel mode driver. So, I’ve got my application which makes calls to the usermode dll, which talks to the kernel mode driver. (Apologies for my rudimentary understanding of what’s going on under the hood) I get that idea after perusing other active threads in this forum.
To say I have an INF file would be a bit misleading. I’ve attempted several variations based upon MS documentation/samples. This one is my spin from https://docs.microsoft.com/en-us/windows-hardware/drivers/network/inf-files-for-callout-drivers
That being said, I can now “install” - it tells me that I must restart my PC - even though the INF2CAT tool still shows the installation INF missing failure.
My Current INF file with a few comments inline:
[Version]
Signature = “$Windows NT$”
Provider = %Company%
CatalogFile = “SampleDriver.cat”
DriverVer = 08/01/2017,1.2.2 ; Documentation here a bit confusing, perhaps the date should be the same as my .sys file date?
; – JUST ADDED THIS TO TRY: DriverPackageType = ClassFilter
[SourceDisksNames]
1 = %DiskName%
[SourceDisksFiles]
SampleDriver64.sys = 1
[DestinationDirs]
; I changed this back to match the example - I originally had my installation directory here
; - the folder I create during installation of my application is where I put the .sys file. (along with the dll)
;
DefaultDestDir = 12 ; %windir%\system32\drivers
SampleDriver.DriverFiles = 12 ; %windir%\system32\drivers
@Tim and @Johnny, thanks so much. That last list of Errors was helpful. First, I did have some bad syntax, but more importantly, the first error showed that I must have a class directive.
I fixed the syntax at the bottom (company, diskname, etc with the extra surrounding %'s) But also, I did not have Class GUID = while I still got an error with chkInf, inf2cat passed. So, it *looks* like it was signed. Now to reboot and see if it works!
Thanks so much.
@Tim and @Johnny, thanks so much. That last list of Errors was helpful. First, I did have some bad syntax, but more importantly, the first error showed that I must have a class directive. I fixed the syntax at the bottom (company, diskname, etc with the extra surrounding %'s) But also, I did not have Class GUID = while I still got an error with chkInf, inf2cat passed. So, it looks like it was signed. Now to reboot and see if it works! Thanks so much.
HELP! My machine now won’t boot. The only idea I have is that “installing” the inf file, installing the driver - which at one point, the start type was: – in example is: 0 ;
SERVICE_BOOT_START.
IF this is it, I want to uninstall the driver, but I’m completely locked out of Windows - I can get to command line - kind of. comes up as X: because I have bitlocker on. In that view, the sys file is not under c:/windows/system32/drivers. I can’t access the drive that it should have been installed *from*. I’ve no idea what to try. I’ve gone to safe mode, no luck. This *driver* doesn’t do anything without a calling dll, so I’ve no idea what’s going on.
ok. I’m back up - I had to disable driver signing verification on bootup. So, exactly what did “install” do from right clicking? Did it simply place the .sys file in my windows/system32/drivers folder. How do I uninstall? There’s no “device” in Device Manager. I’m guessing I could “reinstall” with the StartType instruction not equal to 0. Would deleting the file from windows/system32/drivers do it?
BTW, the driver was under c:/windows/system32/drivers - it wasn’t under x:/windows/system32/drivers. I learned that X is the recovery drive, not a signal that bitlocker was on…
Thanks for any hints on this unintentional install of the driver, and I’ll certainly follow up if the use of my driver is now working with the new signature.
-W
What was the behavior when starting the machine? Did it just boot into recovery mode? I found if that happens there is likely a problem with the singing. Was it bugchecking? If so, what was the nature of the crash?
ok. I’m back up - I had to disable driver signing verification on bootup. So, exactly what did “install” do from right clicking? Did it simply place the .sys file in my windows/system32/drivers folder. How do I uninstall? There’s no “device” in Device Manager. I’m guessing I could “reinstall” with the StartType instruction not equal to 0. Would deleting the file from windows/system32/drivers do it? BTW, the driver was under c:/windows/system32/drivers - it wasn’t under x:/windows/system32/drivers. I learned that X is the recovery drive, not a signal that bitlocker was on… Thanks for any hints on this unintentional install of the driver, and I’ll certainly follow up if the use of my driver is now working with the new signature. -W
It went into a loop of “starting Diagnostics” & “Could not start diagnostics” and to the advanced startup screen. The issue makes sense to me - during the trial and error of attempting different inf files - I had one where I forgot to change the StartType from 0 to 3. So, I told the machine that this driver was required for bootup. Second, the driver of course was not signed at that time - because I was trying to get something to submit for Microsoft to sign it. So, the machine couldn’t boot because it had an unsigned driver that was required at bootup.
So, to boot up - I disabled the signing verification, and it booted “normally”. Once booted, I deleted the .sys file from the system32/drivers verification - however, I still have a strange behavior. Once the sys file is “loaded” from the application, I can’t copy over the .sys file with another one. It seems that the OS has recognized this sys file as running, and the file can’t be copied over - gives the normal File in User error. This only happens on my computer - which I ran the “install” on the INF file. This doesn’t happen on other machines I deploy my software to with this new Microsoft signed sys file. – Yes, that last sentence is to say that it seems to be signed correctly, and works on other machines - including a Windows 7 machine. THANKS SO MUCH. It’s a minor annoyance on my machine. I’ve looked through regedit, and my device manager for any reference to my sys file, I can’t find it - or the copy&paste error from the example, which had the name with the “%” surrounding my driver name.
At this point, the issue is a small, annoying price to pay for the success of actually getting the driver signed. So, thanks for pointing me in the right direction.
First, the reason the file is locked is on newer OSes the kernel maps the memory view of the driver to the file on disk. You should be able to rename the file but not overwrite/delete it.
On the topic of why the machine won?t boot. And, this may or may not apply to your machine. I found, on Secure Boot enabled unpatched Windows 10 machines. Meaning Windows 10 machines from the release date of Windows 10 (IIRC, July something). Have a bug in their Secure Boot code that doesn?t correctly validate third-party WHQL signed drivers. It took a bit a reverse engineering for me to understand this. The approach I had to take was install a driver that was signed before the release date of Windows 10 (Microsoft allows drivers to load that were signed before that date legacy support). The way I detected it was keying in on the .efi file versions, since that is where the bug originated.
Does the above sound like it would fit your machine?
It went into a loop of “starting Diagnostics” & “Could not start diagnostics” and to the advanced startup screen. The issue makes sense to me - during the trial and error of attempting different inf files - I had one where I forgot to change the StartType from 0 to 3. So, I told the machine that this driver was required for bootup. Second, the driver of course was not signed at that time - because I was trying to get something to submit for Microsoft to sign it. So, the machine couldn’t boot because it had an unsigned driver that was required at bootup. So, to boot up - I disabled the signing verification, and it booted “normally”. Once booted, I deleted the .sys file from the system32/drivers verification - however, I still have a strange behavior. Once the sys file is “loaded” from the application, I can’t copy over the .sys file with another one. It seems that the OS has recognized this sys file as running, and the file can’t be copied over - gives the normal File in User error. This only happens on my computer - which I ran the “install” on the INF file. This doesn’t happen on other machines I deploy my software to with this new Microsoft signed sys file. – Yes, that last sentence is to say that it seems to be signed correctly, and works on other machines - including a Windows 7 machine. THANKS SO MUCH. It’s a minor annoyance on my machine. I’ve looked through regedit, and my device manager for any reference to my sys file, I can’t find it - or the copy&paste error from the example, which had the name with the “%” surrounding my driver name. At this point, the issue is a small, annoying price to pay for the success of actually getting the driver signed. So, thanks for pointing me in the right direction.
Johnny, thanks for the reply. No, I don’t think that applies to this machine, I booted up with the 3rd party signed driver and it booted up fine, it’s when the driver isn’t signed is when the machine won’t boot. If I delete the file, no problem. However, the issue that shows that is slightly more than annoying is that once my application uses this driver, then that driver won’t be reloaded with a new installation of my application. The file can be overwritten, so that’s good, but I have to reboot to test it. I don’t do this often, but I was making sure that I could reproduce the customers issue, and I built my installer without the signed version of my driver, and my file still work. I think this is a result of me “installing” it with the INF file - this doesn’t occur with other machines.
