none
USBCGP.sys binding not persistent across device unplug/plug RRS feed

  • Question

  • I'm seeing a behavior with a USB composite device that Ive not seen before and wondered if anyone could offer some insight.

    We have a USB device with 3 interfaces in its config; AC, AS and MSC.  There is an IAD for the the AC+AS, then another for the single MSC interface.  The device descriptor C/S/P is 0xEF/02/01 and usbcgp correctly loads on the device and our custom usb midi (multi-client) driver and the inbox msc driver are loaded and work correctly.  If the USB device is unplugged / plugged back in, usbcgp.sys no longer loads on the device and our custom driver loads instead rendering the MSC device inaccessible.  If we don't install our custom driver, i.e. use the MS inbox Usbaudio2 driver all works as expected across plug / unplug cycles.

    The OS is Windows10/1903 x64, but the behavior is consistent on other versions of win10 we tested at least back to 1709.

    Thanks for any help you can provide.


    • Edited by Wade_Dawson Thursday, September 19, 2019 2:52 PM
    Thursday, September 19, 2019 2:29 PM

Answers

  • So it turns out that adding &MI_xx to the hardwareid in the inf causes our custom driver to no longer compete with usbcgp for loading against the base hardwareid.  Our driver now loads correctly atop usbcgp and persists across usb plug / unplugs.


    • Marked as answer by Wade_Dawson Thursday, September 19, 2019 9:19 PM
    • Edited by Wade_Dawson Thursday, September 19, 2019 9:21 PM
    Thursday, September 19, 2019 9:19 PM

All replies

  • So, are you saying your base composite device sometimes loads USBCCGP and sometimes loads your custom driver?  That's a huge problem.  Even if there are multiple potential drivers for a given hardware ID, the PnP process should always choose the same one.  There is a rigid algorithm for assigning scores to the possible drivers.  Are there any clues in setup.dev.log?

    Now, if you had installed your driver while the device was plugged in, I would expect this behavior.  You'd get USBCCGP the first time, then your driver would become the preferred one, because specific matches are scored higher than generic matches.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    • Marked as answer by Wade_Dawson Thursday, September 19, 2019 6:58 PM
    • Unmarked as answer by Wade_Dawson Thursday, September 19, 2019 8:42 PM
    Thursday, September 19, 2019 6:01 PM
  • Hi Tim.  Not every time.  It's the last scenario you describe - USBCGP, then our preferred driver.  Can I force USBCGP to be ranked higher by lowering the rank of our custom driver in a coninstaller?  We currently have a coinstaller but its handling DIF_SELECTBESTCOMPATDRV which is now depreceated and appears to be no longer called in modern Windows.


    • Edited by Wade_Dawson Thursday, September 19, 2019 8:45 PM
    Thursday, September 19, 2019 6:48 PM
  • So it turns out that adding &MI_xx to the hardwareid in the inf causes our custom driver to no longer compete with usbcgp for loading against the base hardwareid.  Our driver now loads correctly atop usbcgp and persists across usb plug / unplugs.


    • Marked as answer by Wade_Dawson Thursday, September 19, 2019 9:19 PM
    • Edited by Wade_Dawson Thursday, September 19, 2019 9:21 PM
    Thursday, September 19, 2019 9:19 PM