Échec de requête de descripteur de périphérique USB sous Windows : débogage Code 43 avec preuves au niveau bus

« Unknown USB Device (Device Descriptor Request Failed) » est l'une des erreurs USB Windows les plus courantes. Le Gestionnaire de périphériques peut afficher Code 43. Le périphérique peut apparaître comme inconnu, échouer immédiatement après le branchement, ou marcher sur une machine mais pas une autre. Les utilisateurs cherchent « USB Device Descriptor Request Failed », « Windows Code 43 USB », « device descriptor request failed fix » ou « USB enumeration failed » car Windows donne un label côté utilisateur, pas la raison au niveau bus.

La requête de descripteur est l'une des premières étapes de l'énumération USB. Si elle échoue, l'hôte ne peut même pas apprendre ce qu'est le périphérique. Cela signifie que les pilotes de classe, le logiciel applicatif, les ports série, les rapports HID et les protocoles vendor ne sont pas le premier endroit où déboguer. La défaillance s'est produite avant que l'OS ait assez d'informations pour lier le pilote normal.

Bus Scope est utile pour cette classe de problème car la preuve importante est dans les premiers transferts de contrôle après l'attachement.

Ce que Windows essaie de faire

Quand un périphérique USB est branché, l'hôte détecte l'attachement, reset le port et demande le descripteur de périphérique. Le descripteur de périphérique contient les informations d'identité et de capacité de base :

• version USB
• device class/subclass/protocol
• taille de paquet max pour l'endpoint zéro
• Vendor ID
• Product ID
• numéro de release du périphérique
• index de string manufacturer
• index de string product
• index de string numéro de série
• nombre de configurations

Si Windows ne peut pas lire ce descripteur de façon fiable, il peut signaler « Device Descriptor Request Failed ».

Ce que la défaillance peut signifier

Cette erreur peut être causée par :

• firmware du périphérique qui ne répond pas sur l'endpoint zéro
• câble USB mauvais ou instable
• alimentation insuffisante
• reset du périphérique pendant l'énumération
• contenu de descripteur mal formé ou incohérent
• problème de taille de paquet max de l'endpoint zéro
• problème de timing pendant la récupération après reset
• problème de compatibilité hub ou port
• problème de négociation USB 2.0 vs USB 3.x
• dommage électrique ou défaut hardware
• problème de pilote de contrôleur hôte

Le même label Windows couvre de nombreuses causes racines différentes. C'est pourquoi la preuve de paquets compte.

Séquence d'énumération précoce

Une énumération précoce saine ressemble souvent à :

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

Différents contrôleurs hôtes et versions de Windows peuvent varier, mais le motif est similaire. Si le premier GET_DESCRIPTOR échoue, l'hôte n'atteint jamais le setup normal du périphérique.

Les 8 premiers octets comptent

Les hôtes lisent souvent les 8 premiers octets du descripteur de périphérique d'abord pour apprendre la taille de paquet de l'endpoint zéro. Si cette requête échoue ou renvoie des données incohérentes, l'énumération peut s'arrêter.

Les développeurs firmware testent parfois seulement la réponse complète du descripteur et manquent la requête initiale courte. Un périphérique peut marcher avec un hôte et échouer avec un autre car le timing et la longueur de requête diffèrent.

Cherchez :

• aucune réponse à la première requête de descripteur
• paquet court là où une réponse valide est attendue
• stall sur l'endpoint zéro
• timeout suivi d'un reset
• longueur de descripteur qui ne correspond pas à la structure attendue
• données de descripteur changeant entre les tentatives

Boucles d'alimentation et reset

Si le périphérique s'alimente lentement ou consomme trop de courant, il peut reset pendant l'énumération. Windows retente alors. Le résultat peut être une boucle :

Attach
Reset
GET_DESCRIPTOR
Timeout
Reset
GET_DESCRIPTOR
Timeout
Unknown USB Device

Les utilisateurs peuvent penser que c'est un problème de pilote car l'erreur apparaît dans le Gestionnaire de périphériques. Mais si le descripteur n'a jamais été lu, le pilote normal n'était pas encore impliqué.

Essayez un câble direct court, un autre port, un hub alimenté et un autre hôte, mais conservez la capture. La trace dit si le périphérique a échoué avant ou après la réponse au descripteur.

Descripteurs mal formés

Si le périphérique renvoie des octets de descripteur mais qu'ils sont invalides, Windows peut rejeter le périphérique. Exemples :

• mauvais bLength
• mauvais type de descripteur
• décalage de longueur totale de configuration
• descripteur d'endpoint manquant
• décalage du nombre d'interfaces
• taille de paquet max invalide
• décalage de longueur de descripteur string
• affirmations de version USB non supportées

Les descripteurs mal formés sont particulièrement fréquents dans le firmware personnalisé, cartes de développement, cœurs USB FPGA, et périphériques avec des piles USB écrites à la main.

Bus Scope aide à inspecter directement le contenu des descripteurs au lieu de s'appuyer sur une erreur générique du Gestionnaire de périphériques.

Pourquoi ça marche sous Linux mais pas Windows

Certains périphériques s'énumèrent sous Linux mais échouent sous Windows car les hôtes ne sont pas également tolérants. Windows peut appliquer différemment la cohérence des descripteurs. Linux peut retenter d'une façon qui masque les problèmes de timing. Un périphérique peut aussi dépendre d'un comportement de pilote de classe qui diffère entre OS.

Ne concluez pas que Windows a tort ou que le périphérique va bien. Comparez les traces d'énumération. La différence est souvent visible dans l'ordre des requêtes, le timing, la longueur de descripteur ou le comportement de reset.

Checklist de débogage

Suivez ce processus :

1. Capturez depuis avant le branchement.
2. Identifiez si la première requête de descripteur de périphérique reçoit une réponse.
3. Vérifiez si l'endpoint zéro stall ou timeout.
4. Inspectez les octets de descripteurs pour la correction de longueur et de type.
5. Vérifiez les resets de port répétés.
6. Comparez port direct vs hub.
7. Comparez ports USB 2.0 et USB 3.x.
8. Comparez avec un autre câble.
9. Comparez les traces d'énumération Windows et Linux.
10. Si le firmware est personnalisé, testez explicitement les lectures de descripteurs courts.

Que inclure dans un rapport de bug

Un rapport utile inclut :

• texte d'erreur Windows et Code 43 si présent
• VID/PID du périphérique s'il a jamais été lu
• si la requête de descripteur de 8 octets réussit
• dernière requête USB réussie avant la défaillance
• si les resets se répètent
• détails câble/hub/port
• capture autour du branchement, pas seulement après la défaillance

Cela donne aux équipes firmware et pilote des preuves actionnables.

Diagnostic final

« USB Device Descriptor Request Failed » signifie que l'hôte a échoué très tôt dans l'énumération. La cause racine peut être firmware, structure de descripteur, timing, comportement de l'endpoint zéro, alimentation, câble, hub ou compatibilité hôte. Il est généralement trop tôt pour blâmer l'application.

Bus Scope supporte le bon flux : inspecter les premiers transferts de contrôle, conserver la séquence d'énumération, et diagnostiquer la défaillance depuis le bus USB au lieu d'un label Windows générique.