USB Stall Pipe Error

NTDEV
1

Hi,

I am running my program on x86 and it works fine. But when I run it on x64 it issues me an error USBD_STATUS_STALL_PID. I am sending some vendor commands on default control endpoint.

I checked my device firmware and it looks fine. Also, it does not report me any endpoint being stalled.

Also, I checked with usblyzer and it shows me that the hub is generating the error.

when i was debugging my program, if i put a delay between two usb commands then it works fine. no problem. my program is written in .net so there is no memory management problems over here.

i did verify it at the driver level that i am sending the right commands. but everywhere it is fine.

i do not know why it is issuing this error and why it vanishes when there is a delay between commands.

Regards.

2

Capture an etw trace log for the USB stack

d

Bent from my phone

From: xxxxx@prescott-instruments.commailto:xxxxx
Sent: ?10/?29/?2013 9:06 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] USB Stall Pipe Error

Hi,

I am running my program on x86 and it works fine. But when I run it on x64 it issues me an error USBD_STATUS_STALL_PID. I am sending some vendor commands on default control endpoint.

I checked my device firmware and it looks fine. Also, it does not report me any endpoint being stalled.

Also, I checked with usblyzer and it shows me that the hub is generating the error.

when i was debugging my program, if i put a delay between two usb commands then it works fine. no problem. my program is written in .net so there is no memory management problems over here.

i did verify it at the driver level that i am sending the right commands. but everywhere it is fine.

i do not know why it is issuing this error and why it vanishes when there is a delay between commands.

Regards.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

3

i did capture it. and here are the four frames where the error is

