USB драйвер на замену usbser.sys

[WWX]

Доброго времени суток.

Есть некое устройство, которое реализует класс USB CDC. Т.е. при его подключении к ПК в системе появляется виртуальный COM-порт.

Раньше это устройство в Windows'е обслуживалось "стандартным" драйвером usbser.sys.
Но в редких случаях пропадали данные передаваемые от устройства к ПК.
Т.е. ReadFile просто не возвращал управление.
Костыльно проблема решалась установкой таймаута и повторным запросом данных от устройства.

Решено было написать свой драйвер на замену usbser.sys.
Возникла похожая проблема.
В ф-ции завершения обработки опять же в редких случаях URB_STATUS(urb) возвращает 0xC000_0011 = USBD_STATUS_XACT_ERROR.
При этом статус IRP (Irp->IoStatus.Status) 0xC000_0001 = STATUS_UNSUCCESSFUL.
Я так понимаю, что это возвращает драйвер шины.

Точно такие же коды ошибок возникают после отсоединения шнура во время пересылки.

Можно ли это считать аппаратной ошибкой?

(В своё время USB часть этого устройства несколько раз переделывалась - находились аппаратные ошибки.)

Далее я пытаюсь сделать recover (по мотивам У. Они).
Но в ответ на запрос IOCTL_INTERNAL_USB_GET_PORT_STATUS получаю статус 0xC000000E = STATUS_NO_SUCH_DEVICE, хотя физически устройство не вытаскивалось.
До появления ошибки этот запрос отрабатывается нормально: оба флага: USBD_PORT_ENABLED и USBD_PORT_CONNECTED установлены.

ОС: Windows 7 x64.

[Ochkarik]

подозреваю что может быть результатом не совсем верной аппаратной реализации.

For a high-speed bulk endpoint, USBD_STATUS_XACT_ERROR indicates that the
host controller has set the "Transaction Error (XactErr)" bit in the
transfer descriptor's status field. The EHCI spec indicates that this bit
is set when it encounters a CRC error, a timeout, an invalid PID, babble,
or a buffer error (under/overrun). Refer to section 4.15.1.1 of the EHCI
spec for specific details on what conditions will cause this error to be
returned. The spec can be found at the following URL:

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

Я в своей практике точно ловил USBD_STATUS_BABBLE_DETECTED на предельных для 2.0 скоростях обмена, при ошибках в реализации аппаратного интерфейса с готовым контроллером от  Cypress FX2LP.
насчет XACT - уже не помню, но у меня в коде при его обнаружении у стоит такая же обработка как и на USBD_STATUS_BABBLE_DETECTED и USBD_STATUS_STALL_PID. когда их ловлю - отменяю IoCancelIrp все URB  в очереди запросов, как только они все завершатся - вызываю URB_FUNCTION_SYNC_CLEAR_STALL и заполняю очередь URB запросов заново.
почему у меня такое решение - к сожалению уже не помню. но вроде на ошибки обмена никто не жаловался, сейчас FX3 практически на том же коде тоже работает на 350Мбайт/с.