Driver Ranking

NTDEV
1

Hello,

I have a USB HID Class device that uses Windows Vista HID Class driver. For some reasons I dont want to use the native Windows Vista HID Class Driver and want to load my own HID Miniport driver. To accomplish this I tried the following.

Using DriverPackageInstall() I preinstalled my driver and connected the deivce after the installation. But the setup loads the Windows Vista HID Class Driver instead of my driver because of the driver ranking.

Can anyone tell me how to make setup load my driver instead of Vista driver ?

Thank you
Surendra

2

I’m not entirely sure I understand your question, but if I do, then the
answer is “get your driver WHQL-certified”.

xxxxx@hotmail.com wrote:

Hello,

I have a USB HID Class device that uses Windows Vista HID Class driver. For some reasons I dont want to use the native Windows Vista HID Class Driver and want to load my own HID Miniport driver. To accomplish this I tried the following.

Using DriverPackageInstall() I preinstalled my driver and connected the deivce after the installation. But the setup loads the Windows Vista HID Class Driver instead of my driver because of the driver ranking.

Can anyone tell me how to make setup load my driver instead of Vista driver ?

Thank you
Surendra

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

3

Get your driver whql signed and the OS will pick yours over the inbox driver. Just curious, why do you need to have a custom hid miniport for a HID compliant device? Perhaps there is an easier way to solve your problem.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, November 08, 2007 12:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Ranking

Hello,

I have a USB HID Class device that uses Windows Vista HID Class driver. For some reasons I dont want to use the native Windows Vista HID Class Driver and want to load my own HID Miniport driver. To accomplish this I tried the following.

Using DriverPackageInstall() I preinstalled my driver and connected the deivce after the installation. But the setup loads the Windows Vista HID Class Driver instead of my driver because of the driver ranking.

Can anyone tell me how to make setup load my driver instead of Vista driver ?

Thank you
Surendra

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

4

Doron,

My device is a USB HID Mouse. It sends some special information in the reserved bits of mouse HID report. Windows HID class driver ignores these bits and there is no way an application can read these bits. Therefore we are writing HID Miniport driver to handle this.

Since our device is enumerated as USB HID Mouse, Windows selects default HID class driver. I have read that even if my driver is whql-signed windows will load the default driver because of its signature score. Also, we cannot go for whql-signing now since the driver is still in the development stage.

Any thoughts ?

Thanks
Surendra

5

Surendra wrote:

I have read that even if my driver is whql-signed windows will
load the default driver because of its signature score.

Not true at all. (It amazes me when Doron says something, and then people refute him or say, “are you sure?”)

Also, we cannot go for whql-signing now since the driver is
still in the development stage.

So rename input.inf to input._inf.

6

Hi Chris,

Can you please explain how renaming input.inf to input._inf will solve the problem?

Also, my comments on driver signing are based on reading the following from MSDN website.

http://msdn2.microsoft.com/en-us/library/aa477017.aspx

Signature Score (Windows Vista)

A driver rank is formatted as 0xSSGGTHHH, where the value of 0xSS000000 is the signature score, the value of 0x00GG0000 is the feature score, and the value of 0x0000THHH is the identifier score.

The signature score ranks a driver according to how the driver is signed, as follows:

Setup assigns the best signature score (lowest signature score value) to drivers that have a Microsoft signature for Windows Vista. All Microsoft signatures are assigned this best signature score. All else being equal in a driver rank, Setup will select the driver that is the best match from among those that have a Microsoft signature for Windows Vista. The Microsoft signature types include the following:

Premium WHQL signatures and standard WHQL signatures
Signatures for inbox drivers
Windows Sustained Engineering (Widows SE) signatures
A WHQL signature for a Windows version that is the same or later than the Windows version that is specified by the LowerLogoVersion value that is set for the device setup class of a driver.

Setup assigns the second best signature score to a driver that was signed by a third party using Authenticode technology or a driver that has a WHQL signature for a Windows version that is earlier than the version that is specified by the LowerLogoVersion value that is set for the device setup class of the driver. Valid third-party signature types include those signed using a code signing certificate from an Enterprise Certificate Authority (CA), those signed using a code signing certificate issued by a Class 3 CA, or those signed with a code signing certificate created by the MakeCert tool.

