USB driver woes

Robert_Bielik-2 · December 22, 2009, 8:38am

Ok here goes, with a long story cut short: I have a driver derived from the bulkusb example, working fine for a device with only one interface (in this case the hardware ids have no MI_xx part). Now the device is to *additionally* support MIDI over USB. After I made that modification, the driver fails to recognize the device. MIDI functionality installs and works fine though (through Windows default driver).

When trying to install, it fails with saying that device with hardware id USB\VID_xxxx&PID_xxxx&REV_xxxx&MI_00 does not have a compatible driver. In the inf files DeviceList, the selector is USB\VID_xxxx&PID_xxxx&MI_00 (without the REV_xxxx part) and viewing the hardware ID of the device in Device Manager, both those IDs are represented, i.e. with and without the REV_xxxx part.

Thus I don’t understand why driver installation would fail since the device has the correct hw ids… ??

TIA
/Rob

Robert_Bielik-2 · December 22, 2009, 10:30am

Ok, so I gather the device is now a USB Composite Device with 3 interfaces (0 = base bulk i/o interface, 1 = Audio Control interface (no endp), 2 = MIDI streaming interface), so I added the
inlclude/needs directives :

[Install_32Comp.NTx86]
Include=usb.inf
Needs=Composite.Dev.NTx86
CopyFiles=CopyFiles_32Comp

and

[Install_32.NTx86.Services]
Include=usb.inf
Needs=Composite.Dev.NTx86.Services
AddService=SERVICEUSB,2,ServiceInstall_32Comp

but still it fails finding the driver
/R

Tim_Roberts · December 22, 2009, 1:28pm

xxxxx@xponaut.se wrote:

Ok, so I gather the device is now a USB Composite Device with 3 interfaces (0 = base bulk i/o interface, 1 = Audio Control interface (no endp), 2 = MIDI streaming interface), so I added the
inlclude/needs directives :

[Install_32Comp.NTx86]
Include=usb.inf
Needs=Composite.Dev.NTx86
CopyFiles=CopyFiles_32Comp

and

[Install_32.NTx86.Services]
Include=usb.inf
Needs=Composite.Dev.NTx86.Services
AddService=SERVICEUSB,2,ServiceInstall_32Comp

but still it fails finding the driver

You should just remove the composite stuff altogether. Don’t try to
match the composite ID. If you don’t have an INF that matches the
composite device, the operating system will automatically load
usbccgp.sys, which will expose the additional interfaces with the MI_00
suffix.

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

Robert_Bielik-2 · December 22, 2009, 2:15pm

That was the initial attempt (as described in my first post), i.e. setting the MI_00 suffix in the DeviceList, but it doesn’t work either. Installation fails trying the first hw id (with REV_xxxx) and seems not to try the hw id without REV_xxxx…

/R

Tim_Roberts · December 22, 2009, 2:35pm

xxxxx@xponaut.se wrote:

That was the initial attempt (as described in my first post), i.e. setting the MI_00 suffix in the DeviceList, but it doesn’t work either. Installation fails trying the first hw id (with REV_xxxx) and seems not to try the hw id without REV_xxxx…

Can you post your INF? Did you get rid of all traces of your first
test, where you match the composite ID? If you still have a match for
the composite ID, then usbccgp can’t get in to do its thing.

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

Robert_Bielik-2 · December 23, 2009, 2:27am

The original INF for the device (without MIDI interface) is as follows:

;================================================================
[Version]
Signature=$CHICAGO$
Class=Media
ClassGuid={4D36E96C-E325-11CE-BFC1-08002BE10318}
Provider=%vendor%
DriverVer=04/15/2009,2.1.6.0
CatalogFile=vendor.cat

[Manufacturer]
%vendor%=DeviceList,NTx86

[DestinationDirs]
DefaultDestDir=10,system32\drivers

[SourceDisksFiles]
VendorUSB.sys=1

[SourceDisksFiles.NTx86]
VendorUSB.sys=1

[SourceDisksNames]
1=%INSTDISK%,

[ControlFlags]
ExcludeFromSelect=%Dev02a%,%Dev02b%,%Dev02c%,\
%Dev03a%,%Dev03b%,%Dev03c%,\
%Dev04a%,%Dev04b%,%Dev04c%,\
%Dev05a%,%Dev05b%,%Dev05c%,\
%Dev06a%,%Dev06b%,%Dev06c%,\
%Dev07a%,%Dev07b%,%Dev07c%,\
%Dev08a%,%Dev08b%,%Dev08c%,\
%Dev09a%,%Dev09b%,%Dev09c%,\
%Dev0Aa%,%Dev0Ab%,%Dev0Ac%,\
%Dev0Ba%,%Dev0Bb%,%Dev0Bc%,\
%Dev0Ca%,%Dev0Cb%,%Dev0Cc%,\
%Dev0Da%,%Dev0Db%,%Dev0Dc%,\
%Dev0Ea%,%Dev0Eb%,%Dev0Ec%,\
%Dev0Fa%,%Dev0Fb%,%Dev0Fc%,\
%Dev10a%,%Dev10b%,%Dev10c%,\
%Dev11a%,%Dev11b%,%Dev11c%,\
%Dev12a%,%Dev12b%,%Dev12c%,

