Hello, I am trying to validate my driver with the Windows Hardware Lab Kit. My driver is a simple KMDF DMA driver for a PCI-e device. One of the tests that are failing is the ApiValidator. Specifically, the failure is this:
XXX.sys has unsupported API call to “ntoskrnl.exe!KeGetCurrentIrql”
I looked throughout my code and KeGetCurrentIrql is not in use anywhere. I also made sure to remove any calls to PAGED_CODE, because that calls KeGetCurrentIrql. I tried to check in Dependency Walker to see if the function is called, but I’m not seeing it in any of the import lists. What am I doing wrong here? Is there some way that I can determine where this function is called?
Hmmmm… this is strange. I mean, the REAL question here is why KeGetCurrentIrql is an “unsupported API” – I mean, it’s even part of the “Universal” driver set, for goodness sakes.
Peter
@“Peter_Viscarola_(OSR)” said:
Hmmmm… this is strange. I mean, the REAL question here is why KeGetCurrentIrql is an “unsupported API” – I mean, it’s even part of the “Universal” driver set, for goodness sakes.
Peter
I do see these messages:
Binary located at “C:\Windows\System32\DriverStore\FileRepository\XXX.inf_amd64_b2776785c1011672” is NOT Universal
“C:\Windows\System32\DriverStore\FileRepository\XXX.inf_amd64_b2776785c1011672” is NOT Universal
NOT all binaries are Universal
You can use https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/building-for-onecore as a reference on how to build a driver for Onecore.
Make sure that the driver package or binary matches the Supported Api file Architecture. Use the x64 version of UniversalDDIs.xml with the X64 driver or binary file.
Perhaps that is related somehow?
Universal is the most restrictive api set. Also it is likely that the call to KeGetCurrentIrql is inside a macro that is masquerading as a function, or an inline function, which is why dependency tools aren’t going to show it. It is a core kernel function. It’s used all over the place. The fact that apivalidator is now flagging it is disturbing, however the whql tests and tools have been consistently a nightmare for as long as I can remember.
I think based on the other error messages, my INF file wasn’t identifying the driver as being part of the Universal API set. So I ran “infverif /w” on the INF file for the driver and it returned this error:
XXX.inf, line 78: Destination file path ‘C:\WINDOWS\System32\drivers’ for file ‘XXX.sys’ is not isolated to DIRID 13.
The problem stemmed from this line in the INF file:
[DestinationDirs]
DefaultDestDir = 12
As well as this line:
ServiceBinary = %12%$SYSNAME
I changed the "12"s to "13"s and reran the test. It succeeded.
The other thing to do… which is what I would do… is just change the target from Universal to Desktop.
I do not believe that Universal is even “a thing” anymore… IIRC, it’s been deprecated and replaced by “Windows Driver”, which means who-knows-what this week.
So, just forget the whole Universal thing, and target the misleadingly named “Desktop” – which will work for desktop, server, or IOT…
Peter
And… just sayin’…
From the Doc Page for KeGetCurrentIrql:
IN NO WAY, and in no world, should KeGetCurrentIrql be disallowed anywhere. There’s a bug somewhere.
Like I said… ignore “universal”…
Peter