Setup assigns the third best signature score to driver packages that are unsigned, but the driver is installed by an INF DDInstall section that has an .nt platform extension.
Setup assigns the fourth best signature score to driver packages that are unsigned and the driver is not installed by an INF DDInstall section that has an .nt platform extension. In this case, the driver might be for Windows 95, Windows 98, or Windows Millennium.
Setup assigns the fifth and worst signature score (highest signature score value) to drivers for which the signing state is unknown.

For information about the system-defined SIGNERSCORE_Xxx constants that represent signature scores, see Signature Score Constants.

For more information about driver ranking , see How Setup Ranks Drivers (Windows Vista).

Thanks
Surendra

7

xxxxx@hotmail.com wrote:

My device is a USB HID Mouse. It sends some special information in the reserved bits of mouse HID report. Windows HID class driver ignores these bits and there is no way an application can read these bits. Therefore we are writing HID Miniport driver to handle this.

I’m amazed you would come to that conclusion. Why wouldn’t your first
choice be a filter driver? Leverage what already works before starting
over.

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

8

Surendra wrote:

Can you please explain how renaming input.inf to input._inf
will solve the problem?

If Windows can’t find the generic USB HID driver, it will load yours, no matter what the ranking is.

9

> If Windows can’t find the generic USB HID driver, it will load yours, no matter

what the ranking is.

I think this is good enough development and testing. But I still have to solve the problem for the final release.

MSDN documentation says “All Microsoft signatures are assigned this best signature score”. Does it mean even if I get whql-sign for my driver the signature socre would not better than the generic USB HID driver ?

10

Surendra wrote:

MSDN documentation says “All Microsoft signatures are assigned
this best signature score”. Does it mean even if I get whql-sign
for my driver the signature socre would not better than the
generic USB HID driver ?

As you’ve been told several times now, but for some reason you refuse to listen, getting your driver signed by WHQL will give it an equal signature score to the inbox driver.

Your driver will then ultimately be ranked higher because it will match your device’s hardware ID versus the inbox driver matching only the compatible ID.

11

I would like to strongly emphasize what Tim said. Write a KMDF based filter that sits below hidusb and retrieves your extra bits in the filter. If you can, put your extra bits into a separate top level collection and then you have no need for a device driver at all (I sometimes have a hard time wondering why folks would do something this crazy like implement a spec standard to use already written drivers and then put themselves in a hole by adding value in the wrong spots in firmware)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, November 09, 2007 9:51 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Driver Ranking

xxxxx@hotmail.com wrote:

My device is a USB HID Mouse. It sends some special information in the reserved bits of mouse HID report. Windows HID class driver ignores these bits and there is no way an application can read these bits. Therefore we are writing HID Miniport driver to handle this.

I’m amazed you would come to that conclusion. Why wouldn’t your first
choice be a filter driver? Leverage what already works before starting
over.

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

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

12

>If you can, put your extra bits into a separate top level collection and then you have no

need for a device driver at all (I sometimes have a hard time wondering why
folks would do something this crazy like implement a spec standard to use
already written drivers and then put themselves in a hole by adding value in the
wrong spots in firmware)

This device is already in the market and there is no way the firmware can be modified on the device.

13

How are you exposing your extra data in your HID miniport driver? The only sanctioned way is to modify the HID report descriptor to add a new top level collection (TLC) and send the extra bits through the extra TLC. What is much easier to do is write a lower filter in KMDF that enumerates its own raw PDO. You are then free to report your extra bits however you like, you are not restricted to formatting it as HID data. The stack would look like this

HIDClass+hidusb
|
Your filter
|
USB PDO

In the filter you can capture the bulk IN URBs in a completion routine and grab your data.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, November 09, 2007 8:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver Ranking

If you can, put your extra bits into a separate top level collection and then you have no
need for a device driver at all (I sometimes have a hard time wondering why
folks would do something this crazy like implement a spec standard to use
already written drivers and then put themselves in a hole by adding value in the
wrong spots in firmware)

This device is already in the market and there is no way the firmware can be modified on the device.

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