Frame: Number = 4711, Captured Frame Length = 340, MediaType = NetEvent

  • NetEvent:
  • Header:
    Size: 331 (0x14B)
    HeaderType: 0 (0x0)
  • Flags: 64 (0x40)
    ExtInfo: (…0)
    Private: (…0.)
    String: (…0…)
    Trace: (…0…)
    NoCPUTime: (…0…)
    B32: (…0…)
    B64: (…1…) EVENT_HEADER_FLAG_64_BIT_HEADER
    Reserved1: (…0…)
    Classic: (…0…)
    Reserved2: (0000000…)
  • EventProperty: 0 (0x0)
    XML: (…0)
    ForwardXML: (…0.)
    LegacyEventLog: (…0…)
    Reserved: (0000000000000…)
    ThreadId: 68 (0x44)
    ProcessId: 4, ProcessName:
    TimeStamp: 10/29/2013, 12:26:51.208177 UTC
    ProviderId: {C88A4EF5-D048-4013-9408-E04B7DB2814A}
  • Descriptor:
    Id: 46 (0x2E)
    Version: 0 (0x0)
    Channel: 16 (0x10)
    Level: WINEVENT_LEVEL_INFO
    Opcode: 0x19
    Task: 32 (0x20)
  • MicrosoftWindowsUSBUSBPORT_Keyword:
    Diagnostic: (…1) USBPORT_ETW_KEYWORD_DIAGNOSTIC
    PowerDiagnostics: (…0.)
    Reserved1: (10000000000000000000000000000000000000000000000000000000000000…)
    ProcessorTime: 3 (0x3)
    ActivityId: {00000000-0000-0000-0000-000000000000}
    ETLProvider:
  • BufferContext:
    ProcessorNumber: 0 (0x0)
    Alignment: 8 (0x8)
    LoggerId: 13 (0xD)
    ExtendedDataCount: 0 (0x0)
    UserDataLength: 251 (0xFB)
    Reassembled: 0 (0x0)
  • MicrosoftWindowsUSBUSBPORT: Dispatch URB_FUNCTION_VENDOR_DEVICE
  • USBPORT_ETW_EVENT_DISPATCH_URB_FUNCTION_VENDOR_DEVICE: Dispatch URB_FUNCTION_VENDOR_DEVICE
  • fid_USBPORT_HC:
  • DeviceObject: 0x00000000046E5050
    Ptr: 0x00000000046E5050
    PciBus: 0 (0x0)
    PciDevice: 29 (0x1D)
    PciFunction: 0 (0x0)
    PciVendorId: 32902 (0x8086)
    PciDeviceId: 7206 (0x1C26)
  • fid_USBPORT_Device:
  • DeviceHandle: 0x000000000893BDF0
    Ptr: 0x000000000893BDF0
    idVendor: 16363 (0x3FEB)
    idProduct: 33791 (0x83FF)
    PortPathDepth: 2 (0x2)
  • PortPath:
    PortPath: 1 (0x1)
    PortPath: 2 (0x2)
    PortPath: 0 (0x0)
    PortPath: 0 (0x0)
    PortPath: 0 (0x0)
    PortPath: 0 (0x0)
    DeviceSpeed: 1 (0x1)
    DeviceAddress: 5 (0x5)
  • fid_USBPORT_Endpoint:
  • Endpoint: 0x0000000008601A00
    Ptr: 0x0000000008601A00
  • PipeHandle: 0x000000000893BE40
    Ptr: 0x000000000893BE40
  • DeviceHandle: 0x000000000893BDF0
    Ptr: 0x000000000893BDF0
  • fid_USBPORT_Endpoint_Descriptor:
    fid_bLength: 7 (0x7)
    fid_bDescriptorType: 5 (0x5)
    fid_bEndpointAddress: 0 (0x0)
    fid_bmAttributes: 0 (0x0)
    fid_wMaxPacketSize: 64 (0x40)
    fid_bInterval: 0 (0x0)
  • fid_IRP_Ptr: 0x00000000093FB010
    Ptr: 0x00000000093FB010
  • fid_URB_Ptr: 0x0000000009129700
    Ptr: 0x0000000009129700
  • ControlTransfer:
  • Urb: Status = 0x0, Flags 0xa, Length = 4
    fid_URB_Hdr_Length: 136 (0x88)
    fid_URB_Hdr_Function: 23 (0x17)
    fid_URB_Hdr_Status: 0 (0x0)
  • fid_URB_Hdr_UsbdDeviceHandle: 0x000000000893BDF0
    Ptr: 0x000000000893BDF0
  • fid_URB_Hdr_UsbdFlags: 0x0000000000000022
    Ptr: 0x0000000000000022
  • fid_URB_PipeHandle: 0x000000000893BE40
    Ptr: 0x000000000893BE40
    fid_URB_TransferFlags: 10 (0xA)
    fid_URB_TransferBufferLength: 4 (0x4)
  • fid_URB_TransferBuffer: 0x000000000722C6E0
    Ptr: 0x000000000722C6E0
  • fid_URB_TransferBufferMDL: 0x0000000008E50010
    Ptr: 0x0000000008E50010
  • fid_URB_ReservedMBZ: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x00000000092244D0
    Ptr: 0x00000000092244D0
  • fid_URB_ReservedHcd: 0x00000000DEADF00D
    Ptr: 0x00000000DEADF00D
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • fid_URB_ReservedHcd: 0x0000000000000000
    Ptr: 0x0000000000000000
  • SetupPacket:
  • bmRequestType: (Vendor request) 0x40
    Recipient: (…00000) Device
    Type: (.10…) Vendor
    Direction: (0…) Host-to-device
    bRequest: 0xc
    wValue: 0 (0x0)
    wIndex: 0 (0x0)
    wLength: 4 (0x4)