[DeviceList]
%DeviceDescription_32%=Install_32,%Dev02%
%DeviceDescription_32%=Install_32,%Dev03%
%DeviceDescription_32%=Install_32,%Dev04%
%DeviceDescription_32%=Install_32,%Dev05%
%DeviceDescription_32%=Install_32,%Dev06%
%DeviceDescription_32%=Install_32,%Dev07%
%DeviceDescription_32%=Install_32,%Dev08%
%DeviceDescription_32%=Install_32,%Dev09%
%DeviceDescription_32%=Install_32,%Dev0A%
%DeviceDescription_32%=Install_32,%Dev0B%
%DeviceDescription_32%=Install_32,%Dev0C%
%DeviceDescription_32%=Install_32,%Dev0D%
%DeviceDescription_32%=Install_32,%Dev0E%
%DeviceDescription_32%=Install_32,%Dev0F%
%DeviceDescription_32%=Install_32,%Dev10%
%DeviceDescription_32%=Install_32,%Dev11%
%DeviceDescription_32%=Install_32,%Dev12%

[DeviceList.NTx86]
%DeviceDescription_32%=Install_32,%Dev02%
%DeviceDescription_32%=Install_32,%Dev03%
%DeviceDescription_32%=Install_32,%Dev04%
%DeviceDescription_32%=Install_32,%Dev05%
%DeviceDescription_32%=Install_32,%Dev06%
%DeviceDescription_32%=Install_32,%Dev07%
%DeviceDescription_32%=Install_32,%Dev08%
%DeviceDescription_32%=Install_32,%Dev09%
%DeviceDescription_32%=Install_32,%Dev0A%
%DeviceDescription_32%=Install_32,%Dev0B%
%DeviceDescription_32%=Install_32,%Dev0C%
%DeviceDescription_32%=Install_32,%Dev0D%
%DeviceDescription_32%=Install_32,%Dev0E%
%DeviceDescription_32%=Install_32,%Dev0F%
%DeviceDescription_32%=Install_32,%Dev10%
%DeviceDescription_32%=Install_32,%Dev11%
%DeviceDescription_32%=Install_32,%Dev12%

;---------------------------------------------------------------------------
; Windows 2000/XP
;---------------------------------------------------------------------------

[Install_32.NTx86]
CopyFiles=CopyFiles_32

[CopyFiles_32]
VendorUSB.sys,2

[Install_32.NTx86.Services]
AddService=VendorUSB,2,ServiceInstall_32

[ServiceInstall_32]
ServiceType=%SERVICE_KERNEL_DRIVER%
StartType=%SERVICE_DEMAND_START%
ErrorControl=%SERVICE_ERROR_NORMAL%
ServiceBinary=%10%\system32\drivers\VendorUSB.sys

[Install_32.NTx86.Hw]
AddReg=HwAddReg_32

[HwAddReg_32]

;---------------------------------------------------------------------------
; Windows 98
;---------------------------------------------------------------------------

[Install_32]
AddReg=AddReg_32
CopyFiles=CopyFiles_32
DriverVer=04/15/2009,2.1.6.0

[AddReg_32]
HKR,DevLoader,*ntkern
HKR,NTMPDriver,VendorUSB.sys

[Install_32.Hw]
AddReg=HwAddReg_32

;---------------------------------------------------------------------------
; Strings
;---------------------------------------------------------------------------

[Strings]
vendor=“Vendor Ltd”
INSTDISK=“Installation CD”
DeviceDescription_32=“Vendor specific 32-bit USB Driver”

Dev02=“USB\VID_xxxx&PID_0002”
Dev03=“USB\VID_xxxx&PID_0003”
Dev04=“USB\VID_xxxx&PID_0004”
Dev05=“USB\VID_xxxx&PID_0005”
Dev06=“USB\VID_xxxx&PID_0006”
Dev07=“USB\VID_xxxx&PID_0007”
Dev08=“USB\VID_xxxx&PID_0008”
Dev09=“USB\VID_xxxx&PID_0009”
Dev0A=“USB\VID_xxxx&PID_000A”
Dev0B=“USB\VID_xxxx&PID_000B”
Dev0C=“USB\VID_xxxx&PID_000C”
Dev0D=“USB\VID_xxxx&PID_000D”
Dev0E=“USB\VID_xxxx&PID_000E”
Dev0F=“USB\VID_xxxx&PID_000F”
Dev10=“USB\VID_xxxx&PID_0010”
Dev11=“USB\VID_xxxx&PID_0011”
Dev12=“USB\VID_xxxx&PID_0012”

