USB Device Descriptor Request Failed в Windows: отладка Code 43 через доказательства на уровне шины

«Unknown USB Device (Device Descriptor Request Failed)» — одна из самых частых ошибок USB в Windows. Диспетчер устройств может показать Code 43. Устройство может появиться как неизвестное, упасть сразу после подключения или работать на одной машине, но не на другой. Пользователи ищут «USB Device Descriptor Request Failed», «Windows Code 43 USB», «device descriptor request failed fix», «USB enumeration failed», потому что Windows даёт пользовательскую метку, а не причину на уровне шины.

Запрос дескриптора — один из самых ранних шагов USB-перечисления. Если он падает, хост не может даже узнать, что это за устройство. Значит, драйверы класса, прикладное ПО, serial-порты, HID-репорты и вендорные протоколы — не первое место отладки. Сбой произошёл до того, как ОС получила достаточно информации для привязки обычного драйвера.

Bus Scope полезен для этого класса проблем, потому что важные доказательства в первых управляющих передачах после подключения.

Что пытается сделать Windows

Когда USB-устройство воткнуто, хост обнаруживает attach, сбрасывает порт и запрашивает device descriptor. Device descriptor содержит базовую идентичность и информацию о возможностях:

• Версия USB
• Device class/subclass/protocol
• Max packet size для endpoint 0
• Vendor ID
• Product ID
• Device release number
• Индекс строки производителя
• Индекс строки продукта
• Индекс строки serial-номера
• Число конфигураций

Если Windows не может надёжно прочитать этот дескриптор, он может сообщить «Device Descriptor Request Failed».

Что может означать сбой

Эта ошибка может быть вызвана:

• Прошивка устройства не отвечает на endpoint 0.
• Плохой или нестабильный USB-кабель.
• Недостаточное питание.
• Reset устройства во время перечисления.
• Содержимое дескриптора искажено или несогласовано.
• Проблема max packet size endpoint 0.
• Проблема таймингов при восстановлении после reset.
• Проблема совместимости концентратора или порта.
• Проблема negotiation USB 2.0 vs USB 3.x.
• Электрическое повреждение или дефект аппаратуры.
• Проблема драйвера хост-контроллера.

Та же метка Windows покрывает много разных корневых причин. Поэтому важны пакетные данные.

Ранняя последовательность перечисления

Здоровое раннее перечисление часто выглядит так:

Port attach
Port reset
GET_DESCRIPTOR(Device, first 8 bytes)
SET_ADDRESS
GET_DESCRIPTOR(Device, full)
GET_DESCRIPTOR(Configuration)
SET_CONFIGURATION

Разные хост-контроллеры и версии Windows могут варьировать, но паттерн похожий. Если первый GET_DESCRIPTOR падает, хост никогда не доходит до нормальной настройки устройства.

Первые 8 байт важны

Хосты часто сначала читают первые 8 байт device descriptor, чтобы узнать packet size endpoint 0. Если этот запрос падает или возвращает несогласованные данные, перечисление может остановиться.

Разработчики прошивок иногда тестируют только полный ответ дескриптора и пропускают первый короткий запрос. Устройство может работать на одном хосте и падать на другом из-за разных таймингов и длин запроса.

Ищите:

• Нет ответа на первый запрос дескриптора.
• Короткий пакет там, где ожидается валидный ответ.
• Stall на endpoint 0.
• Тайм-аут, за которым идёт reset.
• Длина дескриптора не совпадает с ожидаемой структурой.
• Данные дескриптора меняются между попытками.

Циклы reset от питания

Если устройство стартует медленно или тянет слишком много тока, оно может сбрасываться во время перечисления. Windows тогда пробует снова. Результат может быть циклом:

Attach
Reset
GET_DESCRIPTOR
Timeout
Reset
GET_DESCRIPTOR
Timeout
Unknown USB Device

Пользователи могут думать, что это проблема драйвера, потому что ошибка появляется в Диспетчере устройств. Но если дескриптор вообще не был прочитан, обычный драйвер ещё не участвует.

Попробуйте короткий прямой кабель, другой порт, концентратор с питанием и другой хост, но сохраните захват. Трасса скажет, упало ли устройство до или после ответа дескриптора.

Искажённые дескрипторы

Если устройство возвращает байты дескриптора, но они невалидны, Windows может отвергнуть устройство. Примеры:

• Неверный bLength.
• Неверный тип дескриптора.
• Несовпадение полной длины конфигурации.
• Пропущенный endpoint descriptor.
• Несовпадение числа интерфейсов.
• Невалидный max packet size.
• Несовпадение длины строкового дескриптора.
• Неподдерживаемые заявления версии USB.

Искажённые дескрипторы особенно часты в кастомных прошивках, отладочных платах, USB-ядрах FPGA и устройствах с USB-стеками, написанными вручную.

Bus Scope помогает проверить содержимое дескриптора напрямую, а не полагаться на общую ошибку Диспетчера устройств.

Почему работает в Linux, но не в Windows

Часть устройств перечисляется в Linux, но падает в Windows, потому что хосты не одинаково толерантны. Windows может иначе применять согласованность дескрипторов. Linux может ретраить так, что прячет тайминговые проблемы. Устройство может также зависеть от классового драйвера, который отличается между ОС.

Не делайте вывод, что Windows неправа или устройство в порядке. Сравните трассы перечисления. Различие часто видно в порядке запросов, таймингах, длине дескриптора или поведении reset.

Чек-лист отладки

Используйте такой процесс:

1. Захватите до подключения.
2. Определите, есть ли ответ на первый запрос device descriptor.
3. Проверьте, ставит ли endpoint 0 stall или тайм-аутит.
4. Проверьте байты дескриптора на корректность длины и типа.
5. Проверьте повторяющиеся reset-ы порта.
6. Сравните прямой порт и через концентратор.
7. Сравните USB 2.0 и USB 3.x порты.
8. Сравните другой кабель.
9. Сравните трассы перечисления Windows и Linux.
10. Если прошивка кастомная, явно протестируйте короткие чтения дескриптора.

Что включать в багрепорт

Полезный отчёт включает:

• Текст ошибки Windows и Code 43, если есть.
• VID/PID устройства, если когда-либо прочитаны.
• Успешен ли первый 8-байтовый запрос дескриптора.
• Последний успешный USB-запрос до сбоя.
• Повторяются ли reset-ы.
• Детали кабеля/концентратора/порта.
• Захват вокруг подключения, а не только после сбоя.

Это даёт командам прошивок и драйверов действенные доказательства.

Итоговый диагноз

«USB Device Descriptor Request Failed» значит, что хост упал очень рано в перечислении. Корневая причина может быть в прошивке, структуре дескриптора, таймингах, поведении endpoint 0, питании, кабеле, концентраторе или совместимости с хостом. Обычно рано винить приложение.

Bus Scope поддерживает правильный воркфлоу: проверить первые управляющие передачи, сохранить последовательность перечисления и диагностировать сбой по USB-шине, а не по общей метке Windows.