Frame: Number = 4712, Captured Frame Length = 109, MediaType = NetEvent

  • NetEvent:
  • Header:
    Size: 100 (0x64)
    HeaderType: 0 (0x0)
  • Flags: 64 (0x40)
    ExtInfo: (…0)
    Private: (…0.)
    String: (…0…)
    Trace: (…0…)
    NoCPUTime: (…0…)
    B32: (…0…)
    B64: (…1…) EVENT_HEADER_FLAG_64_BIT_HEADER
    Reserved1: (…0…)
    Classic: (…0…)
    Reserved2: (0000000…)
  • EventProperty: 0 (0x0)
    XML: (…0)
    ForwardXML: (…0.)
    LegacyEventLog: (…0…)
    Reserved: (0000000000000…)
    ThreadId: 68 (0x44)
    ProcessId: 4, ProcessName:
    TimeStamp: 10/29/2013, 12:26:51.208182 UTC
    ProviderId: {C88A4EF5-D048-4013-9408-E04B7DB2814A}
  • Descriptor:
    Id: 8 (0x8)
    Version: 0 (0x0)
    Channel: 16 (0x10)
    Level: WINEVENT_LEVEL_INFO
    Opcode: 0x13
    Task: 2 (0x2)
  • MicrosoftWindowsUSBUSBPORT_Keyword:
    Diagnostic: (…1) USBPORT_ETW_KEYWORD_DIAGNOSTIC
    PowerDiagnostics: (…1.) USBPORT_ETW_KEYWORD_POWER_DIAGNOSTICS
    Reserved1: (10000000000000000000000000000000000000000000000000000000000000…)
    ProcessorTime: 3 (0x3)
    ActivityId: {00000000-0000-0000-0000-000000000000}
    ETLProvider:
  • BufferContext:
    ProcessorNumber: 0 (0x0)
    Alignment: 8 (0x8)
    LoggerId: 13 (0xD)
    ExtendedDataCount: 0 (0x0)
    UserDataLength: 20 (0x14)
    Reassembled: 0 (0x0)
  • MicrosoftWindowsUSBUSBPORT: Host Controller Async Schedule Enable
  • USBPORT_ETW_EVENT_HC_ASYNC_SCHEDULE_ENABLE: Host Controller Async Schedule Enable

Frame: Number = 4713, Captured Frame Length = 109, MediaType = NetEvent

  • NetEvent:
  • Header:
    Size: 100 (0x64)
    HeaderType: 0 (0x0)
  • Flags: 64 (0x40)
    ExtInfo: (…0)
    Private: (…0.)
    String: (…0…)
    Trace: (…0…)
    NoCPUTime: (…0…)
    B32: (…0…)
    B64: (…1…) EVENT_HEADER_FLAG_64_BIT_HEADER
    Reserved1: (…0…)
    Classic: (…0…)
    Reserved2: (0000000…)
  • EventProperty: 0 (0x0)
    XML: (…0)
    ForwardXML: (…0.)
    LegacyEventLog: (…0…)
    Reserved: (0000000000000…)
    ThreadId: 0 (0x0)
    ProcessId: 0, ProcessName:
    TimeStamp: 10/29/2013, 12:26:51.208398 UTC
    ProviderId: {C88A4EF5-D048-4013-9408-E04B7DB2814A}
  • Descriptor:
    Id: 9 (0x9)
    Version: 0 (0x0)
    Channel: 16 (0x10)
    Level: WINEVENT_LEVEL_INFO
    Opcode: 0x14
    Task: 2 (0x2)
  • MicrosoftWindowsUSBUSBPORT_Keyword:
    Diagnostic: (…1) USBPORT_ETW_KEYWORD_DIAGNOSTIC
    PowerDiagnostics: (…1.) USBPORT_ETW_KEYWORD_POWER_DIAGNOSTICS
    Reserved1: (10000000000000000000000000000000000000000000000000000000000000…)
    ProcessorTime: 834081 (0xCBA21)
    ActivityId: {00000000-0000-0000-0000-000000000000}
    ETLProvider:
  • BufferContext:
    ProcessorNumber: 0 (0x0)
    Alignment: 8 (0x8)
    LoggerId: 13 (0xD)
    ExtendedDataCount: 0 (0x0)
    UserDataLength: 20 (0x14)
    Reassembled: 0 (0x0)
  • MicrosoftWindowsUSBUSBPORT: Host Controller Async Schedule Disable
  • USBPORT_ETW_EVENT_HC_ASYNC_SCHEDULE_DISABLE: Host Controller Async Schedule Disable

