INF File Driver Installation

NTDEV
1

I apologize for yet another post, hopefully this will be my last. I have spent few hours and can’t figure out why I cannot install my driver using my INF file.
The error message I receive:

“The specified location does not contain information about your hardware”

I use the Add Hardware Wizzard, and I specify ‘Have a Disk’ and pick the vjoy.inf file manually.

This is a virtual device driver, there’s no physcial device attached. I know I could try devcon but I want to be able to use the WinXP Add Hardware wizzard unless that’s not possible … ??

FYI:
By looking at the examples, the drivers have .rc file - for my driver I did not create.rc file, but do I really need that file? Is that what is causing the error?

Details:

  • HID Class miniport Virtual Joystick Driver (check build, compiled for WinXP 32-bit)
  • Target machine VM WinXP x86
  • Driver, and related files copied to target machine on desktop (vjoy.inf, hidkmdf.sys, vjoy.sys, WdfCoInstaller01009_chk.dll)
  • Vendor ID, Product ID do match between the descriptor and the INF file:
    They are defined in the header as:

#define VENDOR_ID 0x1234
#define PRODUCT_ID 0xABCD
#define VERSION_NO 0x0001

Here’s my inf file (based on hidusbfx2\sys):

[Version]
Signature=“$CHICAGO$”
Class=HIDClass
ClassGuid={745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Provider=%VENDOR%
LayoutFile=layout.inf
DriverVer=07/05/2011,6.1.7600.16385
CatalogFile=kmdfsamples.cat

[SourceDisksFiles]
vjoy.sys = 99
hidkmdf.sys = 99

[SourceDisksNames]
99 = %DISK_NAME%,“”

[DestinationDirs]
CopySystemSysFiles = 12
CopyFunctionDriver = 12
CopyFilterDriver = 12
CopyFilesDLL = 11

[Manufacturer]
%VENDOR%=Vendor, NTx86, NTx86.6.1

; For Win2K
[Vendor]
%vjoy% = vjoy.Inst, HID\VID_1234&PID_ABCD&REV_0001

; For XP and later
[Vendor.NTx86]
%vjoy% = vjoy.Inst,HID\VID_1234&PID_ABCD&REV_0001

; For Win7 and later so that we can use inbox HID-KMDF mapper
[Vendor.NTx86.6.1]
%vjoy% = vjoy.Inst.Win7, HID\VID_1234&PID_ABCD&REV_0001

;===============================================================
; vjoy for Win2K thru Vista
;===============================================================
[vjoy.Inst.NT]
CopyFiles = CopySystemSysFiles, CopyFunctionDriver, CopyFilterDriver, CopyFilesDLL

[vjoy.Inst.NT.HW]
AddReg = vjoy_Parameters.AddReg

;
; hidkmdf is the function driver and vjoy is the lower filter
;
[vjoy.Inst.NT.Services]
AddService = hidkmdf,hidkmdf_Service_Inst,
AddService = vjoy,0x00000002, vjoy_Service_Inst

[CopyFunctionDriver]
hidkmdf.sys

[vjoy_Parameters.AddReg]
HKR,“UpperFilters”,0x00010000,“hidkmdf”

[hidkmdf_Service_Inst]
DisplayName = %hidkmdf.SVCDESC%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\hidkmdf.sys
LoadOrderGroup = PNP Filter

;===============================================================
; vjoy for Win7
; Instead of using hidkmdf.sys as a filter, use the inbox
; mshidkmdf.sys as a mapper filter
;===============================================================
[vjoy.Inst.Win7.NT]
; Just copy the driver. No neeed to copy other system binaries.
CopyFiles = CopyFunctionDriver

[vjoy.Inst.Win7.NT.HW]
AddReg = vjoy_Win7_Parameters.AddReg

;
; hidkmdf is the function driver and vjoy is the lower filter
;
[vjoy.Inst.Win7.NT.Services]
AddService = vjoy,0x00000002, vjoy_Service_Inst

[vjoy_Win7_Parameters.AddReg]
HKR,“UpperFilters”,0x00010000,“mshidkmdf”

;===============================================================
; Sections common to all OS versions
;===============================================================

[CopySystemSysFiles]
HidClass.sys,0x00000010 ;COPYFLG_NO_OVERWRITE (for win2k)
HidParse.sys,0x00000010 ;COPYFLG_NO_OVERWRITE (for win2k)

[CopyFunctionDriver]
vjoy.sys

[CopyFilesDLL]
Hid.dll,0x00000010 ;COPYFLG_NO_OVERWRITE (for win2k)

[vjoy_Service_Inst]
DisplayName = %vjoy%
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_IGNORE%
ServiceBinary = %12%\vjoy.sys

;================================================================
;— WDF Coinstaller installation ------
;
[DestinationDirs]
vjoy.Inst_CoInstaller_CopyFiles = 11

[vjoy.Inst.NT.CoInstallers]
AddReg=vjoy.Inst_CoInstaller_AddReg
CopyFiles=vjoy.Inst_CoInstaller_CopyFiles

[vjoy.Inst_CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller01009_chk.dll,WdfCoInstaller”

[vjoy.Inst_CoInstaller_CopyFiles]
WdfCoInstaller01009_chk.dll,0x00000010 ;COPYFLG_NO_OVERWRITE (for win2k)

[SourceDisksFiles]
WdfCoInstaller01009_chk.dll=99 ; make sure the number matches with SourceDisksNames

[vjoy.Inst.NT.Wdf]
KmdfService = vjoy, vjoy_wdfsect
[vjoy_wdfsect]
KmdfLibraryVersion = 1.9

[Strings]
; *******Localizable Strings*******
VENDOR = “HTML Splash”
vjoy = “Virtual Joystick Device”
DISK_NAME = “Virtual Joystick Device Install Disk”
hidkmdf.SVCDESC = “Filter Driver Service for HID-KMDF Interface layer”

; *******Non Localizable Strings*******

SERVICE_BOOT_START = 0x0
SERVICE_SYSTEM_START = 0x1
SERVICE_AUTO_START = 0x2
SERVICE_DEMAND_START = 0x3
SERVICE_DISABLED = 0x4

SERVICE_KERNEL_DRIVER = 0x1
SERVICE_ERROR_IGNORE = 0x0
SERVICE_ERROR_NORMAL = 0x1
SERVICE_ERROR_SEVERE = 0x2
SERVICE_ERROR_CRITICAL = 0x3

REG_EXPAND_SZ = 0x00020000
REG_DWORD = 0x00010001
REG_MULTI_SZ = 0x00010000
REG_BINARY = 0x00000001
REG_SZ = 0x00000000

2

One more thing:

The inf file specifies the catalog file (.cat). I did not sign my driver with a test certificate. Is that may be the cause of all this?

3

The first things I do when I have similar problems (and I DO have them all the time):

  • Examine the logs (setupapi.dev.log, setupapi.app.log)

  • Run the INF through checkinf

ALSO… are you running the checked build of the OS on the target machine? Because unless something’s changed, that’s the ONLY time you should be using “WdfCoInstaller01009_chk.dll” – In fact, frankly, I don’t recommend you use the checked version of the co-installer at all. If you DO want to use the checked version of the co-installer, you have to rename it to remove the “_chk” part of the name, also, IIRC.

So, my advise would be to (a) do a quick repeat of an attempted install (after changing your INF file) NOT trying to use the checked version of the co-installer, and if that works you set… otherwise (b) consult the logs, and (c) run your INF through CHKINF.

If your problem gets fixes or not, please do report back.

Peter
OSR

4

Thanks so much Peter. I will get home tonight and try your suggestions.
I have looked at the logs prior to posting and there was nothing logged so that’s why I posted.

The target machine is NOT checked build of win XP,- its a retail copy of win XP. That maybe it.

I will follow you recommendations and rebuild the driver using non checked build and use non checked build of co-installer.

5

xxxxx@hotmail.com wrote:

This is a virtual device driver, there’s no physcial device attached. I know I could try devcon but I want to be able to use the WinXP Add Hardware wizzard unless that’s not possible … ??
…
Details:

  • HID Class miniport Virtual Joystick Driver (check build, compiled for WinXP 32-bit)
  • Target machine VM WinXP x86
  • Driver, and related files copied to target machine on desktop (vjoy.inf, hidkmdf.sys, vjoy.sys, WdfCoInstaller01009_chk.dll)
  • Vendor ID, Product ID do match between the descriptor and the INF file:
    They are defined in the header as:

#define VENDOR_ID 0x1234
#define PRODUCT_ID 0xABCD
#define VERSION_NO 0x0001

WHAT descriptor? In order for your INF to be used and your driver to be
loaded, some component must create a PDO with the hardware ID
HID\VID_1234&PID_ABCD&REV_0001, so that it can go searching for a
driver. Who is going to create that? “devcon install” will do it.

;
; hidkmdf is the function driver and vjoy is the lower filter
;
[vjoy.Inst.NT.Services]
AddService = hidkmdf,hidkmdf_Service_Inst,
AddService = vjoy,0x00000002, vjoy_Service_Inst

Your comments do not match your INF. The “2” flag in the AddService
line identifies the function driver for the device. The entire INF is
configured so that “vjoy” is the function driver, with “mshidkmdf” as an
upper filter. You don’t define “mshidkmdf” in this INF file, and the
“hidkmdf” service is never mentioned.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

>WHAT descriptor? In order for your INF to be used and your driver to be
loaded, some component must create a PDO with the hardware ID
HID\VID_1234&PID_ABCD&REV_0001, so that it can go searching for a
driver. Who is going to create that? “devcon install” will do it.

The HID descriptor returned by my mini driver in response to IOCTL_HID_GET_DEVICE_DESCRIPTOR.
Thats where I set the VID, PID.
The windows supplied HID class driver and my supplied vjoy miniport driver are the function driver (actually HID class + shim driver (hidkmdf.sys) are function driver but my vjoy driver is filter driver right underneath it <– that’s the only way to write miniport driver in KMDF).

I don’t exactly know what happens behind the scenes when you go through the Add Hardware wizard and manually pick the .inf file for the driver in a scenario where you are installing FILTER DRIVER that is used by HID class driver in the same device stack.

Since my driver interacts with the HID class driver I thought that would be sufficient to load my mini-port driver and get the rest of the information from it. Since the HID class driver is the FDO and my driver is a filter driver should I worry about having devcon create a PDO here, there has to be a PDO associated with HID class driver.

If some one could elaborate more on this it would be of great help.

Your comments do not match your INF. The “2” flag in the AddService
line identifies the function driver for the device. The entire INF is
configured so that “vjoy” is the function driver, with “mshidkmdf” as an
upper filter. You don’t define “mshidkmdf” in this INF file, and the
“hidkmdf” service is never mentioned.

Here’s the setup:
HID class driver + hidkmdf (mini-port driver) = function driver
vjoy = lower filter driver underneath the function driver

Based on the above setup the comments are are actually correct and so is the rest of the setup lines based on the sample ‘hidusbfx2’. I am not sure why my lower filter driver is setup that way but I assure that’s correct unless the WDF samples are wrong.

7

>some component must create a PDO with the hardware ID
HID\VID_1234&PID_ABCD&REV_0001, so that it can go searching for a
driver. Who is going to create that?

Windows’ HID class driver?
The filter lives in the same device stack as the HID class driver, that’s my understanding.

8

Correction:

I wrote:

The HID descriptor returned by my mini driver in response to
IOCTL_HID_GET_DEVICE_DESCRIPTOR.

No, that’s not correct!
The PID, VID are set on HID device attributes in response to IOCTL_HID_GET_DEVICE_ATTRIBUTES which HIDCLASS sends as part of its processing of the IRP_MN_START_DEVICE request and conceivably other times to obtain information that a USB device records in its
device descriptor.

9

> You don’t define “mshidkmdf” in this INF file, and the
“hidkmdf” service is never mentioned.

mshidkmdf is build into win7 and later.
hidkmdf is mentioned under ‘vjoy for Win2K thru Vista’ section.

10

xxxxx@hotmail.com wrote:

The HID descriptor returned by my mini driver in response to IOCTL_HID_GET_DEVICE_DESCRIPTOR.
Thats where I set the VID, PID.

But who is going to load that?

In a typical USB HID stack, the USB driver will create a PDO with the
USB name (USB\VID_1234&PID_5678). That causes the usbhid driver to be
loaded, which creates an FDO. THAT driver then creates a PDO for
HID\VID_1234&PID_5678, which loads a HID driver and responds to HID
requests. I think that lower infrastructure is missing in your
scenario, although perhaps I’ve just missed something.

mshidkmdf is build into win7 and later.
hidkmdf is mentioned under ‘vjoy for Win2K thru Vista’ section.

Yes, I see that now.

OK, it’s possible that, through my ignorance, I’m now doing more harm
than good. I’m going to back out and hope that someone more deeply in
the HID world will pick up.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

No problem Tim, I know you trying to help.
My understanding based on what I 've been reading in past months is that:

Bus driver enumerates the devices on its bus and create PDOs for each. Then foreach enumerated device a driver is loaded that will be the FDO for this device. So, bus driver creates PDOs, device driver creates FDO.

With HID class driver as explained to me by others it acts as a bus driver for TLCs (HID Top Level Collections) and creates PDOs for each. What I wrote is a lower kmdf filter driver for already present hid class driver.

I’ve been reading more on the HID stuff and how Windows matches the INF file is based by bus enumerator finds all connected devices to the bus and reads descriptor info from the hardware. That info must match what’s in the INF file.
Unfortunately, for my virtual device there’s no hardware, so I made up the VID, PID respectively and returned in response to IOCTL_HID_GET_DEVICE_ATTRIBUTES. Then I pray that magic happens and when I go through the wizard all goes well. I will try the suggestions by Peter and see if the cause is just the co-installer.

12

Update on my progress:

The BAD news (first):

Peter, I tried your suggestions by creating free build of my drivers and using free build of the co-installer. I also ran CheckINF which gave me 5 minor warnings (copyright info missing, etc). It did detect one major error for this section:

[vjoy.Inst.NT]
CopyFiles = CopySystemSysFiles, CopyFunctionDriver, CopyFilterDriver, CopyFilesDLL

It said CopyFilterDriver section was missing which is true so I removed it and the error went away (btw, the WDM sample has the same error in the INF file).

End result: The New Hardware wizard still gives me same error. No logs in Windows’ log files, no Kernel trace in DebugView, nothing, - just the error:

“The specified location does not contain information about your hardware”

The GOOD NEWS:

So I said, forget this, and went ahead with Tim’s suggestion using devcon.

I executed:

devcon install vjoy.inf “HID\VID_1234&PID_ABCD&REV_0001”

And it worked like a charm. Device appeared in Device Manager and my Kernel traces appeared in DebugView and all calls executed fine (Driver Entry, Device Add, etc.).
The device was installed as root device though (by looking at the device manager). Is that how the filter should be installed for the HID class driver?

I removed it using devcon remove and tried to install it using devcon update, nothing happened!

My pending questions:

What I would like to know why am I receiving this error message from Add Hardware Wizard when installing my driver by selecting my driver’s .inf file.?

Tim mentioned following:

In order for your INF to be used and your driver to be loaded, some component must create a PDO with the hardware ID HID\VID_1234&PID_ABCD&REV_0001, so that it can go searching for a
driver. Who is going to create that? “devcon install” will do it.

Tim, what I am confused is that my filter driver which just plugs into existing HID class device stack and filters do not have PDOs right?

How should I install my filter driver which just plugs in to HID class device stack? What’s the right way of installing a filter?

13

You need a root enumerated device to get your stack up and running. Devcon install will do this

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, July 06, 2011 3:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] INF File Driver Installation

No problem Tim, I know you trying to help.
My understanding based on what I 've been reading in past months is that:

Bus driver enumerates the devices on its bus and create PDOs for each. Then foreach enumerated device a driver is loaded that will be the FDO for this device. So, bus driver creates PDOs, device driver creates FDO.

With HID class driver as explained to me by others it acts as a bus driver for TLCs (HID Top Level Collections) and creates PDOs for each. What I wrote is a lower kmdf filter driver for already present hid class driver.

I’ve been reading more on the HID stuff and how Windows matches the INF file is based by bus enumerator finds all connected devices to the bus and reads descriptor info from the hardware. That info must match what’s in the INF file.
Unfortunately, for my virtual device there’s no hardware, so I made up the VID, PID respectively and returned in response to IOCTL_HID_GET_DEVICE_ATTRIBUTES. Then I pray that magic happens and when I go through the wizard all goes well. I will try the suggestions by Peter and see if the cause is just the co-installer.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

Just a small correction:

When I executed devcon update … the driver did not get installed as I stated but I got message back:
devcon failed.

15

>You need a root enumerated device to get your stack up and running. Devcon
install will do this

Thanks Doron, that’s fine, and it works that way but:

What I wrote is a filter driver that goes underneath HID class driver. What I imagined would happen is that it would appear as part of the HID class driver’s device stack. Clearly, that understanding is wrong.
How does my filter driver relate to the HID class driver? Does the HID class driver act as a bus driver for my filter driver? Does HID class then create the PDO for my filter driver and loads my driver? I read stuff on HID but did not find any documentation that details the relationship between the HID class driver and its filter driver (my KMDF mini-driver).

16

You’re flipped around. Yes, hidclass is a bus driver. It enumerates a child pdo per TLC. As a bus driver, there is a parent or child role for each devobj. Your filter sits below the parent hidclass devobj. That parent devobj also needs to have its own pdo enumerated by some driver to be in the pnp device tree. For a USB device , usbhub or usbccgp will enumerate the pdo. For your case, there is a system supplied bus driver which creates root enumerated devices. This root bus is what is creating the pdo that your filter and the parent hidclass devobj attach to. Devcon install tells the root bus driver to create such a pdo. Open device manager and view by connection , it should become clearer .

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, July 06, 2011 6:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] INF File Driver Installation

