Assertion failure in USBPORT

NTDEV
1

I’m hitting an assertion failure in USBPORT, and would appreciate some info
on why.

*** Assertion failed: endpointDescriptor->bDescriptorType ==
USB_ENDPOINT_DESCRIPTOR_TYPE
*** Source File: d:\xpsprtm\drivers\wdm\usb\hcd\usbport\config.c, line
1483

ChildEBP RetAddr
f78ca30c 805285ba nt!DbgBreakPoint
f78ca5fc 805285fc nt!RtlAssert2+0x104
f78ca618 bace6d1f nt!RtlAssert+0x18
f78ca630 bacf5438 USBPORT!USBPORT_AssertFailure+0x17
f78ca654 bacf5758 USBPORT!USBPORT_InternalGetInterfaceLength+0x9c
f78ca674 baceae1d USBPORT!USBPORT_InternalParseConfigurationDescriptor+0xe8
f78ca694 bacf71eb USBPORT!USBPORT_InitializeInterfaceInformation+0x29
f78ca6d4 bacd0a41 USBPORT!USBPORT_SelectConfiguration+0x38f
f78ca708 bace218d USBPORT!USBPORT_ProcessURB+0x715
f78ca72c bac8e25f USBPORT!USBPORT_PdoInternalDeviceControlIrp+0x189
f78ca754 804eddf9 USBPORT!USBPORT_Dispatch+0x227
f78ca764 8064b5a8 nt!IopfCallDriver+0x31
f78ca788 f6f7e12e nt!IovCallDriver+0xa0
f78ca7a4 f6f7f502 usbhub!USBH_PdoUrbFilter+0x298
f78ca7c8 f6f78986 usbhub!USBH_PdoDispatch+0x2bc
f78ca7d8 804eddf9 usbhub!USBH_HubDispatch+0x48
f78ca7e8 8064b5a8 nt!IopfCallDriver+0x31
f78ca80c 80655fd6 nt!IovCallDriver+0xa0
f78ca820 804eddf9 nt!ViDriverDispatchGeneric+0x2a
f78ca830 8064b5a8 nt!IopfCallDriver+0x31
f78ca854 b822ded3 nt!IovCallDriver+0xa0
f78ca890 b822a74e XXX!UsbSubmitUrbSynchronous+0x163
f78ca90c b821f93b XXX!ReadAndSelectConfiguration+0x28e

Apparently this is happening because of the contents of the configuration
descriptor provided to the USB stack. The device has 1 configuration, which
has 2 interfaces. The second interface has 1 endpoint, but also includes
another descriptor before the endpoint descriptor.

From poking around in USBPORT_InternalGetInterfaceLength, it appears to walk
the interface descriptor chain, and gets grumpy when it finds a descriptor
whose type is not USB_DESCRIPTOR_ENDPOINT.

So, is USBPORT being too picky? Or is this other descriptor illegal, at
least at this point in the chain of descriptors?

Any help is appreciated.

– arlie

2

Arlie Davis wrote:

I’m hitting an assertion failure in USBPORT, and would appreciate some info
on why.

…
Apparently this is happening because of the contents of the configuration
descriptor provided to the USB stack. The device has 1 configuration, which
has 2 interfaces. The second interface has 1 endpoint, but also includes
another descriptor before the endpoint descriptor.

>From poking around in USBPORT_InternalGetInterfaceLength, it appears to walk
the interface descriptor chain, and gets grumpy when it finds a descriptor
whose type is not USB_DESCRIPTOR_ENDPOINT.

So, is USBPORT being too picky? Or is this other descriptor illegal, at
least at this point in the chain of descriptors?

What class of device? What is the other descriptor? In a USBAUDIO
device, for example, you’ll get a configuration descriptor, an interface
descriptor, a couple of class-specific interface descriptors, then a set
of endpoint descriptors with class-specific endpoint descriptors. They
are grouped together: interface descriptor(s), then endpoint
descriptor(s). I do not believe it is legal, for example, for a string
descriptor to be inserted in the middle.

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

3

It’s a class-specific descriptor.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, February 21, 2006 8:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in USBPORT

