We're controlling a device using an EZ-USB chipset that operates on Windows via the ::WriteFile() and ::ReadFile() interface, and made asynchronous using Completion Ports (a suggestion provided by the Cypress team). Lately, and particularly with Windows 10, when calling ::GetQueuedCompletionStatus() on a queued operation, the function returns an error, and ::GetLastError() returns 0xe0000011 — which is out-of-band. Because the application bit-flag is set, this would imply that this error is set by the application. Oddly enough, this error sometimes coincides with the operation completing successfully — but we can't (and shouldn't have to) rely on a special case code to know when an operation has completed successfully, especially when the OS is telling us there's been an error.

How do we either correct this issue so ::GetQueuedCompletionStatus() doesn't return an error on success, or interpret this error code so we can handle it in a meaningful and informed way?

Upon further investigation, it looks like this is a Thesycon USBIO error code, specifically USBIO_ERR_XACT_ERROR. According to Thesycon documentation:

USBIO_ERR_XACT_ERROR (0xE0000011)

A XACT error has been detected. This error is reported by the USB host controller driver

According to Microsoft documentation, this could be due to a number of issues:

- A bad USB cable

- The device generating USB communication errors.

- The host controller flagging a proper USB transaction in error.

We've already swapped out the USB cable with a brand new one, and while this reduced the probability of the error occurring, it does still end up occurring. We need to set up a USB trace to see whether the xact error is legit or not.

The weird thing is, while we've had these errors for a while now, they've never been as frequent as they have been in the last few weeks, and we've made no changes to our hardware/software in that time. Obviously we'd like to stabilize communication between the controller and the device — have there been any changes in the supply chain, or design changes on those chips that might cause these kinds of errors? How can we go about recovering from these errors?