Dev02a=%Dev02%“&MI_00”
Dev03a=%Dev03%“&MI_00”
Dev04a=%Dev04%“&MI_00”
Dev05a=%Dev05%“&MI_00”
Dev06a=%Dev06%“&MI_00”
Dev07a=%Dev07%“&MI_00”
Dev08a=%Dev08%“&MI_00”
Dev09a=%Dev09%“&MI_00”
Dev0Aa=%Dev0A%“&MI_00”
Dev0Ba=%Dev0B%“&MI_00”
Dev0Ca=%Dev0C%“&MI_00”
Dev0Da=%Dev0D%“&MI_00”
Dev0Ea=%Dev0E%“&MI_00”
Dev0Fa=%Dev0F%“&MI_00”
Dev10a=%Dev10%“&MI_00”
Dev11a=%Dev11%“&MI_00”
Dev12a=%Dev12%“&MI_00”

Dev02b=%Dev02%“&MI_01”
Dev03b=%Dev03%“&MI_01”
Dev04b=%Dev04%“&MI_01”
Dev05b=%Dev05%“&MI_01”
Dev06b=%Dev06%“&MI_01”
Dev07b=%Dev07%“&MI_01”
Dev08b=%Dev08%“&MI_01”
Dev09b=%Dev09%“&MI_01”
Dev0Ab=%Dev0A%“&MI_01”
Dev0Bb=%Dev0B%“&MI_01”
Dev0Cb=%Dev0C%“&MI_01”
Dev0Db=%Dev0D%“&MI_01”
Dev0Eb=%Dev0E%“&MI_01”
Dev0Fb=%Dev0F%“&MI_01”
Dev10b=%Dev10%“&MI_01”
Dev11b=%Dev11%“&MI_01”
Dev12b=%Dev12%“&MI_01”

Dev02c=%Dev02%“&MI_02”
Dev03c=%Dev03%“&MI_02”
Dev04c=%Dev04%“&MI_02”
Dev05c=%Dev05%“&MI_02”
Dev06c=%Dev06%“&MI_02”
Dev07c=%Dev07%“&MI_02”
Dev08c=%Dev08%“&MI_02”
Dev09c=%Dev09%“&MI_02”
Dev0Ac=%Dev0A%“&MI_02”
Dev0Bc=%Dev0B%“&MI_02”
Dev0Cc=%Dev0C%“&MI_02”
Dev0Dc=%Dev0D%“&MI_02”
Dev0Ec=%Dev0E%“&MI_02”
Dev0Fc=%Dev0F%“&MI_02”
Dev10c=%Dev10%“&MI_02”
Dev11c=%Dev11%“&MI_02”
Dev12c=%Dev12%“&MI_02”

SERVICE_KERNEL_DRIVER=1
SERVICE_DEMAND_START=3
SERVICE_ERROR_NORMAL=1

My modified INF (for device with MIDI interface) is this:

;================================================================

[Version]
Signature=$CHICAGO$
Class=Media
ClassGuid={4D36E96C-E325-11CE-BFC1-08002BE10318}
Provider=%vendor%
DriverVer=04/15/2009,2.1.6.0
CatalogFile=vendor.cat

[Manufacturer]
%vendor%=DeviceList,NTx86

[DestinationDirs]
DefaultDestDir=10,system32\drivers

[SourceDisksFiles]
VendorUSB.sys=1

[SourceDisksFiles.NTx86]
VendorUSB.sys=1

[SourceDisksNames]
1=%INSTDISK%,

[ControlFlags]
ExcludeFromSelect=%Dev02b%,%Dev02c%,\
%Dev03b%,%Dev03c%,\
%Dev04b%,%Dev04c%,\
%Dev05b%,%Dev05c%,\
%Dev06b%,%Dev06c%,\
%Dev07b%,%Dev07c%,\
%Dev08b%,%Dev08c%,\
%Dev09b%,%Dev09c%,\
%Dev0Ab%,%Dev0Ac%,\
%Dev0Bb%,%Dev0Bc%,\
%Dev0Cb%,%Dev0Cc%,\
%Dev0Db%,%Dev0Dc%,\
%Dev0Eb%,%Dev0Ec%,\
%Dev0Fb%,%Dev0Fc%,\
%Dev10b%,%Dev10c%,\
%Dev11b%,%Dev11c%,\
%Dev12b%,%Dev12c%,

