Preventing Default USB COmposite Device Driver Vista

Dear All,

For the HID complaint device, in-order to prevent the default Vista driver loading, I renamed input.inf and input.pnf files in driver store. So my custom driver got loaded.

The new device is a composite device with two interfaces for mouse and keyboard. So I commented usb.inf, usb.pnf along with input.inf,input.pnf files and my custom driver is loading correctly. My custom driver is for mouse interface only and I want default USB HID keyboard driver for second interface.

This renaming is working correctly on some systems(PCs). But in the case of some Laptops, the installation fails saying that it cannot find the driver for the keyboard.

I noticed the following differences in the driver store of the above two categories:

  1. Working case (PCs) has only input.inf, .pnf files exactly in only one location.
    C:\Windows\System32\DriverStore\FileRepository\input.inf_53578522

But in the case of Laptops, I find input.inf at the following locations:
C:\Windows\System32\DriverStore\FileRepository\input.inf_53578522
C:\Windows\System32\DriverStore\FileRepository\input.inf_3xxxxxxxx

  1. In working case, usb.inf, pnf were in
    C:\Windows\System32\DriverStore\FileRepository\usb.inf_c89fac9c

In laptops, usb.inf, pnf were in
C:\Windows\System32\DriverStore\FileRepository\usb.inf_c89fac9c
C:\Windows\System32\DriverStore\FileRepository\usb.inf_a79ff0aa
C:\Windows\System32\DriverStore\FileRepository\usb.inf_3be276b7

I tried renaming the files in all the above locations.
All the above three locations have usb.in, pnf, usbhub.sys, usbccgp.sys in them.

Any pointers to the different behaviour in driver loading.

What
Regards.

There is simply nothing right about what you are doing. Are you seriously
considering this a product?

On Fri, May 23, 2008 at 5:42 AM, wrote:

> Dear All,
>
> For the HID complaint device, in-order to prevent the default Vista driver
> loading, I renamed input.inf and input.pnf files in driver store. So my
> custom driver got loaded.
>
> The new device is a composite device with two interfaces for mouse and
> keyboard. So I commented usb.inf, usb.pnf along with input.inf,input.pnf
> files and my custom driver is loading correctly. My custom driver is for
> mouse interface only and I want default USB HID keyboard driver for second
> interface.
>
> This renaming is working correctly on some systems(PCs). But in the case
> of some Laptops, the installation fails saying that it cannot find the
> driver for the keyboard.
>
> I noticed the following differences in the driver store of the above two
> categories:
>
> 1. Working case (PCs) has only input.inf, .pnf files exactly in only one
> location.
> C:\Windows\System32\DriverStore\FileRepository\input.inf_53578522
>
> But in the case of Laptops, I find input.inf at the following locations:
> C:\Windows\System32\DriverStore\FileRepository\input.inf_53578522
> C:\Windows\System32\DriverStore\FileRepository\input.inf_3xxxxxxxx
>
> 2. In working case, usb.inf, pnf were in
> C:\Windows\System32\DriverStore\FileRepository\usb.inf_c89fac9c
>
> In laptops, usb.inf, pnf were in
> C:\Windows\System32\DriverStore\FileRepository\usb.inf_c89fac9c
> C:\Windows\System32\DriverStore\FileRepository\usb.inf_a79ff0aa
> C:\Windows\System32\DriverStore\FileRepository\usb.inf_3be276b7
>
> I tried renaming the files in all the above locations.
> All the above three locations have usb.in, pnf, usbhub.sys, usbccgp.sys in
> them.
>
> Any pointers to the different behaviour in driver loading.
>
> What
> Regards.
>
> —
> 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
>


Mark Roddy

This method is just for testing the driver. Once the driver gets loaded and the device functionality is verified, we need to apply for WHQL certification so that the renaming is not required.

And what is the installation mechanism going to be at that point?

You should be using a standard install process with test signed drivers.

On Fri, May 23, 2008 at 8:03 AM, wrote:

>
> This method is just for testing the driver. Once the driver gets loaded
> and the device functionality is verified, we need to apply for WHQL
> certification so that the renaming is not required.
>
>
>
> —
> 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
>


Mark Roddy

Thanks for immediate inputs and clarifications. I am pre-installing
the drivers using DPInst and selecting Install Anyway option in the
security dialog.

On Fri, May 23, 2008 at 6:05 PM, Mark Roddy wrote:
> And what is the installation mechanism going to be at that point?
>
> You should be using a standard install process with test signed drivers.
>
> On Fri, May 23, 2008 at 8:03 AM, wrote:
>>
>> This method is just for testing the driver. Once the driver gets loaded
>> and the device functionality is verified, we need to apply for WHQL
>> certification so that the renaming is not required.
>>
>>
>>
>> —
>> 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
>
>
>
> –
> Mark Roddy — 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

xxxxx@gmail.com wrote:

This method is just for testing the driver. Once the driver gets loaded and the device functionality is verified, we need to apply for WHQL certification so that the renaming is not required.

For testing the driver, it seems to me like it would be MUCH easier to
let the standard system driver get assigned, then go hack the registry
in the CCS\Control\Enum\USB subkey to change the Service to your own.
No INF renaming required.


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

Tim Roberts wrote:

For testing the driver, it seems to me like it would be MUCH easier
to let the standard system driver get assigned, then go hack the
registry in the CCS\Control\Enum\USB subkey to change the Service
to your own. No INF renaming required.

This won’t work if the inbox driver is in a different setup class than your custom driver.