USB ISO Out transaction error with Virtual Host

NTDEV
1

Hi ,

I am working on a Virtual Usb Host Driver and facing some issue with ISO
Out transaction like UsbAudio . While i complete my 1st ISO URB , i
receives the URB_FUNCTION_ABORT_PIPE from UsbAudio.Sys.

I debugged further and after capturing and comparing the URB I found that
the problem is with my URB completion routine.

the listed difference is :

  1. There is undocumented and reserve field *UsbdFlags *in
    *URB_HEADER*. on the Completion upper stack expect the correct value
    as 0x00000022
    .
  2. There is undocumented and reserve field *UsbdDeviceHandle in
    URB_HEADER .* On the completion upper stack expect the Device Handle in
    this field *.*
  3. In the original scenario , the Host layer provides the *
    TransferBufferMDL* in its completion routine , which i was not doing .
  4. URB_ISOCH_TRANSFER structure contain the URB_HCD_AREA which is also
    undocumented and reserve. The completion routine of URB contains the value
    in HcdEndpoint and HCDIrp .

Is there any document which have info related with this reserved field ?

As no document for USB host driver implementation is available , how
should i proceed to implement these reserved field so that my virtual
driver will not get the URB_FUNCTION_ABORT_PIPE from usbaudio.sys .

Thanks in advance .

Niraj Jha

2

Niraj Jha wrote:

I am working on a Virtual Usb Host Driver and facing some issue with
ISO Out transaction like UsbAudio . While i complete my 1st ISO URB ,
i receives the URB_FUNCTION_ABORT_PIPE from UsbAudio.Sys.

I debugged further and after capturing and comparing the URB I found
that the problem is with my URB completion routine.

the listed difference is :

  1. There is undocumented and reserve field *UsbdFlags *in
    *URB_HEADER*. on the Completion upper stack expect the correct
    value as 0x00000022 .

What do you mean by “upper stack”? Usbaudio.sys doesn’t care about this
field. It is reserved strictly for the USB stack. If you are trying to
pass through Microsoft’s hub driver, then it’s possible. The host
controller and hub drivers are, essentially, a matched set. Each makes
assumptions about the other. If you want your fake HCD to work with
Microsoft’s hub driver, then you will have to reverse engineer these
fields. Their use is not documented.

  1. There is undocumented and reserve field *UsbdDeviceHandle in
    URB_HEADER .*On the completion upper stack expect the Device
    Handle in this field.

If the request passed through the hub driver to begin with, then this
field should already have been filled in by the time you get it. Are
you altering the USBD-reserved fields in your HCD? *

*

  1. URB_ISOCH_TRANSFER structure contain the URB_HCD_AREA which is
    also undocumented and reserve. The completion routine of URB
    contains the value in HcdEndpoint and HCDIrp .

Is there any document which have info related with this reserved field ?

No. They are undocumented, because they are for private communication
between Microsoft’s hub driver and Microsoft host controller driver.

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

3

Thanks Tim . Here Upper Stack means Hub and function .

>>If the request passed through the hub driver to begin with, then this
>>field should already have been filled in by the time you get it. Are
>>you altering the USBD-reserved fields in your HCD?

my request is getting passed through hub driver . The URB at the call time
was not having the fields of URB_HCD_AREA . Not only this the
TransferBufferMDL member of ISOC transfer structure is also NULL on the
call time , and these value is supplied by the HCD on its completion .

I will try to do some reverse engineering to get this field info.

Thanks

On Mon, Aug 6, 2012 at 10:29 PM, Tim Roberts wrote:

> Niraj Jha wrote:
> >
> > I am working on a Virtual Usb Host Driver and facing some issue with
> > ISO Out transaction like UsbAudio . While i complete my 1st ISO URB ,
> > i receives the URB_FUNCTION_ABORT_PIPE from UsbAudio.Sys.
> >
> > I debugged further and after capturing and comparing the URB I found
> > that the problem is with my URB completion routine.
> >
> > the listed difference is :
> >
> > 1. There is undocumented and reserve field *UsbdFlags *in
> > URB_HEADER. on the Completion upper stack expect the correct
> > value as 0x00000022 .
> >
>
> What do you mean by “upper stack”? Usbaudio.sys doesn’t care about this
> field. It is reserved strictly for the USB stack. If you are trying to
> pass through Microsoft’s hub driver, then it’s possible. The host
> controller and hub drivers are, essentially, a matched set. Each makes
> assumptions about the other. If you want your fake HCD to work with
> Microsoft’s hub driver, then you will have to reverse engineer these
> fields. Their use is not documented.
>
>
> > 1. There is undocumented and reserve field *UsbdDeviceHandle in
> > URB_HEADER .*On the completion upper stack expect the Device
> > Handle in this field.
> >
>
> If the request passed through the hub driver to begin with, then this
> field should already have been filled in by the time you get it. Are
> you altering the USBD-reserved fields in your HCD? *
>
>
> *
> >
> > 1. URB_ISOCH_TRANSFER structure contain the URB_HCD_AREA which is
> > also undocumented and reserve. The completion routine of URB
> > contains the value in HcdEndpoint and HCDIrp .
> >
> > Is there any document which have info related with this reserved field ?
>
> No. They are undocumented, because they are for private communication
> between Microsoft’s hub driver and Microsoft host controller driver.
>
> –
> 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
>