[DeviceList]
%DeviceDescription_32%=Install_32,%Dev02%
%DeviceDescription_32%=Install_32,%Dev03%
%DeviceDescription_32%=Install_32,%Dev04%
%DeviceDescription_32%=Install_32,%Dev05%
%DeviceDescription_32%=Install_32,%Dev06%
%DeviceDescription_32%=Install_32,%Dev07%
%DeviceDescription_32%=Install_32,%Dev08%
%DeviceDescription_32%=Install_32,%Dev09%
%DeviceDescription_32%=Install_32,%Dev0A%
%DeviceDescription_32%=Install_32,%Dev0B%
%DeviceDescription_32%=Install_32,%Dev0C%
%DeviceDescription_32%=Install_32,%Dev0D%
%DeviceDescription_32%=Install_32,%Dev0E%
%DeviceDescription_32%=Install_32,%Dev0F%
%DeviceDescription_32%=Install_32,%Dev10%
%DeviceDescription_32%=Install_32,%Dev11%
%DeviceDescription_32%=Install_32,%Dev12%
%DeviceDescription_32%=Install_32,%Dev02a%
%DeviceDescription_32%=Install_32,%Dev03a%
%DeviceDescription_32%=Install_32,%Dev04a%
%DeviceDescription_32%=Install_32,%Dev05a%
%DeviceDescription_32%=Install_32,%Dev06a%
%DeviceDescription_32%=Install_32,%Dev07a%
%DeviceDescription_32%=Install_32,%Dev08a%
%DeviceDescription_32%=Install_32,%Dev09a%
%DeviceDescription_32%=Install_32,%Dev0Aa%
%DeviceDescription_32%=Install_32,%Dev0Ba%
%DeviceDescription_32%=Install_32,%Dev0Ca%
%DeviceDescription_32%=Install_32,%Dev0Da%
%DeviceDescription_32%=Install_32,%Dev0Ea%
%DeviceDescription_32%=Install_32,%Dev0Fa%
%DeviceDescription_32%=Install_32,%Dev10a%
%DeviceDescription_32%=Install_32,%Dev11a%
%DeviceDescription_32%=Install_32,%Dev12a%

[DeviceList.NTx86]
%DeviceDescription_32%=Install_32,%Dev02%
%DeviceDescription_32%=Install_32,%Dev03%
%DeviceDescription_32%=Install_32,%Dev04%
%DeviceDescription_32%=Install_32,%Dev05%
%DeviceDescription_32%=Install_32,%Dev06%
%DeviceDescription_32%=Install_32,%Dev07%
%DeviceDescription_32%=Install_32,%Dev08%
%DeviceDescription_32%=Install_32,%Dev09%
%DeviceDescription_32%=Install_32,%Dev0A%
%DeviceDescription_32%=Install_32,%Dev0B%
%DeviceDescription_32%=Install_32,%Dev0C%
%DeviceDescription_32%=Install_32,%Dev0D%
%DeviceDescription_32%=Install_32,%Dev0E%
%DeviceDescription_32%=Install_32,%Dev0F%
%DeviceDescription_32%=Install_32,%Dev10%
%DeviceDescription_32%=Install_32,%Dev11%
%DeviceDescription_32%=Install_32,%Dev12%
%DeviceDescription_32%=Install_32,%Dev02a%
%DeviceDescription_32%=Install_32,%Dev03a%
%DeviceDescription_32%=Install_32,%Dev04a%
%DeviceDescription_32%=Install_32,%Dev05a%
%DeviceDescription_32%=Install_32,%Dev06a%
%DeviceDescription_32%=Install_32,%Dev07a%
%DeviceDescription_32%=Install_32,%Dev08a%
%DeviceDescription_32%=Install_32,%Dev09a%
%DeviceDescription_32%=Install_32,%Dev0Aa%
%DeviceDescription_32%=Install_32,%Dev0Ba%
%DeviceDescription_32%=Install_32,%Dev0Ca%
%DeviceDescription_32%=Install_32,%Dev0Da%
%DeviceDescription_32%=Install_32,%Dev0Ea%
%DeviceDescription_32%=Install_32,%Dev0Fa%
%DeviceDescription_32%=Install_32,%Dev10a%
%DeviceDescription_32%=Install_32,%Dev11a%
%DeviceDescription_32%=Install_32,%Dev12a%

;---------------------------------------------------------------------------
; Windows 2000/XP
;---------------------------------------------------------------------------

[Install_32.NTx86]
CopyFiles=CopyFiles_32

[CopyFiles_32]
VendorUSB.sys,2

[Install_32.NTx86.Services]
AddService=VendorUSB,2,ServiceInstall_32

[ServiceInstall_32]
ServiceType=%SERVICE_KERNEL_DRIVER%
StartType=%SERVICE_DEMAND_START%
ErrorControl=%SERVICE_ERROR_NORMAL%
ServiceBinary=%10%\system32\drivers\VendorUSB.sys

[Install_32.NTx86.Hw]
AddReg=HwAddReg_32

[HwAddReg_32]

;---------------------------------------------------------------------------
; Windows 98
;---------------------------------------------------------------------------

[Install_32]
AddReg=AddReg_32
CopyFiles=CopyFiles_32
DriverVer=04/15/2009,2.1.6.0

