WHQL fails with "Failed to get primary INF, error 0x00000490" on driver PDO device

I get this peculiar error from WHQL tests on a kernel mode driver.

The driver creates a PDO for user mode programs to communicate with it. The code to create this PDO follows that in kbfiltr from the sample code save creating a SpinLock & a ring buffer.

The driver is a mouse class driver, PnP driver. (Mouse drivers are typically not necessary, but we need it as there are some bugs in the HID reports sent by the device firmware that need to be addressed).

Research on the Net did not yield anything specific regarding this message.

Anyone else encountered this error? What could be the root cause?

TIA

Hari

What test is returning this error and for what devices?
This error could mean the element being requested is missing.

It’s a mouse class drive driver. It’s a function driver rather than a filter driver as in the ‘kbfiltr’ sample in DDK.

The PDO is used by the user mode agent to customize the behavior of the driver as necessary. The PDO code follows the rawpdo.c in that sample very closed, save for creating an extra spin lock and a WDF queue for posting events to the user mode agent.

Did you create another INF (not in the mouse or hid device class) that installs the “null” driver on the raw PDO?

@Doron_Holan said:
Did you create another INF (not in the mouse or hid device class) that installs the “null” driver on the raw PDO?

No I didn’t. From what I can see, the sample code kbfiltr doesn’t do that either. Or did I miss something?

Does that mean that raw PDO needs its own INF? Can this be combined with the device INF file?

A raw PDO does not need an INF file. No FDO will be loaded. However, the PDO has to be marked as “raw”. You’re still calling WdfPdoInitAssignRawDevice?

@Tim_Roberts said:
A raw PDO does not need an INF file. No FDO will be loaded. However, the PDO has to be marked as “raw”. You’re still calling WdfPdoInitAssignRawDevice?

Yes. But the DeviceClassGuid set to GUID_DEVCLASS_UNKNOWN (unlike kbfiltr which passes GUID_DEVCLASS_KEYBOARD). This is following the Note for this parameter in the doc:
“You should always specify a custom class GUID. You should not specify an existing class GUID. If you specify an existing class GUID, other drivers that attempt to specify that existing class GUID might fail to install or might install with incorrect security settings.”

However, in the Remarks there is this:
" The DeviceClassGuid parameter only identifies a section of the registry and does not actually set the device setup class for the device. The INF Version section in your device and driver’s INF file sets the device setup class. Typically, the DeviceClassGuid parameter’s GUID should match the GUID that the INF Version section specifies."

And in the Examples at the bottom of the doc, WdfPdoINitAssignRawDevice is called with a custom GUID.

So what is the correct argument for this?

Could this be the problem why the WHQL test fails?

Thanks a lot, both Doron & Tim for responding. Appreciate it.

Going through the various samples, I also notice that the usb/kmdf_enum_switches/sys sample also creates a PDO.

But this samples supplies a custom GUID as the deviceclass and its INF has the following entries where the custom GUID is specified:

[OSR.NT$ARCH$]
%USB\VID_045E&PID_930A.DeviceDesc%=kmdf_enumswitches.Dev, USB\VID_0547&PID_1002
%Switch.DeviceDesc%=Switch.Dev, {6FDE7521-1B65-48ae-B628-80BE62016026}\OsrUsbFxRawPdo


[kmdf_enumswitches.Dev.NT]
CopyFiles=kmdf_enumswitches.Files.Ext

[Switch.Dev.NT]
;dummy section

[Switch.Dev.NT.Services]
AddService = , %SPSVCINST_ASSOCSERVICE%, 

{6FDE7521-1B65-48ae-B628-80BE62016026} is the custom deviceclass GUID value supplied to WdfPdoInitAssignRawDevice.

Update:

I ran the WHQL tests using GUID_DEVCLASS_MOUSE & custom GUID with the necessary modifiers as per the kmdf_enum_switches/sys sample. In both cases I get the same error.

Can you ignore this test? This test shouldn’t be running on your PDO. I’ve checked in a change on my end to not throw an error in the future.

@Zac_Lockard said:
Can you ignore this test? This test shouldn’t be running on your PDO. I’ve checked in a change on my end to not throw an error in the future.

Thanks Zac.

Just to clarify – so we can ignore the “DF - InfVerif INF Verification” test on the PDO? All tests pass except for this particular one.

As for your comment on checking in a change – does it mean that if we submit the drivers for formal verification, it’ll pass?

Yes, you can ignore the test. And yes I believe it will pass a formal submission, but if there are any issues I will waive this test for a device that has no driver