Override generic parent driver for USB composite devices?

NTDEV
1

I am working on a driver for a composite device that contains two USB interfaces. Despite this separation (which is defined in the hardware and cannot be changed), these two functions are actually dependent upon one another, and I need to facilitate communication between them from within my driver. My driver must therefore be applied to the composite device as a whole, and not to the individual interfaces.

Unfortunately, when the device is first plugged in (prior to my INF being installed to the driver store), Windows assigns the “USB Composite Device” driver to my device, and attempts to find matching drivers for each of the individual interfaces. This operation is certainly understandable, as my driver is not yet installed for Windows to search against at that point. However, this creates a situation in which I need to replace/update the driver selection for the top-level USB device so that it uses my driver. My question, then, is:

Is there some *friendly* way for the end user to select my INF for the whole device after Windows has already automatically assigned the generic parent driver for it? In particular, is there any way to utilize the existing hardware wizards that pop up for the interfaces, but have them use the provided INF to override the selection of the parent driver?

During my development and testing, I have simply been going into Device Manager, selecting “Update driver” for the parent “USB Composite Device” entry, and pointing it at my driver. Unfortunately, this type of installation procedure is a poor user experience for the customer, and creating an installer to pre-install our driver package is not an option for our particular deployment.

2

Without an installer or app to automate the updating of the driver or preinstalling the driver package on the machine, the user gong to the UI is the only option.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@cspeed.com
Sent: Monday, February 13, 2012 2:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Override generic parent driver for USB composite devices?

I am working on a driver for a composite device that contains two USB interfaces. Despite this separation (which is defined in the hardware and cannot be changed), these two functions are actually dependent upon one another, and I need to facilitate communication between them from within my driver. My driver must therefore be applied to the composite device as a whole, and not to the individual interfaces.

Unfortunately, when the device is first plugged in (prior to my INF being installed to the driver store), Windows assigns the “USB Composite Device” driver to my device, and attempts to find matching drivers for each of the individual interfaces. This operation is certainly understandable, as my driver is not yet installed for Windows to search against at that point. However, this creates a situation in which I need to replace/update the driver selection for the top-level USB device so that it uses my driver. My question, then, is:

Is there some *friendly* way for the end user to select my INF for the whole device after Windows has already automatically assigned the generic parent driver for it? In particular, is there any way to utilize the existing hardware wizards that pop up for the interfaces, but have them use the provided INF to override the selection of the parent driver?

During my development and testing, I have simply been going into Device Manager, selecting “Update driver” for the parent “USB Composite Device” entry, and pointing it at my driver. Unfortunately, this type of installation procedure is a poor user experience for the customer, and creating an installer to pre-install our driver package is not an option for our particular deployment.

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

3

Thanks for the quick response, Doron.

Is there any way that I could update the driver for the parent device from an INF targeted at an interface? For instance, suppose that I modified my INF such that it also matched the child interfaces (by adding models for &Mi_00 and &Mi_01). If I provide that INF to the wizard that pops up for one of the child interfaces, is there some INF directive that can be used to tell Windows that it is the parent driver that should be updated to use this INF (and that I don’t actually want to apply this to the interface whose wizard I’m using)?

Alternatively, are there any user-friendly ways to pre-install a driver without providing an installer? For instance, can Control Panel –> Add Hardware be used to install the INF before the device has been plugged in? (When I tried this out and selected “No, I have not added the hardware yet”, the wizard tells me that I should connect the hardware before running the wizard. This is problematic because connecting the hardware first will result in the USB Composite Device driver being selected, which defeats the point.)

Or, once the USB Composite Device driver has already be automatically installed, is there some user-friendly way to update/replace the driver through an existing wizard (rather than by going to Device Manager, navigating to the parent device through the “by connection” view, and selecting “Update Driver”)?

4

Look at dp_inst and devcon update for cmd line tools that accomplish the same things.

d

debt from my phone

From: xxxxx@cspeed.com
Sent: 2/13/2012 4:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Override generic parent driver for USB composite devices?

Thanks for the quick response, Doron.

Is there any way that I could update the driver for the parent device from an INF targeted at an interface? For instance, suppose that I modified my INF such that it also matched the child interfaces (by adding models for &Mi_00 and &Mi_01). If I provide that INF to the wizard that pops up for one of the child interfaces, is there some INF directive that can be used to tell Windows that it is the parent driver that should be updated to use this INF (and that I don’t actually want to apply this to the interface whose wizard I’m using)?