[AddReg_32]
HKR,DevLoader,*ntkern
HKR,NTMPDriver,VendorUSB.sys

[Install_32.Hw]
AddReg=HwAddReg_32

;---------------------------------------------------------------------------
; Strings
;---------------------------------------------------------------------------

[Strings]
vendor=“Vendor Ltd”
INSTDISK=“Installation CD”
DeviceDescription_32=“Vendor specific 32-bit USB Driver”

Dev02=“USB\VID_xxxx&PID_0002”
Dev03=“USB\VID_xxxx&PID_0003”
Dev04=“USB\VID_xxxx&PID_0004”
Dev05=“USB\VID_xxxx&PID_0005”
Dev06=“USB\VID_xxxx&PID_0006”
Dev07=“USB\VID_xxxx&PID_0007”
Dev08=“USB\VID_xxxx&PID_0008”
Dev09=“USB\VID_xxxx&PID_0009”
Dev0A=“USB\VID_xxxx&PID_000A”
Dev0B=“USB\VID_xxxx&PID_000B”
Dev0C=“USB\VID_xxxx&PID_000C”
Dev0D=“USB\VID_xxxx&PID_000D”
Dev0E=“USB\VID_xxxx&PID_000E”
Dev0F=“USB\VID_xxxx&PID_000F”
Dev10=“USB\VID_xxxx&PID_0010”
Dev11=“USB\VID_xxxx&PID_0011”
Dev12=“USB\VID_xxxx&PID_0012”

Dev02a=%Dev02%“&MI_00”
Dev03a=%Dev03%“&MI_00”
Dev04a=%Dev04%“&MI_00”
Dev05a=%Dev05%“&MI_00”
Dev06a=%Dev06%“&MI_00”
Dev07a=%Dev07%“&MI_00”
Dev08a=%Dev08%“&MI_00”
Dev09a=%Dev09%“&MI_00”
Dev0Aa=%Dev0A%“&MI_00”
Dev0Ba=%Dev0B%“&MI_00”
Dev0Ca=%Dev0C%“&MI_00”
Dev0Da=%Dev0D%“&MI_00”
Dev0Ea=%Dev0E%“&MI_00”
Dev0Fa=%Dev0F%“&MI_00”
Dev10a=%Dev10%“&MI_00”
Dev11a=%Dev11%“&MI_00”
Dev12a=%Dev12%“&MI_00”

Dev02b=%Dev02%“&MI_01”
Dev03b=%Dev03%“&MI_01”
Dev04b=%Dev04%“&MI_01”
Dev05b=%Dev05%“&MI_01”
Dev06b=%Dev06%“&MI_01”
Dev07b=%Dev07%“&MI_01”
Dev08b=%Dev08%“&MI_01”
Dev09b=%Dev09%“&MI_01”
Dev0Ab=%Dev0A%“&MI_01”
Dev0Bb=%Dev0B%“&MI_01”
Dev0Cb=%Dev0C%“&MI_01”
Dev0Db=%Dev0D%“&MI_01”
Dev0Eb=%Dev0E%“&MI_01”
Dev0Fb=%Dev0F%“&MI_01”
Dev10b=%Dev10%“&MI_01”
Dev11b=%Dev11%“&MI_01”
Dev12b=%Dev12%“&MI_01”

Dev02c=%Dev02%“&MI_02”
Dev03c=%Dev03%“&MI_02”
Dev04c=%Dev04%“&MI_02”
Dev05c=%Dev05%“&MI_02”
Dev06c=%Dev06%“&MI_02”
Dev07c=%Dev07%“&MI_02”
Dev08c=%Dev08%“&MI_02”
Dev09c=%Dev09%“&MI_02”
Dev0Ac=%Dev0A%“&MI_02”
Dev0Bc=%Dev0B%“&MI_02”
Dev0Cc=%Dev0C%“&MI_02”
Dev0Dc=%Dev0D%“&MI_02”
Dev0Ec=%Dev0E%“&MI_02”
Dev0Fc=%Dev0F%“&MI_02”
Dev10c=%Dev10%“&MI_02”
Dev11c=%Dev11%“&MI_02”
Dev12c=%Dev12%“&MI_02”

SERVICE_KERNEL_DRIVER=1
SERVICE_DEMAND_START=3
SERVICE_ERROR_NORMAL=1

I just added the HW ids with MI_00 postfix in the DeviceList section, together with the original ones, since I need the INF to work for devices with or without MIDI interface (their base interface (index zero) is the same).

The actual HW id of the device is USB\VID_xxxx&PID_000B&REV_0003&MI_00 + USB\VID_xxxx&PID_000B&MI_00 with the MIDI interface enabled and USB\VID_xxxx&PID_000B without MIDI. Without MIDI interface exposed the driver installs fine (using the original INF), but fails with MIDI exposed saying that HW id USB\VID_xxxx&PID_000B&REV_0003&MI_00 cannot be matched to a driver…