Frame: Number = 4714, Captured Frame Length = 340, MediaType = NetEvent

  • NetEvent:
  • Header:
    Size: 331 (0x14B)
    HeaderType: 0 (0x0)
  • Flags: 64 (0x40)
    ExtInfo: (…0)
    Private: (…0.)
    String: (…0…)
    Trace: (…0…)
    NoCPUTime: (…0…)
    B32: (…0…)
    B64: (…1…) EVENT_HEADER_FLAG_64_BIT_HEADER
    Reserved1: (…0…)
    Classic: (…0…)
    Reserved2: (0000000…)
  • EventProperty: 0 (0x0)
    XML: (…0)
    ForwardXML: (…0.)
    LegacyEventLog: (…0…)
    Reserved: (0000000000000…)
    ThreadId: 0 (0x0)
    ProcessId: 0, ProcessName:
    TimeStamp: 10/29/2013, 12:26:51.208402 UTC
    ProviderId: {C88A4EF5-D048-4013-9408-E04B7DB2814A}
  • Descriptor:
    Id: 66 (0x42)
    Version: 0 (0x0)
    Channel: 16 (0x10)
    Level: WINEVENT_LEVEL_INFO
    Opcode: 0x1a
    Task: 10 (0xA)
  • MicrosoftWindowsUSBUSBPORT_Keyword:
    Diagnostic: (…1) USBPORT_ETW_KEYWORD_DIAGNOSTIC
    PowerDiagnostics: (…0.)
    Reserved1: (10000000000000000000000000000000000000000000000000000000000000…)
    ProcessorTime: 834081 (0xCBA21)
    ActivityId: {00000000-0000-0000-0000-000000000000}
    ETLProvider:
  • BufferContext:
    ProcessorNumber: 0 (0x0)
    Alignment: 8 (0x8)
    LoggerId: 13 (0xD)
    ExtendedDataCount: 0 (0x0)
    UserDataLength: 251 (0xFB)
    Reassembled: 0 (0x0)
  • MicrosoftWindowsUSBUSBPORT: Complete URB_FUNCTION_CONTROL_TRANSFER
  • USBPORT_ETW_EVENT_COMPLETE_URB_FUNCTION_CONTROL_TRANSFER: Complete URB_FUNCTION_CONTROL_TRANSFER
4

Any solution?

5

Consider that you are sending two commands, A and B.

Command A takes time T(A) to complete

What are you doing in your firmware while command A is being processed?

Let T(B-A) represent the time between the receipt of A and the arrival of B.

If B arrives in time T(B - A) < T(A), what happens to it?

I am not an expert on hubs, but why would a hub reject a command? Perhaps
because it has unsuccessfully tried to send B to the device, which is busy
off doing A, and can’t be bothered.

So where you say you “checked the firmware”, what did you check for?
Proper execution of A and B, or did you also determine T(A) and figure out
what happens if B arrives before T(A) expires?

I have seen similar problems on other networks when there were timing
glitches like this. I had to insert a Sleep(5) [which is actually
Sleep(15), but I decided to treat it as if I didn’t know there was any
round-up being applied, in case some day Windows changed how it handled
Sleep() to handle shorter intervals than a motherboard tick.]
joe

Any solution?

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

6

xxxxx@prescott-instruments.com wrote:

Any solution?

There’s nothing particularly interesting in your ETW log. It shows a
vendor command (0x0c) with a 4-byte payload, and that’s pretty much it.
Is it possible your device is sending back more than 4 bytes? That
would cause the hub to report an error (although it should be a “babble”
error, not a “stall”).

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