Issue with BulkUsb_ReadWriteCompletion returning and error

NTDEV
1

I have a USB device that seems to randomly stop communicating with the
PC. It is communicating just fine for a while, then stops.

The firmware in the device seems to be functioning correctly when the
error occurs. We have an LED that lights up when it receives a USB
communication, and turns off when it sends the response back over the
USB. The light is always off when the error occurs. It is difficult to
get other debug output from the device – we have a few LEDs that we
tried turning on for various things that we thought might be causing the
error, but none of them light up. The only other way to get debug
output is through the USB.

The PC software uses a Windows.ReadFile API call to get the data from
the USB. When the error occurs, this ReadFile is unsuccessful, and the
GetLastError code is 31 (A device attached to the system is not
functioning). If I do another GetLastError a short time later, it
returns error 233 (No device is on the other end of the pipe).
At this level, I tried to retry the Windows.ReadFile call. When it is
retried, it never returns from the API call.

I put other debug output in at the driver level. There is a routine
named BulkUsb_ReadWriteCompletion, which is called with an irp. When
the error occurs, the status of the irp is C0000001
(STATUS_UNSUCCESSFUL). I put 5 million other debug statements into the
driver to try to determine what is happening when this is set but so far
have had no luck.

I have the following questions -
What is the proper response of the PC software when the Windows.ReadFile
API call fails? Should I be able to retry? Is there some API I need to
use to reset something before it retries?

Any advice on how to determine if the problem is in the PC software, USB
driver, device firmware, or USB electronics?

2

A couple of the following details may help experts of the list to
isolate the issue.

  1. Which pc side Windows OS you are using.

  2. You have driver on host side, that means the USB
    device is of custom class like Bulk class.

  3. ReadFile can be used both synchronously and
    asynchronously. Did you have overlapped structure
    parameter in CreateFile.

  4. USB driver sample can be found at
    WinDDK\7600.16385.1\src\usb\usbsamp along with
    the bulk endpoints test application. You can remove
    your existing driver and use this sample. If the test
    application behaves as expected, then we can
    eliminate driver part from the suspicious list.

Regards.

On Wed, Nov 17, 2010 at 12:06 PM, Frank Bishop
wrote:
>
> I have a USB device that seems to randomly stop communicating with the PC.
> ?It is communicating just fine for a while, then stops.
>
> The firmware in the device seems to be functioning correctly when the error
> occurs. ?We have an LED that lights up when it receives a USB communication,
> and turns off when it sends the response back over the USB. ?The light is
> always off when the error occurs. ?It is difficult to get other debug output
> from the device – we have a few LEDs that we tried turning on for various
> things that we thought might be causing the error, but none of them light
> up. ?The only other way to get debug output is through the USB.
>
> The PC software uses a Windows.ReadFile API call to get the data from the
> USB. ?When the error occurs, this ReadFile is unsuccessful, and the
> GetLastError code is 31 (A device attached to the system is not
> functioning). ?If I do another GetLastError a short time later, it returns
> error 233 (No device is on the other end of the pipe).
> At this level, I tried to retry the Windows.ReadFile call. ?When it is
> retried, it never returns from the API call.
>
> I put other debug output in at the driver level. ?There is a routine named
> BulkUsb_ReadWriteCompletion, which is called with an irp. ?When the error
> occurs, the status of the irp is C0000001 (STATUS_UNSUCCESSFUL). ?I put 5
> million other debug statements into the driver to try to determine what is
> happening when this is set but so far have had no luck.
>
> I have the following questions -
> What is the proper response of the PC software when the Windows.ReadFile API
> call fails? ?Should I be able to retry? ?Is there some API I need to use to
> reset something before it retries?
>
> Any advice on how to determine if the problem is in the PC software, USB
> driver, device firmware, or USB electronics?
>
> —
> 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

On 11/17/2010 7:36 AM, Frank Bishop wrote:

Any advice on how to determine if the problem is in the PC software, USB
driver, device firmware, or USB electronics?

Try using your device behind an USB hub, please.

One our customers had an USB problem where all would work well, then
after ~30 minutes our device was suddenly not found anymore.

Turned out the problem happened only on a docking station USB port.
Using another built-in port fixed the problem.