/Rob

Tim_Roberts · December 23, 2009, 12:42pm

xxxxx@xponaut.se wrote:

The original INF for the device (without MIDI interface) is as follows:
…
My modified INF (for device with MIDI interface) is this:
[DeviceList]
%DeviceDescription_32%=Install_32,%Dev02%
%DeviceDescription_32%=Install_32,%Dev03%
%DeviceDescription_32%=Install_32,%Dev04%
%DeviceDescription_32%=Install_32,%Dev05%
%DeviceDescription_32%=Install_32,%Dev06%
…
I just added the HW ids with MI_00 postfix in the DeviceList section, together with the original ones, since I need the INF to work for devices with or without MIDI interface (their base interface (index zero) is the same).

This is something that you did not mention previously, and I’m convinced
that it makes your situation completely hopeless. You are asking for
omniscience on the part of Device Manager.

Think about what you’re asking. When your device is plugged in, the
device ID USB\VID_xxxx&PID_000B will be exposed, and Device Manager
tries to find a match for it. If it is able to find a match, it loads
that driver, and then Device Manager is done. It doesn’t do anything
else. Ordinarily, with a composite device, there won’t be a match, so
it falls back to the default driver for composite devices, usbccgp.sys.
THAT driver is the one that checks the descriptors and exposes the
&MI_00 and &MI_01 interfaces. But, in your case, since you already
claimed the composite device, usbccgp will not be loaded, so those
interfaces will never appear.

You can’t have it both ways. Either your root device ID is composite,
or it isn’t. There’s no way to write an INF that handles both cases.

What you NEED to do is use a new PID for the devices that include MIDI.
There is no alternative, as far as I can see

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

Tim_Roberts · December 23, 2009, 12:48pm

Tim Roberts wrote:

xxxxx@xponaut.se wrote:

> …
> I just added the HW ids with MI_00 postfix in the DeviceList section, together with the original ones, since I need the INF to work for devices with or without MIDI interface (their base interface (index zero) is the same).
>
>

You can’t have it both ways. Either your root device ID is composite,
or it isn’t. There’s no way to write an INF that handles both cases.

What you NEED to do is use a new PID for the devices that include MIDI.
There is no alternative, as far as I can see

OK, so there IS an alternative. You could write a simple bus driver
yourself, as a replacement for usbccgp.sys. That driver could check the
descriptors on its own. If there is only one interface, you create a
PDO for &MI_00. If there are multiple interfaces, you create a PDO for
&MI_00 and another for &MI_01. Then, a second INF has your original
driver match for &MI_00, and a third INF can match &MI_01 to usbaudio.sys.

Usbccgp.sys does a little trickery with the descriptors when it creates
child devices, to allow them to pretend that there interface is the only
one in the system. You will probably have to do that same descriptor
rewriting.

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

Doron_Holan · December 23, 2009, 1:11pm

Usbccgp allows for cusomization of how the interfaces are grouped in the pdos, that is the exact problem jitesh is having in his thread. You can impl the same interface and have usbccgp do your bidding inf that works for this scenario

d

-----Original Message-----
From: Tim Roberts
Sent: Wednesday, December 23, 2009 9:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB driver woes

Tim Roberts wrote:
> xxxxx@xponaut.se wrote:
>
>> …
>> I just added the HW ids with MI_00 postfix in the DeviceList section, together with the original ones, since I need the INF to work for devices with or without MIDI interface (their base interface (index zero) is the same).
>>
>>
>
> You can’t have it both ways. Either your root device ID is composite,
> or it isn’t. There’s no way to write an INF that handles both cases.
>
> What you NEED to do is use a new PID for the devices that include MIDI.
> There is no alternative, as far as I can see
>

OK, so there IS an alternative. You could write a simple bus driver
yourself, as a replacement for usbccgp.sys. That driver could check the
descriptors on its own. If there is only one interface, you create a
PDO for &MI_00. If there are multiple interfaces, you create a PDO for
&MI_00 and another for &MI_01. Then, a second INF has your original
driver match for &MI_00, and a third INF can match &MI_01 to usbaudio.sys.

Usbccgp.sys does a little trickery with the descriptors when it creates
child devices, to allow them to pretend that there interface is the only
one in the system. You will probably have to do that same descriptor
rewriting.

–
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

Robert_Bielik-2 · December 25, 2009, 3:22am

Tim: Ok, I’m a bit confused since usbccgp obviously does get loaded anyway, otherwise the MIDI interface wouldn’t work, right ? During device installation, the message “USB Composite Device ready” is shown which I guess is from usbccgp?

Doron: Do you mean the “iocompleterequest called twice in a layered stack” thread?

I’ll set the setup logging to very verbose and try see what really happens. Also I’ll make an INF with only the …&MI_00 interface entry, see if that works.

