Strange behaviour in TransferFlags.

NTDEV
1

Hi,

I get bulk usb urbs from the ms storage driver when i plug in a flash disk. My driver sits below the ms driver.

  1. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 2
  2. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 2, PipeHandle: 81
  3. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 81

My question is can I trust the TransferFlags field. Obviously 1 and 3 above can’t both be correct.

What I want to do is to use TransferFlags to figure out the whether the urb is IN or OUT.

Thanks,

Kevin.

2

I have no idea about transfer flags but why don’t you use pipe
direction, instead? See USB_ENDPOINT_DIRECTION_OUT() and
USB_ENDPOINT_DIRECTION_IN().

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 28, 2010 6:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Strange behaviour in TransferFlags.

Hi,

I get bulk usb urbs from the ms storage driver when i plug in
a flash disk. My driver sits below the ms driver.

  1. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 2
  2. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 2, PipeHandle: 81
  3. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 81

My question is can I trust the TransferFlags field. Obviously
1 and 3 above can’t both be correct.

What I want to do is to use TransferFlags to figure out the
whether the urb is IN or OUT.

Thanks,

Kevin.

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

3

I did! USB_ENDPOINT_DIRECTION_IN is defined as:

#define USB_ENDPOINT_DIRECTION_IN (x) ((x) & USB_ENDPOINT_DIRECTION_MASK)

so still

  1. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 2
  2. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 81

would give the same value, which is wrong as per the endpoints.

There is another way, which is by looking at the endpoint attributes, but I wanted to try the above because it seemed simpler and more elegant.

4

Nope. You pass PipeHandle as a parameter and get the correct result. I
mean to ignore TransferFlags and use just endpoint descriptor.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 28, 2010 7:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Strange behaviour in TransferFlags.

I did! USB_ENDPOINT_DIRECTION_IN is defined as:

#define USB_ENDPOINT_DIRECTION_IN (x) ((x) &
USB_ENDPOINT_DIRECTION_MASK)

so still

  1. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0, PipeHandle: 2
  2. SubmitUrbBulkOrInterruptTransfer - TransferFlags: 0,
    PipeHandle: 81

would give the same value, which is wrong as per the endpoints.

There is another way, which is by looking at the endpoint
attributes, but I wanted to try the above because it seemed
simpler and more elegant.

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

5

In a WDM driver such as USBSTOR.SYS the USBD_TRANSFER_DIRECTION_IN flag only needs to be explicitly set, or not, for the following control transfer requests (need to double check and verify this):

URB_FUNCTION_CONTROL_TRANSFER
URB_FUNCTION_CONTROL_TRANSFER_EX
URB_FUNCTION_CLASS_DEVICE
URB_FUNCTION_CLASS_ENDPOINT
URB_FUNCTION_CLASS_INTERFACE
URB_FUNCTION_CLASS_OTHER
URB_FUNCTION_VENDOR_DEVICE
URB_FUNCTION_VENDOR_ENDPOINT
URB_FUNCTION_VENDOR_INTERFACE
URB_FUNCTION_VENDOR_OTHER

For all other control transfer requests the direction is implied by the control transfer URB function (e.g. URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE is IN, URB_FUNCTION_SET_DESCRIPTOR_TO_DEVICE is OUT).

For URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER and URB_FUNCTION_ISOCH_TRANSFER transfer requests the direction is implied by the endpoint direction.

By itself a USBD_PIPE_HANDLE PipeHandle value as returned in a USBD_PIPE_INFORMATION structure as the result of a URB_FUNCTION_SELECT_CONFIGURATION or URB_FUNCTION_SELECT_INTERFACE request tells you nothing about the endpoint type or direction. It is an opaque value. In your examples the values 2 and 81 are not USBD_PIPE_HANDLE PipeHandle values.

As the comment in the header file says, the USB_ENDPOINT_DIRECTION_IN() macro is intended to be used with the bEndpointAddress field of a USB_ENDPOINT_DESCRIPTOR, not with a USBD_PIPE_HANDLE PipeHandle value.

If you are using WinUSB it also appears that the USB_ENDPOINT_DIRECTION_IN() macro is intended to be used with the WINUSB_PIPE_INFORMATION structure’s PipeId member. I’m not a WinUSB expert myself and I wasn’t aware of that usage.

-Glen

6

Yep, it works now.

Thanks.