USB Device Descriptor Request Failed unter Windows: Code 43 mit Bus-Level-Evidence debuggen

"Unknown USB Device (Device Descriptor Request Failed)" ist einer der häufigsten Windows-USB-Fehler. Device Manager mag Code 43 zeigen. Das Device erscheint möglicherweise als unknown, scheitert sofort nach dem Anstecken oder läuft auf einer Maschine, aber nicht auf einer anderen. Nutzer suchen nach "USB Device Descriptor Request Failed", "Windows Code 43 USB", "device descriptor request failed fix" und "USB enumeration failed", weil Windows ein User-Facing-Label gibt, nicht den Bus-Level-Grund.

Der Deskriptor-Request ist einer der frühesten Schritte in der USB-Enumeration. Schlägt er fehl, kann der Host nicht einmal lernen, was das Device ist. Das heißt, Klassentreiber, Anwendungssoftware, Serial-Ports, HID-Reports und Vendor-Protokolle sind nicht der erste Ort zum Debuggen. Der Fehler passierte, bevor das OS genug Informationen hatte, um den normalen Treiber zu binden.

Bus Scope hilft für diese Klasse von Issues, weil die wichtige Evidence in den ersten Control-Transfers nach dem Attach liegt.

Was Windows versucht

Wenn ein USB-Device angesteckt wird, erkennt der Host das Attach, resettet den Port und fragt nach dem Device-Deskriptor. Der Device-Deskriptor enthält grundlegende Identitäts- und Capability-Informationen:

• USB-Version
• Device-Class/Subclass/Protocol
• Maximale Paketgröße für Endpoint Null
• Vendor-ID
• Product-ID
• Device-Release-Number
• Manufacturer-String-Index
• Product-String-Index
• Serial-Number-String-Index
• Anzahl der Konfigurationen

Kann Windows diesen Deskriptor nicht zuverlässig lesen, meldet es möglicherweise "Device Descriptor Request Failed".

Was der Fehler bedeuten kann

Dieser Fehler kann verursacht sein durch:

• Device-Firmware antwortet nicht auf Endpoint Null.
• schlechtes oder instabiles USB-Kabel.
• unzureichende Stromversorgung.
• Device-Reset während der Enumeration.
• Deskriptor-Inhalt fehlerhaft oder inkonsistent.
• Endpoint-Null-Max-Packet-Size-Problem.
• Timing-Issue während Reset-Recovery.
• Hub- oder Port-Kompatibilitäts-Issue.
• USB-2.0- vs. USB-3.x-Verhandlungs-Problem.
• elektrischer Schaden oder Hardware-Defekt.
• Host-Controller-Treiber-Problem.

Dasselbe Windows-Label deckt viele verschiedene Root-Causes ab. Deshalb zählt Packet-Evidence.

Frühe Enumeration-Sequenz

Eine gesunde frühe Enumeration sieht oft so aus:

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

Verschiedene Host-Controller und Windows-Versionen können variieren, aber das Muster ist ähnlich. Schlägt die erste GET_DESCRIPTOR fehl, erreicht der Host nie das normale Device-Setup.

Die ersten 8 Bytes zählen

Hosts lesen oft die ersten 8 Bytes des Device-Deskriptors zuerst, um die Endpoint-Null-Paketgröße zu lernen. Scheitert dieser Request oder gibt er inkonsistente Daten zurück, kann die Enumeration stoppen.

Firmware-Entwickler testen manchmal nur die volle Deskriptor-Antwort und verpassen den kurzen initialen Request. Ein Device kann mit einem Host laufen und mit einem anderen scheitern, weil Timing und Request-Länge abweichen.

Achten Sie auf:

• keine Antwort auf den ersten Deskriptor-Request.
• Short-Paket, wo eine valide Antwort erwartet wird.
• Stall auf Endpoint Null.
• Timeout gefolgt von Reset.
• Deskriptor-Länge, die nicht zur erwarteten Struktur passt.
• wechselnde Deskriptor-Daten zwischen Versuchen.

Power- und Reset-Loops

Fährt das Device langsam hoch oder zieht zu viel Strom, kann es während der Enumeration resetten. Windows versucht es dann erneut. Das Ergebnis kann eine Loop sein:

Attach
Reset
GET_DESCRIPTOR
Timeout
Reset
GET_DESCRIPTOR
Timeout
Unknown USB Device

Nutzer denken möglicherweise, es sei ein Treiber-Issue, weil der Fehler im Device Manager erscheint. Aber wenn der Deskriptor nie gelesen wurde, war der normale Treiber noch nicht beteiligt.

Versuchen Sie ein kurzes direktes Kabel, einen anderen Port, einen powered Hub und einen anderen Host, aber bewahren Sie den Capture. Der Trace sagt, ob das Device vor oder nach der Deskriptor-Antwort gescheitert ist.

Fehlerhafte Deskriptoren

Gibt das Device Deskriptor-Bytes zurück, die aber ungültig sind, kann Windows das Device ablehnen. Beispiele:

• falsche bLength.
• falscher Deskriptor-Typ.
• Mismatch der Configuration-Gesamtlänge.
• Endpoint-Deskriptor fehlt.
• Interface-Anzahl-Mismatch.
• ungültige Max-Packet-Size.
• String-Deskriptor-Längen-Mismatch.
• nicht unterstützte USB-Versions-Behauptungen.

Fehlerhafte Deskriptoren sind besonders häufig in Custom-Firmware, Dev-Boards, FPGA-USB-Cores und Devices mit handgeschriebenen USB-Stacks.

Bus Scope hilft, Deskriptor-Inhalt direkt zu inspizieren, statt sich auf einen generischen Device-Manager-Fehler zu verlassen.

Warum es unter Linux läuft, aber nicht unter Windows

Manche Devices enumerieren unter Linux, scheitern aber unter Windows, weil Hosts nicht gleich tolerant sind. Windows kann Deskriptor-Konsistenz anders durchsetzen. Linux kann auf eine Weise retryen, die Timing-Issues versteckt. Ein Device kann auch von einem Class-Driver-Verhalten abhängen, das zwischen Betriebssystemen abweicht.

Schließen Sie nicht, dass Windows falsch liegt oder das Device in Ordnung ist. Vergleichen Sie die Enumeration-Traces. Der Unterschied ist oft in Request-Reihenfolge, Timing, Deskriptor-Länge oder Reset-Verhalten sichtbar.

Debug-Checkliste

Nutzen Sie diesen Ablauf:

1. Capturen, bevor Sie anstecken.
2. Identifizieren, ob der erste Device-Deskriptor-Request eine Antwort bekommt.
3. Prüfen, ob Endpoint Null stalled oder timed out.
4. Deskriptor-Bytes auf Längen- und Typ-Korrektheit prüfen.
5. Auf wiederholte Port-Resets prüfen.
6. Direkter Port vs. Hub vergleichen.
7. USB-2.0- und USB-3.x-Ports vergleichen.
8. Anderes Kabel vergleichen.
9. Windows- und Linux-Enumeration-Traces vergleichen.
10. Wenn die Firmware custom ist, kurze Deskriptor-Reads explizit testen.

Was in einen Bug-Report gehört

Ein nützlicher Report enthält:

• Windows-Fehlertext und Code 43, falls vorhanden.
• Device VID/PID, falls je gelesen.
• ob der erste 8-Byte-Deskriptor-Request erfolgreich ist.
• letzten erfolgreichen USB-Request vor dem Fehler.
• ob sich Resets wiederholen.
• Kabel/Hub/Port-Details.
• Capture rund ums Anstecken, nicht nur nach dem Fehler.

Das gibt Firmware- und Treiber-Teams actionable Evidence.

Enddiagnose

"USB Device Descriptor Request Failed" heißt, dass der Host sehr früh in der Enumeration gescheitert ist. Die Root-Cause kann Firmware, Deskriptor-Struktur, Timing, Endpoint-Null-Verhalten, Power, Kabel, Hub oder Host-Kompatibilität sein. Es ist meist zu früh, um die App zu beschuldigen.

Bus Scope unterstützt den richtigen Workflow: Inspizieren Sie die ersten Control-Transfers, bewahren Sie die Enumeration-Sequenz und diagnostizieren Sie den Fehler aus dem USB-Bus statt aus einem generischen Windows-Label.