Thnx guys and happy holidays,
/Robert

Robert_Bielik-2 · December 28, 2009, 5:06am

Interestingly enough, if I set the DeviceList as follows:

[DeviceList]
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp&MI_00
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp

for each PID, the driver installs fine for both non-MIDI units and MIDI enabled units with a single INF
file (!). In first case, the second entry in DeviceList is used, and in the latter case usbccgp grabs the root ID
and then exposes the composite ID, then I point the installer wizard to the INF and driver installs fine.
Subsequent removal/insertion of unit works fine.

If I have a non-MIDI unit with driver installed, then “upgrade” the unit to expose MIDI, the installed driver cannot
start (rather natural). Also, MIDI doesn’t work as the driver was installed for root ID, and usbccgp never loads. Solution here is
to manually remove the driver, and reinstall it.

Since our aim is to provide the driver at Windows Update, will WHQL verification complain about such an INF file?

/Rob

Robert_Bielik-2 · December 28, 2009, 6:24am

Robert Bielik skrev:

If I have a non-MIDI unit with driver installed, then “upgrade” the unit
to expose MIDI, the installed driver cannot
start (rather natural). Also, MIDI doesn’t work as the driver was
installed for root ID, and usbccgp never loads. Solution here is
to manually remove the driver, and reinstall it.

Even more interestingly, if I during the “upgrade” only uninstall the device instance (with USBDeview),
but not the driver, then the already installed driver handles the “new” composite device just fine

I suppose devcon’s remove device command does pretty much the same thingy, right?

/Rob

Tim_Roberts · December 28, 2009, 1:05pm

Robert Bielik wrote:

Since our aim is to provide the driver at Windows Update, will WHQL
verification complain about such an INF file?

You can run the chkinf tool yourself. It’s in the WDK. That’s all that
the WHQL tests do. My hunch is that it will be fine.

I do have to say that your solution makes me uncomfortable. I wonder
whether you are just encountering behavior that works by accident.

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

Robert_Bielik-2 · December 28, 2009, 2:20pm

Tim Roberts skrev:

You can run the chkinf tool yourself. It’s in the WDK. That’s all that
the WHQL tests do. My hunch is that it will be fine.

Ok, thnx, will do.

I do have to say that your solution makes me uncomfortable. I wonder
whether you are just encountering behavior that works by accident.

The thought has crossed my mind too. But I’ve tested the possible scenarios which seem to work. The one scenario
I was worried about is when there is no driver installed, and thus usbccgp gets hold of root ID and exposes the
composite IDs, then when I point to the INF it is natural that it will install.

However, if I then unplug the device and plug it back in, I was worried that the installed INF would grab the
root ID. But it seems that once the device instance in the registry (under System\ControlSet001\Enum\USB) is
“wired” to the PDO, the driver will only be loaded for that PDO. So, the case when the unit got “updated” to a composite
device it was natural that the driver would not start, unless the device instance was purged and then the
driver started up fine. But in this case I agree that it is a bit mysterious that usbccgp gets loaded even though
the installed INF contains the root ID…

Doron, can you shed some light on this ?

TIA
/Robert

Doron_Holan · December 28, 2009, 5:35pm

Everyone here is on vacation (including me), I think you will get some attention next week after the new year

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Robert Bielik
Sent: Monday, December 28, 2009 11:18 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB driver woes

Tim Roberts skrev:

You can run the chkinf tool yourself. It’s in the WDK. That’s all that
the WHQL tests do. My hunch is that it will be fine.

Ok, thnx, will do.

I do have to say that your solution makes me uncomfortable. I wonder
whether you are just encountering behavior that works by accident.

The thought has crossed my mind too. But I’ve tested the possible scenarios which seem to work. The one scenario
I was worried about is when there is no driver installed, and thus usbccgp gets hold of root ID and exposes the
composite IDs, then when I point to the INF it is natural that it will install.

However, if I then unplug the device and plug it back in, I was worried that the installed INF would grab the
root ID. But it seems that once the device instance in the registry (under System\ControlSet001\Enum\USB) is
“wired” to the PDO, the driver will only be loaded for that PDO. So, the case when the unit got “updated” to a composite
device it was natural that the driver would not start, unless the device instance was purged and then the
driver started up fine. But in this case I agree that it is a bit mysterious that usbccgp gets loaded even though
the installed INF contains the root ID…

Doron, can you shed some light on this ?

TIA
/Robert

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

Robert_Bielik-2 · December 29, 2009, 2:26am

Doron Holan skrev:

Everyone here is on vacation (including me), I think you will get some attention next week after the new year

Thnx Doron, will anxiously await that. Meanwhile a Happy New year to you and all!

/Rob

Philip_Ries · December 30, 2009, 2:39pm

Sounds like the mystery is why CCGP gets loaded for the upgraded (composite/MIDI) device, when these lines are in your INF.

