バススコープ logo バススコープ USB診断

2026-06-03

USB文字列ディスクリプタとLANGIDのデバッグ：シリアル番号、製造者、製品名、ドライババインド問題

USB文字列ディスクリプタ、LANGIDリクエスト失敗、シリアル番号ディスクリプタバグ、製造者／製品名、重複シリアル番号、ドライババインド問題をデバッグする方法を解説します。

USB文字列ディスクリプタ, LANGID, シリアル番号ディスクリプタ, 製造者文字列, 製品文字列, 重複シリアル番号, USB診断

USB文字列ディスクリプタは一見無害に見えますが、文字列の不具合がドライババインド・デバイス識別子・シリアルポートの永続性・ラボ自動化・ファームウェア更新ツール・サポートワークフローを壊すことがあります。デバイスは列挙しても識別子が不安定なとき、USB string descriptor failed、LANGID descriptor、USB serial number descriptor missing、duplicate USB serial number、USB product string wrong、Windows shows unknown USB device name で検索されます。

Bus Scopeが効くのは、文字列ディスクリプタの失敗が列挙中の「コントロール転送」として起きるからです。ホストは対応言語IDを問い合わせ、製造者／製品／シリアル番号文字列を要求します。どこかの手順が壊れたデータを返すと、OSは処理を続けても誤った識別子を保存します。

LANGIDディスクリプタ

特定の文字列を要求する前に、ホストは文字列ディスクリプタ0を要求することがあります。これは対応言語IDを返します。

典型的な証拠：

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

文字列ディスクリプタ0が失敗すると、以降の文字列リクエストはホストごとに挙動が割れることがあります。

製造者／製品／シリアル文字列

一般的な文字列インデックス：

  • iManufacturer
  • iProduct
  • iSerialNumber

これらはDevice Descriptorから参照されます。デバイスが非ゼロの文字列インデックスを提示しているのに、その文字列を返せない場合、ホスト挙動はさまざまになります。

症状：

  • デバイスが「Unknown Device」として現れる
  • 製品名が文字化け
  • シリアル番号が空
  • 接続のたびにWindowsが新しいCOMポートを作る
  • Linuxのudevルールが安定してマッチしない
  • ファームウェア更新ツールがターゲットを識別できない
  • 複数ユニットが1つの識別子に合流する

シリアル番号の重複

USBシリアル番号の重複は重大な製造上の問題です。VID／PID／シリアル番号が同じ物理デバイス2台が、同一のデバイスインスタンス扱いされることがあります。

結果：

  • 誤ったキャリブレーションデータが読み込まれる
  • テストステーションが誤ユニットにログを書く
  • COMポート割り当てが不安定になる
  • ライセンスやプロビジョニングが誤ハードウェアに紐づく
  • 現地サポートがデバイスを見分けられない

パケットキャプチャは、シリアルディスクリプタバイトが実際に重複しているのか、OS表示層がより深い問題を隠しているのかを証明できます。

シリアル番号の欠落

一部デバイスは意図的にシリアル番号を省略します。簡単な周辺機器では許容されますが、安定した識別子が必要な場面では問題になります。

よく検索される語：

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

シリアル番号がない場合、OSはハードウェア識別子の代わりにポートトポロジでデバイスを識別します。

UTF-16LE文字列の形式不正

USB文字列はUnicodeエンコードです。ファームウェアの不具合例：

  • ディスクリプタ長が誤り
  • 奇数バイト
  • ディスクリプタ種別が抜けている
  • 不正なUTF-16LEバイト
  • null終端期待の不一致
  • ASCIIバイトをそのまま返してしまう
  • 長いシリアル番号を切り詰める

ホストによっては許容しますし、ディスクリプタを拒否したり文字列を破損表示したりするホストもあります。

文字列リクエストのタイミングとリトライ

ホストは同じ文字列を別々の長さで複数回要求することがあります。デバイスは短いプローブ要求とフル長要求の両方を処理できるべきです。

失敗パターン：

  • デバイスは最初の2バイトを正しく返すがフル要求で失敗
  • ファームウェアが wLength を常にディスクリプタ長と決め打ち
  • 繰り返される文字列リクエストでコントロールエンドポイントがストール
  • リセット後にデバイスが別のシリアル番号を返す
  • ブートローダーとアプリファームウェアが異なる識別子を報告

ファームウェア更新ワークフローで頻発します。

ドライババインドへの影響

ドライバ選択は通常VID/PID/クラスに依存しますが、文字列ディスクリプタはユーザー可視の識別子と一部ベンダーツールに影響します。複合デバイス、CDCシリアルデバイス、HIDツール、DFUブートローダは、サポートと自動化のために文字列に依存することが多いです。

サポートチケットに「USBデバイス名が誤っている」と書かれていても、見た目の問題として片付けないでください。ディスクリプタの破損やファームウェア状態の混乱を示していることがあります。

デバッグチェックリスト

次の流れで作業すると、原因に早くたどり着けます。

  1. 接続時から列挙をキャプチャする
  2. Device Descriptorの文字列インデックスを確認する
  3. 文字列ディスクリプタ0のLANGIDを確認する
  4. 製造者文字列をデコードする
  5. 製品文字列をデコードする
  6. シリアル番号文字列をデコードする
  7. 物理ユニット2台を比較する
  8. ブートローダーとアプリファームウェアを比較する
  9. リセット後と再接続後の挙動を確認する
  10. ファームウェア修正のため生ディスクリプタバイトを保全する

最終的な診断

USB文字列ディスクリプタとLANGIDの問題は、デバイス識別子／シリアル永続性／製造テスト／現地サポート／ドライバワークフローに影響します。鍵となる証拠はOSラベルではなく、実際のディスクリプタコントロール転送です。

Bus Scopeは、LANGID／製造者／製品／シリアル番号／不正文字列／重複シリアル／列挙リトライを1つの診断ビューにまとめます。

関連ワークフロー