USB-String-Deskriptor- und LANGID-Debugging: Serial-Number, Manufacturer, Product-Name und Treiberbindung

USB-String-Deskriptoren wirken harmlos, aber schlechte Strings können Treiberbindung, Device-Identität, Serial-Port-Persistenz, Lab-Automation, Firmware-Update-Tools und Support-Workflows zerbrechen. Nutzer suchen nach "USB string descriptor failed", "LANGID descriptor", "USB serial number descriptor missing", "duplicate USB serial number", "USB product string wrong" und "Windows shows unknown USB device name", wenn das Device enumeriert, aber die Identität instabil ist.

Bus Scope hilft, weil String-Deskriptor-Fehler während der Enumeration als Control-Transfers passieren. Der Host fragt nach unterstützten Language-IDs und dann nach Manufacturer-, Product- und Serial-Number-Strings. Gibt irgendeine Step fehlerhafte Daten zurück, kann das OS trotzdem weitermachen, aber schlechte Identität speichern.

LANGID-Deskriptor

Bevor spezifische Strings angefragt werden, kann der Host String-Deskriptor Null anfragen. Der gibt unterstützte Language-IDs zurück.

Typische Evidence:

GET_DESCRIPTOR String index 0
LANGID list returned
GET_DESCRIPTOR String index 1
GET_DESCRIPTOR String index 2
GET_DESCRIPTOR String index 3

Scheitert String-Deskriptor Null, können spätere String-Requests sich über Hosts hinweg inkonsistent verhalten.

Manufacturer-, Product- und Serial-Strings

Häufige String-Indizes:

• iManufacturer
• iProduct
• iSerialNumber

Diese Felder werden vom Device-Deskriptor referenziert. Wirbt das Device mit einem Non-Zero-String-Index, scheitert aber, den String zurückzugeben, kann das Host-Verhalten variieren.

Symptome:

• Device erscheint als "Unknown Device".
• Product-Name ist verstümmelt.
• Serial-Number ist leer.
• Windows erstellt nach jedem Anstecken einen neuen COM-Port.
• Linux-udev-Regeln matchen nicht zuverlässig.
• Firmware-Update-Tool kann das Target nicht identifizieren.
• Mehrere Units kollabieren in eine Identität.

Doppelte Serial-Numbers

Doppelte USB-Serial-Numbers sind ein ernstes Produktions-Problem. Zwei physische Devices mit derselben VID, PID und Serial-Number können als dieselbe Device-Instanz behandelt werden.

Konsequenzen:

• Falsche Kalibrier-Daten geladen.
• Test-Station schreibt Logs auf falsches Gerät.
• COM-Port-Zuweisung ändert sich unvorhersehbar.
• Licensing oder Provisioning bindet an falsche Hardware.
• Field-Support kann Devices nicht unterscheiden.

Packet-Capture kann belegen, ob die Serial-Deskriptor-Bytes tatsächlich dupliziert sind oder ob die OS-Anzeige ein tieferes Issue versteckt.

Fehlende Serial-Number

Manche Devices lassen absichtlich eine Serial-Number weg. Das kann für einfache Peripheriegeräte akzeptabel sein, verursacht aber Probleme, wenn stabile Identität zählt.

Häufige Suchbegriffe:

• "USB device new COM port every time"
• "USB serial number missing"
• "Windows USB device instance path changes"
• "Linux udev match USB serial"

Fehlt die Serial-Number, identifiziert das OS das Device möglicherweise über Port-Topology statt über Hardware-Identität.

Fehlerhafte UTF-16LE-Strings

USB-Strings sind als Unicode-Strings kodiert. Firmware-Bugs umfassen:

• falsche Deskriptor-Länge.
• ungerade Byte-Anzahl.
• fehlender Deskriptor-Typ.
• ungültige UTF-16LE-Bytes.
• Null-Termination-Erwartungs-Mismatch.
• Rückgabe von ASCII-Bytes statt USB-String-Format.
• Truncation langer Serial-Numbers.

Manche Hosts tolerieren das. Andere verwerfen den Deskriptor oder zeigen korrupten Text.

String-Request-Timing und Retries

Hosts können denselben String mehrfach mit unterschiedlichen Längen anfragen. Ein Device sollte sowohl kurze Probe-Requests als auch Full-Length-Requests behandeln.

Fehler-Patterns:

• Device gibt korrekte ersten 2 Bytes zurück, scheitert aber beim Full-Request.
• Firmware nimmt an, dass wLength immer der Deskriptor-Länge entspricht.
• Control-Endpoint stalled bei wiederholtem String-Request.
• Device gibt nach Reset andere Serial-Number zurück.
• Bootloader und App-Firmware melden unterschiedliche Identität.

Das ist häufig in Firmware-Update-Workflows.

Treiberbindungs-Auswirkung

Die Treiber-Auswahl hängt meist von VID/PID/Klasse ab, aber String-Deskriptoren beeinflussen die User-sichtbare Identität und manchmal Vendor-Tools. Composite-Devices, CDC-Serial-Devices, HID-Tools und DFU-Bootloader verlassen sich oft auf Strings für Support und Automation.

Sagt ein Support-Ticket "falscher USB-Device-Name", verwerfen Sie das nicht als kosmetisch. Es kann Deskriptor-Korruption oder Firmware-State-Verwirrung anzeigen.

Debug-Checkliste

Nutzen Sie diesen Ablauf:

1. Enumeration ab Anstecken capturen.
2. Device-Deskriptor-String-Indizes inspizieren.
3. String-Deskriptor Null auf LANGID prüfen.
4. Manufacturer-String dekodieren.
5. Product-String dekodieren.
6. Serial-Number-String dekodieren.
7. Zwei physische Units vergleichen.
8. Bootloader und App-Firmware vergleichen.
9. Verhalten nach Reset und Replug prüfen.
10. Roh-Deskriptor-Bytes für Firmware-Fixes bewahren.

Enddiagnose

USB-String-Deskriptor- und LANGID-Probleme beeinflussen Device-Identität, Serial-Persistenz, Fertigungstests, Field-Support und Treiber-Workflows. Die Schlüssel-Evidence ist nicht das OS-Label, sondern die tatsächlichen Deskriptor-Control-Transfers.

Bus Scope zeigt LANGID, Manufacturer, Product, Serial-Number, fehlerhafte Strings, doppelte Serials und Enumeration-Retries in einer Diagnose-Sicht.