When our USB function driver is used in a loop or for a long transfer of data
(MBs) on a Bulk endpoint, after a short period of time the I/O status (IRP)
returns a failure but the URB status is successful. This is after hundreds of
successful requests. The IRP errors have been STATUS_IO_DEVICE_ERROR or
STATUS_IO_TIMEOUT. The URB status is USBD_STATUS_SUCCESS in either case. In
what conditions would the Windows USB stack return these errors and the URB
be successful?

Second question, when testing for IRP error codes from a
IOCTL_INTERNAL_USB_SUBMIT_URB request, which I/O status should be tested?

IO_STATUS_BLOCK ioStatus = { 0, 0 };

PIRP irp = IoBuildDeviceIoControlRequest(...., &ioStatus);
// Boilerplate code...
ntStatus = IoCallDriver(pdx->lowerDeviceObject, irp);
if (ntStatus == STATUS_PENDING)
// Wait on event

At this point is io.Status.Status == irp->IoStatus.Status ???? If not,
which is the proper method??

Thanks,
SteveB, MCSD
Welch Allyn, Inc.

io.Status.Status will be == to irp->IoStatus.Status when the irp completes,
ie after the wait on the event is satisfied.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"SteveB" <diverdown@newsgroup.nospam> wrote in message
news:8EA3CAF1-468E-4366-B428-8B7794349934@microsoft.com...

Can you expand on the disparity between the NTSTATUS and URB status codes
noted below? Should one have more precedence over the other?

TIA,
Steve.

"Doron Holan [MS]" wrote:

I can't find any circumstances where the USB stack will return an IRP
status of STATUS_IO_DEVICE_ERROR or STATUS_IO_TIMEOUT. The root cause
must be something other than the core USB stack.


Thanks,
Martin Borve [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

When sending URB requests, which error code should I *rely on*, the URB
status (urb->UrbHeader.Status) or the IRP status (irp->ioStatus.Status.) My
problem is I am receiving conflicting result codes. The URB status is
successful and the IRP status returns an error.

Thanks,
Steve.


""Martin Borve [MSFT]"" wrote:

Steve,

Normally you would check the IRP status first. The exception to this would
be isoch transfers, in which case you need to check each isoch packet for
an error.

The behavior you are describing is not consistent with the USB stack. If
you are getting an IRP error and no USBD error, something is really wrong.
You don't have any filter drivers installed in the USB stack? If not, you
might try installing the checked USB drivers and see if they provide any
insight into the problem.

Thanks,
Martin Borve [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.