[DeviceList]
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp&MI_00
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp

Maybe other posters who’ve written their own CCGP have hit a similar issue where inbox CCGP would continue to load? Unless their devices don’t meet the CCGP enumeration requirements: http://msdn.microsoft.com/en-us/library/aa476434.aspx

Does your non-MIDI device meet those CCGP requirements? If it doesn’t, for now here is a guess at what’s going on. For the MIDI device only, there are 2 INF matches, and the inbox signature makes usb.inf’s compatible ID match rank as better than your INF’s HWID match. In that case the situation would change once you sign or WHQL-sign your driver package. At that point you wouldn’t get to use CCGP.

Vista/Win7 driver ranking: http://msdn.microsoft.com/en-us/library/aa477022.aspx
2000/XP/2003 driver ranking: http://msdn.microsoft.com/en-us/library/aa477008.aspx

Your SetupAPI logs might make the system’s driver selection clearer: http://msdn.microsoft.com/en-us/library/ms791354.aspx

Couple other questions.

What version or versions of Windows have you tried? It would be good to test multiple versions.

To avoid this possible issue, in the upgrade to MIDI can you change the hardware ID via device descriptor at all? If you can’t change the PID, can you change the REV (bcdDevice)?

Philip

Robert Bielik wrote:

Doron Holan skrev:
> Everyone here is on vacation (including me), I think you will get some attention next week after the new year
>

Thnx Doron, will anxiously await that. Meanwhile a Happy New year to you and all!

/Rob

Chris_Aseltine · December 31, 2009, 2:02am

Philip Ries wrote:

Maybe other posters who’ve written their own CCGP have hit a
similar issue where inbox CCGP would continue to load?

Besides the usual issues with driver ranking versus an inbox driver that you’ve mentioned already, I’ve also seen issues where “updating” a device’s driver, which involves moving it across device classes, does not always work properly. For example we had a device that would get the MTP driver (wpdusb) loaded automatically. When we “updated” to use a custom function driver (in another setup class) … blue screen.

If you can’t change the PID, can you change the REV
(bcdDevice)?

I wouldn’t recommend messing with REV/ bcdDevice. Reason why: yes, the hub driver will generate a hardware ID with the &REV_xxxx figure tacked on, but the actual devnode that is created is agnostic with respect to bcdDevice, so messing with bcdDevice won’t get you a new PDO. In other words bcdDevice is only relevant at device installation time. This is sort of confusing and probably not what the OP wants.

In the end he should probably just mess with his descriptors so that usbccgp never loads in the first place.

Robert_Bielik-2 · December 31, 2009, 4:24am

Thanks Philip for your enlightening reply.

xxxxx@microsoft.com skrev:

In that case the situation would change once you sign or WHQL-sign your driver package. At that point you wouldn’t get to use CCGP.

As WHQL-signing is in the pipe, I see that my solution is not viable (as Tim’s gut feeling already pointed out).

But acc. to the docs at http://msdn.microsoft.com/en-us/library/aa476434.aspx, I should be able to do this:

Drop the root ID and only use the composite ID for both non-MIDI and MIDI units. i.e.:

[DeviceList]
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp&MI_00

Add include/needs to usb.inf (per the docs) so that the non-composite device ends up having a composite ID with MI_00 suffix.

So with this scheme I figure that in the non-composite case, CCGP will still be loaded and then
the composite ID will match. The composite case is then trivial since there is no root ID match.
Won’t be able to try this until next week though…

What version or versions of Windows have you tried? It would be good to test multiple versions.

So far I only tested on Vista, but now I’ll defer testing until I get another solution working.

Thnx!
/Robert

Robert_Bielik-2 · January 7, 2010, 3:22am

Ok, so now I’ll try to do this:

[Manufacturer]
%vendor%=DeviceList,NTx86
%Microsoft.Mfg%=CCGPLoader,NTx86

[…snip…]

[DeviceList]
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp&MI_00

[DeviceList.NTx86]
%DeviceDescription_32%=Install_32,USB\VID_vvvv&PID_pppp&MI_00

[CCGPLoader]
%Composite.Device.Desc%=Composite.Device,USB\VID_vvvv&PID_pppp

[CCGPLoader.NTx86]
%Composite.Device.Desc%=Composite.Device,USB\VID_vvvv&PID_pppp

; Common Class Generic Parent for root ID

[Composite.Device.NTx86]
Include=usb.inf
Needs=Composite.Dev.NT

[Composite.Device.NTx86.Services]
Include=usb.inf
Needs=Composite.Dev.NT.Services

[…snip…]

This ought to load the ccgp for both the composite and non-composite case. And also when the driver package
is WHQL signed, right ?

How can I simulate that situation, i.e. when my INF will be higher ranked ? Is it as simple as putting my
certificate amongst Trusted Publishers ?

TIA
/Rob