You need a root enumerated device to get your stack up and running. Devcon
install will do this

Thanks Doron, that’s fine, and it works that way but:

What I wrote is a filter driver that goes underneath HID class driver. What I imagined would happen is that it would appear as part of the HID class driver’s device stack. Clearly, that understanding is wrong.
How does my filter driver relate to the HID class driver? Does the HID class driver act as a bus driver for my filter driver? Does HID class then create the PDO for my filter driver and loads my driver? I read stuff on HID but did not find any documentation that details the relationship between the HID class driver and its filter driver (my KMDF mini-driver).

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

17

Thank you for your patience Doron.

I was looking at the Dev. Manager and I can see the parent/child relationship. I guess my confusion who is the parent and who is the child of the parent by looking at the device stack.

So if I got this straight:

Parent is the bus which enumerates PDOs for its children. The enumerated PDOs give rise to child device stacks. A parent bus can be a child to another bus.
In dev. manager at the top level are always parents and as you drill down, the device nodes below are the respective children.

Hopefully I got this right.

18

Doron,
I noticed that when I expanded my Vjoy device in device manager I see a question mark with caption ‘Unknow Device’. What’s that all about?

My driver does create a non-pnp legacy control device using WdfDeviceCreate. Is that what the Dev. Manager picks up? Or is it the fact that I did not impelement IOCTL_HID_GET_FEATURE/IOCTL_HID_GET_STRING?

19

What is the hardware and compact ids for the ?'ed unknown device ? It is not picking up the control device .

d

debt from my phone

-----Original Message-----
From: xxxxx@hotmail.com
Sent: Wednesday, July 06, 2011 9:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] INF File Driver Installation

Doron,
I noticed that when I expanded my Vjoy device in device manager I see a question mark with caption ‘Unknow Device’. What’s that all about?

My driver does create a non-pnp legacy control device using WdfDeviceCreate. Is that what the Dev. Manager picks up? Or is it the fact that I did not impelement IOCTL_HID_GET_FEATURE/IOCTL_HID_GET_STRING?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

20

>What is the hardware and compact ids for the ?'ed unknown device ?

When I create the control device I:

  • WdfControlDeviceInitAllocate( …, SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RW_RES_R);
  • WdfDeviceInitAssignName( …, “\Device\VJoy0”);
  • WdfDeviceCreate();
  • WdfDeviceCreateSymbolicLink( …, “\DosDevices\VJoy0”);

I don’t set anything else on it, I use purely the approach as in kbfilter WDM sample.

In device manager for this device, under ‘General’ tab only ‘Location’ shows info that this device is on my VJoy device everything else displays as ‘Unknown’.