Fallo en la petición de device descriptor USB en Windows: depurando Code 43 con evidencia a nivel de bus

"Unknown USB Device (Device Descriptor Request Failed)" es uno de los errores USB más comunes en Windows. El Administrador de dispositivos puede mostrar Code 43. El dispositivo puede aparecer como desconocido, fallar nada más enchufarlo o ir en una máquina pero no en otra. Los usuarios buscan "USB Device Descriptor Request Failed", "Windows Code 43 USB", "device descriptor request failed fix" y "USB enumeration failed" porque Windows da una etiqueta de usuario, no la razón a nivel de bus.

La petición del descriptor es uno de los primeros pasos de la enumeración USB. Si falla, el host no llega a saber ni qué es el dispositivo. Eso significa que los drivers de clase, el software de aplicación, los puertos serie, los HID reports y los protocolos vendor no son el primer sitio donde depurar. El fallo pasó antes de que el sistema operativo tuviera bastante información para enlazar el driver normal.

Bus Scope ayuda para esta clase de problema porque la evidencia importante está en las primeras transferencias de control tras el attach.

Qué intenta hacer Windows

Cuando se enchufa un dispositivo USB, el host detecta el attach, resetea el puerto y pide el device descriptor. El device descriptor contiene identidad básica e información de capacidad:

• Versión USB.
• Device class / subclass / protocol.
• Max packet size para endpoint zero.
• Vendor ID.
• Product ID.
• Número de release del dispositivo.
• Índice de string de fabricante.
• Índice de string de producto.
• Índice de string de número de serie.
• Número de configuraciones.

Si Windows no puede leer este descriptor de forma fiable, puede reportar "Device Descriptor Request Failed".

Qué puede significar el fallo

Este error puede deberse a:

• Firmware del dispositivo que no responde en endpoint zero.
• Cable USB malo o inestable.
• Power insuficiente.
• Reset del dispositivo durante la enumeración.
• Contenido del descriptor mal formado o inconsistente.
• Problema con el max packet size del endpoint zero.
• Problema de timing durante la recuperación tras reset.
• Compatibilidad de hub o puerto.
• Problema de negociación USB 2.0 vs USB 3.x.
• Daño eléctrico o defecto de hardware.
• Problema de driver del host controller.

La misma etiqueta de Windows cubre muchas causas raíz distintas. Por eso importa la evidencia de paquetes.

Secuencia temprana de enumeración

Una enumeración temprana sana suele parecerse a:

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

Distintos host controllers y versiones de Windows pueden variar, pero el patrón es similar. Si el primer GET_DESCRIPTOR falla, el host nunca llega al setup normal del dispositivo.

Los primeros 8 bytes importan

Los hosts suelen leer primero los primeros 8 bytes del device descriptor para conocer el packet size del endpoint zero. Si esa petición falla o devuelve datos inconsistentes, la enumeración se puede parar.

Los desarrolladores de firmware a veces prueban solo la respuesta completa del descriptor y se pierden la petición inicial corta. Un dispositivo puede ir con un host y fallar con otro porque el timing y la longitud de la petición cambian.

Busca:

• Ninguna respuesta a la primera petición de descriptor.
• Short packet donde se espera una respuesta válida.
• STALL en endpoint zero.
• Timeout seguido de reset.
• Longitud de descriptor que no encaja con la estructura esperada.
• Datos del descriptor que cambian entre intentos.

Power y bucles de reset

Si el dispositivo tarda en arrancar o consume demasiada corriente, puede resetearse durante la enumeración. Windows entonces vuelve a intentar. El resultado puede ser un bucle:

Attach
Reset
GET_DESCRIPTOR
Timeout
Reset
GET_DESCRIPTOR
Timeout
Unknown USB Device

Los usuarios pueden creer que es un problema de driver porque el error aparece en el Administrador de dispositivos. Pero si nunca se leyó el descriptor, el driver normal ni siquiera entró en juego.

Prueba un cable corto directo, otro puerto, un hub con alimentación y otro host, pero conserva la captura. La traza dice si el dispositivo falló antes o después de la respuesta de descriptor.

Descriptores mal formados

Si el dispositivo devuelve bytes de descriptor pero son inválidos, Windows puede rechazar el dispositivo. Ejemplos:

• bLength incorrecto.
• Descriptor type incorrecto.
• Longitud total de configuración que no encaja.
• Falta el endpoint descriptor.
• Interface count que no encaja.
• Max packet size inválido.
• String descriptor length que no coincide.
• Versión USB anunciada como soportada sin estarlo.

Los descriptores mal formados son especialmente habituales en firmware a medida, placas de desarrollo, cores USB en FPGA y dispositivos con stacks USB escritos a mano.

Bus Scope puede inspeccionar el contenido del descriptor directamente en lugar de depender del error genérico del Administrador de dispositivos.

Por qué va en Linux pero no en Windows

Algunos dispositivos enumeran en Linux pero fallan en Windows porque los hosts no son igual de tolerantes. Windows puede aplicar comprobaciones de consistencia de descriptores distintas. Linux puede reintentar de forma que tape problemas de timing. Un dispositivo también puede depender de un comportamiento de driver de clase que cambia entre sistemas operativos.

No concluyas que Windows se equivoca o que el dispositivo está bien. Compara las trazas de enumeración. La diferencia se suele ver en el orden de peticiones, el timing, la longitud del descriptor o el comportamiento de reset.

Checklist de depuración

Usa este proceso:

1. Captura desde antes del plug-in.
2. Identifica si la primera petición de device descriptor recibe alguna respuesta.
3. Comprueba si el endpoint zero hace STALL o timeout.
4. Inspecciona los bytes del descriptor para verificar longitud y tipo.
5. Mira si se repiten resets de puerto.
6. Compara puerto directo frente a hub.
7. Compara puertos USB 2.0 y USB 3.x.
8. Prueba otro cable.
9. Compara trazas de enumeración en Windows y Linux.
10. Si el firmware es a medida, prueba lecturas de descriptor cortas de forma explícita.

Qué incluir en un bug report

Un informe útil incluye:

• Texto del error de Windows y Code 43 si aparece.
• VID/PID del dispositivo si alguna vez se leyó.
• Si la primera petición de descriptor de 8 bytes tuvo éxito.
• Última petición USB correcta antes del fallo.
• Si se repiten los resets.
• Detalles de cable/hub/puerto.
• Captura en torno al plug-in, no solo tras el fallo.

Eso da a los equipos de firmware y driver evidencia accionable.

Diagnóstico final

"USB Device Descriptor Request Failed" significa que el host falló muy pronto en la enumeración. La causa raíz puede estar en el firmware, la estructura del descriptor, el timing, el comportamiento del endpoint zero, el power, el cable, el hub o la compatibilidad con el host. Suele ser demasiado pronto para echar la culpa a la aplicación.

Bus Scope soporta el flujo correcto: inspeccionar las primeras transferencias de control, conservar la secuencia de enumeración y diagnosticar el fallo desde el bus USB en lugar de desde una etiqueta genérica de Windows.