Arlie Davis wrote:

I’m hitting an assertion failure in USBPORT, and would appreciate some
info on why.

…
Apparently this is happening because of the contents of the
configuration descriptor provided to the USB stack. The device has 1
configuration, which has 2 interfaces. The second interface has 1
endpoint, but also includes another descriptor before the endpoint
descriptor.

>From poking around in USBPORT_InternalGetInterfaceLength, it appears
>to walk
the interface descriptor chain, and gets grumpy when it finds a
descriptor whose type is not USB_DESCRIPTOR_ENDPOINT.

So, is USBPORT being too picky? Or is this other descriptor illegal,
at least at this point in the chain of descriptors?

What class of device? What is the other descriptor? In a USBAUDIO device,
for example, you’ll get a configuration descriptor, an interface descriptor,
a couple of class-specific interface descriptors, then a set of endpoint
descriptors with class-specific endpoint descriptors. They are grouped
together: interface descriptor(s), then endpoint descriptor(s). I do not
believe it is legal, for example, for a string descriptor to be inserted in
the middle.

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

4

Arlie Davis wrote:

It’s a class-specific descriptor.

What kind of class-specific descriptor? It is legal to have a
class-specific interface descriptor before the endpoint descriptors, but
not some other kind. For example, this should be valid:

config
interface
class-specific interface
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
interface
class-specific interface
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
string

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

5

Unfortunately, I can’t go into more detail about the specifics of the
descriptor, except to say “it’s a class-specific descriptor”. From the
point of view of the MS USB stack, it should simply be “not the endpoint
descriptor that I’m looking for”.

If class-specific descriptors are valid in this position (after interface
descriptor, before endpoint descriptor), then USBPORT is raising an
assertion failure when it shouldn’t be.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 22, 2006 2:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in USBPORT

Arlie Davis wrote:

It’s a class-specific descriptor.

What kind of class-specific descriptor? It is legal to have a
class-specific interface descriptor before the endpoint descriptors, but not
some other kind. For example, this should be valid:

config
interface
class-specific interface
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
interface
class-specific interface
endpoint
class-specific endpoint
class-specific endpoint
class-specific endpoint
string

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stonestreetone.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Arlie Davis wrote:

Unfortunately, I can’t go into more detail about the specifics of the
descriptor, except to say “it’s a class-specific descriptor”. From the
point of view of the MS USB stack, it should simply be “not the endpoint
descriptor that I’m looking for”.

If class-specific descriptors are valid in this position (after interface
descriptor, before endpoint descriptor), then USBPORT is raising an
assertion failure when it shouldn’t be.

I am not getting my point across. The spec says that class-specific
INTERFACE descriptors must immediately follow a standard INTERFACE
descriptor. Class-specific ENDPOINT descriptors must immediately follow
a standard ENDPOINT descriptor.

Interface and endpoint descriptors are the only kinds that are allowed
in a configuration descriptor. Any other kind of class-specific or
vendor-specific descriptor cannot be embedded in a configuration
descriptor. It must be fetched in a separate GetDescriptor request.

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

7

You ARE getting your point across. It’s a class-specific INTERFACE
descriptor, and it immediately follows the USB interface descriptor.

I’ve stepped through the assembly code in
USBPORT_InternalGetInterfaceLength, and it the only thing it appears to
check is to see if the next descriptor has bDescriptorType =
USB_ENDPOINT_DESCRIPTOR_TYPE. No allowance is made for other descriptors of
any kind, until the endpoint count (found in the interface descriptor that
is the input of this function) is exhausted. The assertion text seems to
confirms this:

*** Assertion failed: endpointDescriptor->bDescriptorType ==
USB_ENDPOINT_DESCRIPTOR_TYPE
*** Source File: d:\xpsprtm\drivers\wdm\usb\hcd\usbport\config.c, line
1483

Obviously, my analysis of stepping through the assembly code could be wrong
– it can be difficult to map the assembly back to what’s really happening.
Which is why I posted to begin with.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 22, 2006 3:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in USBPORT

Arlie Davis wrote:

