none
OS Driver installation order for a composite USB device RRS feed

  • Question

  • Hi-

    Is there any way to control the order in which the OS (XP,Vista,Win7) will enumerate and attempt to install drivers for a composite USB device?   The reason for this is that we want to guarantee that our Memory device at interface 0 is always first to enumerate and install, as it contains the drivers and INFs for the subsequent interfaces to use.   If the interfaces get enumerated out of order, which we have observed in a few cases, things do not work correctly.

    You can think of this as a sort of a "smart" install device where the device provides its own drivers/INF to satisfy the overall composite USB device installation.

    Thanks!

    Jeremy

    Monday, October 15, 2012 5:26 PM

Answers

  • Actually after more research there's apparently quite a few devices out there that do this.  The Linux world has a number of utilities and mechanisms for getting these devices OUT of that state "see usb-modeswitch" and into whatever device they are supposed to be.    Looks like these devices handle this identity swap by waiting for an "eject" command or some other overloaded command to tell the device to tear down CD-Rom (or Mass Storage) and go into the real device state. 

    Thanks for the help/feedback here!

    Jeremy

    Monday, October 15, 2012 10:09 PM

All replies

  • No you can't guarantee the order, but why should you?  You could package the drivers with a single INF that handles all the devices or you could provide a Difx package that preinstalls all the drivers.  Trying to rely on things like this is just creating unessecary bugs.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, October 15, 2012 5:37 PM
  • you can't always put everything into one INF. If you need separate device classes, you must have an INF/class.  Are you using autorun/autoplay to get the drivers on interface 0 installed into the driver store?  if you do that, the order in which they enumerate does not matter. Eventually interface 0 has its driver installed, the driver packages on it are imported and you kick off a rescan.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 15, 2012 5:43 PM
  • HI Don-

    The idea here is the the user plugs in the device and drivers/SW installation are all handled automatically without any dependencies.    The device itself has the drivers and SW needed to get the user up and going.  No need for downloading them from the web, no need to put in a CD, etc.  

    Hi Doran-

    You are correct that we use autorun/autoplay on interface 0 to stage/install the drivers(of course requiring the user to authorize the driver and software installation).   The problem we run into is that when interface 1 enumerates first, it cannot resolve drivers as none have been staged yet.   And because of the apparent sequential enumeration order of composite interfaces, interface 0 never gets enumerated until the user does something with the "found new hardware" prompt generated from interface 1.     If the interfaces were to install in parallel, this would not be a concern...

    Thanks!

    Jeremy

    Monday, October 15, 2012 5:51 PM
  • on win7 (and I think vista), you get installs in parallel, there is very little change of even interacting with the FNH dialog box.  XP is a diff story. if ordering important, enumerate only interface 0  until you can figure out the condition in which it is OK to tear it down and enumerate the other functions. I know a few other devices which carry their own driver payload do this.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 15, 2012 6:59 PM
  • Hi Doran-

    Do you happen to know offhand what those devices might be?  We'd be interested in getting some to figure out how they did it.

    Thanks

    Jeremy

    Monday, October 15, 2012 8:20 PM
  • offhand, no I don't remember specific devices.  A lot of usb devices pop up as a CD ROM to present the media and then once a driver is installed, it reenumerates as its real self.  there was a defacto standard for this, for the life of me I can't remember its name... 

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 15, 2012 8:53 PM
  • Actually after more research there's apparently quite a few devices out there that do this.  The Linux world has a number of utilities and mechanisms for getting these devices OUT of that state "see usb-modeswitch" and into whatever device they are supposed to be.    Looks like these devices handle this identity swap by waiting for an "eject" command or some other overloaded command to tell the device to tear down CD-Rom (or Mass Storage) and go into the real device state. 

    Thanks for the help/feedback here!

    Jeremy

    Monday, October 15, 2012 10:09 PM