USB Transfer May Fail Due to Transaction Error

Article ID: 960958
Expand all | Collapse all
Source: Microsoft Support
Back to the top | Give Feedback

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.
Back to the top | Give Feedback

Symptom

A device driver for a USB device may observe that a USB Transfer to or from the device fails due to a Transaction Error.  This error is reported to the USB device driver by the Microsoft USB core driver stack as a value of USBD_STATUS_XACT_ERROR returned in the Status field of the URB_HEADER in the USB request block (URB) submitted to the Microsoft USB core driver stack to perform the transfer to or from the device.
Back to the top | Give Feedback

Cause



This error is reported to USB device drivers by the Microsoft USB core driver stack via the USB status code USBD_STATUS_XACT_ERROR if the USB EHCI host controller sets the Transaction Error (XactErr) bit in the USB transfer descriptor upon completion of the USB transfer.  The USB EHCI host controller sets this bit if it detects that certain bus protocol errors occur during communication with the USB device.

Thus, the cause of a USB Transaction Error (XactErr) is one of the following:
  • An error in the communications with a USB device over the USB bus, caused by either the device, an external USB hub connected between the device and the USB host controller/root hub, or a faulty USB cable.
  • An error in the USB EHCI host controller itself, resulting in an erroneous report of a USB Transaction Error when in fact no error in USB bus communications occurred.
Back to the top | Give Feedback

Resolution



To identify the cause of a USB Transaction Error, a careful examination of the USB bus traffic during the time that the error was reported must be performed.
  • If examination of USB traces reveals a communication error committed by the USB device or hub that would be expected to result in a USB Transaction Error, the vendor of the faulting device should be engaged to diagnose and resolve the problem with the connected USB hardware.
  • Whether examination of USB traces reveals communication errors that would be expected to result in a USB Transaction Error or not, it's possible that at least one of the USB cables connected is faulty.  All cables involved in the connection should be replaced with known certified USB cables.  If a faulty USB cable is located between the USB bus analyzer and the attached device, then communication errors may be seen by the USB analyzer.  If a faulty USB cable is located between the USB host controller/root hub port and the USB bus analyzer, communication errors may not be seen by the USB analyzer, but may still be seen by the USB host controller.
  • If examination of USB traces reveals no communication errors that would be expected to result in a USB Transaction Error, and if the problem is not resolved by replacing the USB cables with known certified USB cables, then it's likely that the USB EHCI host controller erroneously reported a USB Transaction Error.  In this case, the vendor of the USB EHCI host controller should be contacted for further information.  Since USB EHCI host controllers are often embedded in the main chipset of the computer's motherboard, a resolution for a USB EHCI host controller error (erratum) may not be available.


To recover from USB transfers which fail with a USB status of USBD_STATUS_XACT_ERROR, USB device driver developers should take the following actions:
  • Issue a URB_FUNCTION_RESET_PIPE request for the USB endpoint that is the target of the failed transfer.  This action is normally expected to clear errors such as a Transaction Error (XactErr), and allow subsequent USB transfers to resume.
  • Before issuing a URB_FUNCTION_RESET_PIPE request, a URB_FUNCTION_ABORT_PIPE request should be issued for the USB endpoint that is the target of the failed transfer.  The URB_FUNCTION_ABORT_PIPE request will cancel all pending transfers for the specified endpoint, which is documented in the Windows Driver Kit (WDK) as a prerequisite to issuing a URB_FUNCTION_RESET_PIPE request.
  • If the above actions fail to allow subsequent USB transfers to resume for the specified USB device and endpoint, an IOCTL_INTERNAL_USB_RESET_PORT request may be issued by a kernel-mode USB device driver to reset the USB port to which the USB device is attached.  All pending transfers to all endpoints of the USB device should be cancelled via URB_FUNCTION_ABORT_PIPE requests, and the USB device driver should wait for these transfers to complete, before isssuing this request.
  • Finally, if all of the above actions fail to restore communications with the USB device following a Transaction Error, a kernel-mode USB device driver may issue an IOCTL_INTERNAL_USB_CYCLE_PORT to cause the USB device to be effectively removed from and re-enumerated on the USB port to which it is attached.  All pending transfers to all endpoints of the USB device should be cancelled via URB_FUNCTION_ABORT_PIPE requests, and the USB device driver should wait for these transfers to complete, before isssuing this request.


Installing the hotfixes referenced in Microsoft Knowledge Base article 908673 or 913365, and setting the EnSoftRetry registry value as documented in Microsoft Knowledge Base article 908673, may suppress reporting of a USBD_STATUS_XACT_ERROR for a USB transfer which completes with a USB Transaction Error (XactErr) and cause the transfer to be automatically retried.  However, since the original transfer actually failed, this behavior may be undesirable.  A USB device driver may need to be aware of the fact that the transfer actually failed, so that appropriate action can be taken.  In such situations, the hotfixes referenced in Microsoft Knowledge Base article 908673 or 913365 should not be installed, and the EnSoftRetry registry value should not be set, to allow USB Transaction Errors to be reported to the USB device driver for appropriate action.
Back to the top | Give Feedback

More Information



In the "Enhanced Host Controller Interface Specification for Universal Serial Bus" (henceforth referred to as the USB EHCI Spec),  a Transaction Error is described in sections 3.3.2, 3.4.3, and 3.5.3 as follows:

Collapse this tableExpand this table
 Bit Status Field Description
 3

Transaction Error (XactErr).
Set to a one by the Host Controller during status update in the case where the host did not receive a valid response from the device (Timeout, CRC, Bad PID, etc.). Refer to Section 4.15.1.1 for summary of the conditions that affect this bit. If the host controller sets this bit to a one, then it remains a one for the duration of the transfer. 


 

Section 4.15.1.1 of the USB EHCI Spec states:

4.15.1.1 Transaction Error
A transaction error is any error that caused the host controller to think that the transfer did not complete successfully. Table 4–18 lists the events/responses that the host can observe as a result of a transaction. The effects of the error counter and interrupt status are summarized in the following paragraphs. Most of these errors set the XactErr status bit in the appropriate interface data structure.

Additional details can be found in sections 4.15.1.1, 4.15.1.1.1, and 4.15.1.1.2 of the USB EHCI Spec.

The Enhanced Host Controller Interface Specification for Universal Serial Bus is downloadable from:

http://www.intel.com/technology/usb/ehcispec.htm
(http://www.intel.com/technology/usb/ehcispec.htm)


You may search for certified USB Implementers Forum, Inc. (USB-IF) logo compliant products at:

http://www.usb.org/kcompliance/view
(http://www.usb.org/kcompliance/view)
Back to the top | Give Feedback

DISCLAIMER

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.
Back to the top | Give Feedback

Properties

Article ID: 960958 - Last Review: December 8, 2008 - Revision: 1.0
Keywords: 
kbnomt kbrapidpub KB960958
Back to the top | Give Feedback

Give Feedback

 
Back to the topBack to the top