Alternatively, are there any user-friendly ways to pre-install a driver without providing an installer? For instance, can Control Panel –> Add Hardware be used to install the INF before the device has been plugged in? (When I tried this out and selected “No, I have not added the hardware yet”, the wizard tells me that I should connect the hardware before running the wizard. This is problematic because connecting the hardware first will result in the USB Composite Device driver being selected, which defeats the point.)

Or, once the USB Composite Device driver has already be automatically installed, is there some user-friendly way to update/replace the driver through an existing wizard (rather than by going to Device Manager, navigating to the parent device through the “by connection” view, and selecting “Update 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

5

I appreciate your patience in assisting me with my needs. I suppose it may be inevitable that I will have to use an installer (DPInst or otherwise) to get the results that I am looking for.

Before I surrender to the installer approach, though, I would like to pose one last question on the topic. First, let me describe the ideal deployment scenario. Ultimately, our driver will be WHQL tested and available through Windows Update. This would be the preferred means of distribution: rather than directly providing our users with a driver package, they would simply plug in the device and let Windows Update search for the best available driver when the new hardware wizard prompts pop up. Unfortunately, I suspect that this online driver search only applies to the individual interfaces for which the wizard pops up (please correct me if I am wrong in this assumption!), and not for the top-level USB device for which Windows will have presumably already found a match (the USB Composite Device driver).

So, is there any way to distribute a driver for a custom composite device on Windows Update such that it will actually be matched and applied to the top-level USB device when the device is plugged in for the first time?

6

/*While Doron and the real USB gurus are pondering over their answers +/

Maybe you can make a coinstaller for the child device which will update the parent driver.

–pa

7

WU can update the parent too if your ibf matches on a hardware id. This is how the Bluetooth driver works. Should these two interdependent interfaces be enumerated as one instead? Have you looked at the IAD?

d

debt from my phone

From: xxxxx@cspeed.com
Sent: 2/14/2012 5:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Override generic parent driver for USB composite devices?

I appreciate your patience in assisting me with my needs. I suppose it may be inevitable that I will have to use an installer (DPInst or otherwise) to get the results that I am looking for.

Before I surrender to the installer approach, though, I would like to pose one last question on the topic. First, let me describe the ideal deployment scenario. Ultimately, our driver will be WHQL tested and available through Windows Update. This would be the preferred means of distribution: rather than directly providing our users with a driver package, they would simply plug in the device and let Windows Update search for the best available driver when the new hardware wizard prompts pop up. Unfortunately, I suspect that this online driver search only applies to the individual interfaces for which the wizard pops up (please correct me if I am wrong in this assumption!), and not for the top-level USB device for which Windows will have presumably already found a match (the USB Composite Device driver).

So, is there any way to distribute a driver for a custom composite device on Windows Update such that it will actually be matched and applied to the top-level USB device when the device is plugged in for the first time?

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

8

Frank Jenner wrote:

So, is there any way to distribute a driver for a custom
composite device on Windows Update such that it will
actually be matched and applied to the top-level USB
device when the device is plugged in for the first time?

Why not monkey with your descriptors so that the USB\COMPOSITE compatible ID is never applied in the first place, and thus usbccgp is never loaded? This would give your users a chance to hit Windows Update.

Recommended reading:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff537109

9

The hardware that we are using does not have any IADs, nor do we have control over the USB descriptors (other than VID/PID and strings). As far as our INF goes, we are currently matching the hardware ID based on VID/PID. However, we could add models for VID/PID/bInterfaceNumber if you think that there may be something useful that we could do by making the INF match the interfaces (although we will ultimately need to control both interfaces in the same driver).

You noted that Windows Update can be used to update the parent. I’m supposing you meant that it will search Windows Update if you manually choose to update the driver after Windows has already assigned the USB Composite Device driver. What we’re looking to deal with right now is the driver installation during the initial attachment of the device.

This is my current understanding of what Windows will do the first time that our device is plugged in (assuming that our driver exists on Windows Update). Please let me know if I overlooked something or if I appear to be misunderstanding something.

1.) Windows detects that a new device has been connected and searches for a matching driver:
2.) Windows searches the local driver store for INFs with matching hardware IDs. Since our INF has not yet been introduced to the system, it will not find a match.
3.) Windows searches the local driver store for INFs with matching compatible IDs. Due to our hardware settings (class, subclass, number of interfaces, etc.) our device will match against the Composite USB Device driver.
4.) Windows installs the Composite USB Device driver for our device, which enumerates two child devices corresponding to the two USB interfaces.
5.) Windows detects these new devices, and searches for drivers for each one:
6.) Windows searches the local driver store for INFs with matching hardware IDs for a child interface. No INFs should already exist with this hardware ID, so there will be no match.
7.) Windows searches the local driver store for INFs with matching compatible IDs for a child interface. The child interfaces are not part of a standard USB class, so there will be no match.
8.) Because no suitable driver could be found, Windows pops up the found new hardware wizard prompt to allow the user to specify a driver file for the child interface.
9.) At the prompt, the user opts to search Windows Update.
10.a.) No suitable driver will be found on Windows Update, because our driver matches against VID/PID, whereas the device for which the wizard appeared is providing VID/PID/interface.
10.b.) Presumably, if our driver actually did match against VID/PID/interface, Windows Update would find a driver, but that driver would be installed for each interface individually, rather than for the whole device.

That said, is there any way that Windows Update could interject before step (3) such that my driver (again, assuming that it’s already up on Windows Update) will be found and selected before the USB Composite Device driver? Alternatively, if Windows searches Windows Update per step (10.b), is there some way that my driver can be applied to the parent device during this step, or can it only be applied to the child interfaces because those were the “devices” that actually invoked the wizard?

Also, I looked into DPInst, as per your suggestion. This is definitely a great solution for deploying the driver (with DPInst) directly to customers. However, because I cannot guarantee that our users will install the driver before plugging in any hardware, I’m wondering if DPInst packages can be distributed/run from Windows Update during the found new hardware wizard. If so, it seems like I could force my INFs to match also against VID/PID/interface so that when the child interfaces search Windows Update, they will download/run my DPInst package, which will then replace the parent driver with my intended driver. Is this possible? If so, is it an appropriate practice? (I’m still somewhat unclear on the correct procedure for deploying a custom composite device driver through Windows Update such that it will be retrieved when the device is first connected.)

10

Why not have your driver match both interfaces?

Mark Roddy

On Tue, Feb 14, 2012 at 8:44 AM, wrote:
> I appreciate your patience in assisting me with my needs. I suppose it may be inevitable that I will have to use an installer (DPInst or otherwise) to get the results that I am looking for.
>
> Before I surrender to the installer approach, though, I would like to pose one last question on the topic. First, let me describe the ideal deployment scenario. Ultimately, our driver will be WHQL tested and available through Windows Update. This would be the preferred means of distribution: rather than directly providing our users with a driver package, they would simply plug in the device and let Windows Update search for the best available driver when the new hardware wizard prompts pop up. Unfortunately, I suspect that this online driver search only applies to the individual interfaces for which the wizard pops up (please correct me if I am wrong in this assumption!), and not for the top-level USB device for which Windows will have presumably already found a match (the USB Composite Device driver).
>
> So, is there any way to distribute a driver for a custom composite device on Windows Update such that it will actually be matched and applied to the top-level USB device when the device is plugged in for the first time?
>
> —
> 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

11

>> Why not have your driver match both interfaces?

In my driver, I need to facilitate communication between the two interfaces (i.e., some event occurs on one interface, in response to which I need to send some data to the other interface, and vice versa). If these interfaces are handled as separate devices, then I would have to deal with the hassle of communicating between the two device stacks. This could especially become cumbersome when multiple devices are attached, each with two interfaces, as I would need to ensure that each “interface 0” is actually targeting with the correct “interface 1” from the same device. I suppose it would be feasible, but it would be much less pleasant than my current design, where each composite device is treated as a whole.

12

Doesnt seem that difficult to me. The ‘and I could have N (physical)
devices’ is just designing from the start for a solution that supports
more than one physical device.

You seem to be stuck with your composite ids, and trying to work
around that to get usbccgp out of the way is problematic.

Mark Roddy

On Tue, Feb 14, 2012 at 4:37 PM, wrote:
>>> Why not have your driver match both interfaces?
>
> In my driver, I need to facilitate communication between the two interfaces (i.e., some event occurs on one interface, in response to which I need to send some data to the other interface, and vice versa). If these interfaces are handled as separate devices, then I would have to deal with the hassle of communicating between the two device stacks. This could especially become cumbersome when multiple devices are attached, each with two interfaces, as I would need to ensure that each “interface 0” is actually targeting with the correct “interface 1” from the same device. I suppose it would be feasible, but it would be much less pleasant than my current design, where each composite device is treated as a whole.
>
> —
> 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