Unfortunately, I can’t go into more detail about the specifics of the
descriptor, except to say “it’s a class-specific descriptor”. From the
point of view of the MS USB stack, it should simply be “not the
endpoint descriptor that I’m looking for”.

If class-specific descriptors are valid in this position (after
interface descriptor, before endpoint descriptor), then USBPORT is
raising an assertion failure when it shouldn’t be.

I am not getting my point across. The spec says that class-specific
INTERFACE descriptors must immediately follow a standard INTERFACE
descriptor. Class-specific ENDPOINT descriptors must immediately follow a
standard ENDPOINT descriptor.

Interface and endpoint descriptors are the only kinds that are allowed in a
configuration descriptor. Any other kind of class-specific or
vendor-specific descriptor cannot be embedded in a configuration descriptor.
It must be fetched in a separate GetDescriptor request.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stonestreetone.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

The problem isn’t that you have other descriptors before the endpoint
descriptor. I believe that the problem you are seeing is due to the
fact that your InterfaceDescriptor->bNumEndpoints value is greater than
the actual number of endpoint descriptors in your descriptor set. The
other possibility is that your class-specific descriptor has the bLength
field set to zero. Either one of these conditions would result in the
assert.

Randy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, February 21, 2006 5:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in USBPORT

Arlie Davis wrote:

I’m hitting an assertion failure in USBPORT, and would appreciate some
info
on why.

…
Apparently this is happening because of the contents of the
configuration
descriptor provided to the USB stack. The device has 1 configuration,
which
has 2 interfaces. The second interface has 1 endpoint, but also
includes
another descriptor before the endpoint descriptor.

>From poking around in USBPORT_InternalGetInterfaceLength, it appears
to walk
the interface descriptor chain, and gets grumpy when it finds a
descriptor
whose type is not USB_DESCRIPTOR_ENDPOINT.

So, is USBPORT being too picky? Or is this other descriptor illegal,
at
least at this point in the chain of descriptors?

What class of device? What is the other descriptor? In a USBAUDIO
device, for example, you’ll get a configuration descriptor, an interface
descriptor, a couple of class-specific interface descriptors, then a set
of endpoint descriptors with class-specific endpoint descriptors. They
are grouped together: interface descriptor(s), then endpoint
descriptor(s). I do not believe it is legal, for example, for a string
descriptor to be inserted in the middle.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Another possibility is that your bLength field in your cless-specific
descriptor is not exactly the correct size, thus throwing the descriptor
parsing off track.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Aull
Sent: Wednesday, February 22, 2006 3:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Assertion failure in USBPORT

The problem isn’t that you have other descriptors before the endpoint
descriptor. I believe that the problem you are seeing is due to the
fact that your InterfaceDescriptor->bNumEndpoints value is greater than
the actual number of endpoint descriptors in your descriptor set. The
other possibility is that your class-specific descriptor has the bLength
field set to zero. Either one of these conditions would result in the
assert.

Randy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, February 21, 2006 5:13 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in USBPORT

Arlie Davis wrote:

I’m hitting an assertion failure in USBPORT, and would appreciate some
info
on why.

…
Apparently this is happening because of the contents of the
configuration
descriptor provided to the USB stack. The device has 1 configuration,
which
has 2 interfaces. The second interface has 1 endpoint, but also
includes
another descriptor before the endpoint descriptor.

>From poking around in USBPORT_InternalGetInterfaceLength, it appears
to walk
the interface descriptor chain, and gets grumpy when it finds a
descriptor
whose type is not USB_DESCRIPTOR_ENDPOINT.

So, is USBPORT being too picky? Or is this other descriptor illegal,
at
least at this point in the chain of descriptors?

What class of device? What is the other descriptor? In a USBAUDIO
device, for example, you’ll get a configuration descriptor, an interface
descriptor, a couple of class-specific interface descriptors, then a set
of endpoint descriptors with class-specific endpoint descriptors. They
are grouped together: interface descriptor(s), then endpoint
descriptor(s). I do not believe it is legal, for example, for a string
descriptor to be inserted in the middle.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com