2026-06-02

USBデバイスが繰り返し切断される：リセットループ、電源イベント、列挙失敗のデバッグ

USBデバイスが繰り返し切断・リセット・再列挙・サスペンド後の失敗を起こす事象を、パケットレベルのUSB証拠に基づいて診断する方法を解説します。

USBデバイスが繰り返し切断される事象は、ハードウェア問題の中でも最も厄介な部類です。症状がうるさく、かつ一貫しない。デバイスは現れたり消えたり、再接続したり、COMポートが変わったり、列挙に失敗したり、数秒だけ動いてリセットされたりします。OSのメッセージが実際に何を起こしたかを説明してくれることはまずないので、USB device keeps disconnecting、USB reset loop、USB device not recognized after reconnect、why does my USB device re-enumerate で検索することになります。

意味のある証拠はアプリ層よりも下にあります。知りたいのは「ホストがポートをリセットしたのか」「デバイスが応答を止めたのか」「ディスクリプタ読み取りが失敗したのか」「電源管理がデバイスをサスペンドしたのか」「ドライバがクラスリクエストを発行したのか」「エンドポイントがストールしたのか」です。

Bus ScopeはそうしたスタイルのUSBトラブルシューティングのために作られています。USBをブラックボックス扱いせず、コントロール転送・ディスクリプタ読み取り・リセット・エンドポイント挙動・切断のタイミングを確認できるようにします。

「切断」が意味しうるもの

「USB disconnecting」という言葉は、実際にはいくつもの異なる失敗を指します。

物理的な抜去やケーブルの揺れ
電気ノイズや電源の不安定
ホストコントローラによるポートリセット
デバイスファームウェアのクラッシュと再起動
リセット後の列挙失敗
ドライバのアンロードと再ロード
Selective Suspendやランタイム電源管理
エンドポイントSTALL後の復旧失敗
複合デバイスのインターフェース失敗
高帯域転送のオーバーロード

デスクトップ通知で見ればどれも同じに見えますが、USBの証拠上ではまったく違う姿を見せます。

列挙リセットループ

リセットループは多くの場合、ホストがデバイスを検出し、ポートをリセットし、ディスクリプタを読み、アドレスを割り当て、SET_CONFIGURATION 前に失敗する——というサイクルが繰り返される形で始まります。

簡略化したシーケンス：

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

SET_CONFIGURATION 前に失敗するなら、ディスクリプタ内容・ファームウェアタイミング・電源・ホスト互換性の問題かもしれません。SET_CONFIGURATION 後に失敗するなら、クラス初期化・エンドポイントセットアップ・ドライバリクエストの問題かもしれません。

電源問題がプロトコル問題に見えることがある

USBデバイスは、電圧低下・電流スパイク・ハブの給電不足でリセットすることがあります。よくあるケース：

USBカメラ
USBキャプチャカード
外付けドライブ
開発ボード
セルラーモデム
パッシブハブ経由のデバイス
品質の低い／長いケーブル

パケットレベルでは、電源起因のリセットは「突然の無音 → 再列挙」のように見えます。デバイスがリクエストへの応答を止め、ホストがポートをリセットし、列挙がやり直しになる。

Bus Scopeは電圧を直接測定できませんが、リセット前後のタイミングとシーケンスは示せます。直近の成功操作が帯域を食うストリーム開始や、モーター／電源モード切替コマンドだったなら、電源またはファームウェアストレスが疑わしい。

Selective Suspendとランタイム電源管理

OSはアイドル状態のUSBデバイスをサスペンドして電力を節約します。これはデバイスとドライバが正しく対応している限り正常動作。問題になるのは、デバイスファームウェアがクリーンにレジュームしない場合や、アプリが「アクティブのまま」と想定しているデバイスをドライバがサスペンドしてしまう場合です。

症状：

接続直後は動くがアイドル後に失敗
アイドル後の最初のリクエストがエラー
スリープやスクリーンロック後にデバイス消滅
レジューム後にシリアルデバイスの状態が変わる
ウェイク後にHIDデバイスが入力を見落とす

USBトレースを見れば、障害前にトラフィックが止まったか、レジューム／リセットシーケンスが走ったかが分かります。アプリのエラーメッセージから推測するよりずっと有用です。

切断の直前にエンドポイントSTALL

「切断」として報告される事例の中には、実態はエンドポイントレベルの失敗もあります。デバイスがバルク・インタラプト・コントロールリクエストをストールさせる。ドライバはSTALLのクリアを試みます。復旧に失敗するとドライバはデバイスをリセットし、アプリはハンドルを閉じます。

確認ポイント：

コントロール転送の STALL
繰り返されるバルク転送失敗
CLEAR_FEATURE(ENDPOINT_HALT)
毎回同じリクエストのあとのリセット
切断前のタイムアウト

同じコマンドが常にリセットを誘発するなら、そのコマンド処理中にファームウェアがクラッシュしている可能性があります。

複合デバイスのリセットループ

複合USBデバイスは、1台のデバイスに複数のインターフェースを公開します。例：

CDCシリアルインターフェース
HIDコントロールインターフェース
マスストレージインターフェース
ベンダー固有診断インターフェース

デバイスは部分的に列挙されても、特定のインターフェースドライバがアタッチする瞬間に失敗することがあります。「USBデバイス認識」直後に即切断するのは、あるインターフェースがファームウェアクラッシュやドライバ競合を引き起こしているサインかもしれません。

トレース上では、インターフェースディスクリプタ・Alternate Setting・エンドポイントディスクリプタ・クラス固有リクエストを確認しましょう。リセットは、特定のインターフェースをホストがコンフィギュレーションし始めた瞬間にしか起きないかもしれません。

高帯域デバイスの切断

USBビデオ、オーディオ、キャプチャ、データ収集系のデバイスは、負荷がかかると切断することがあります。デバイスは正常に列挙し、簡単なコントロールリクエストも通るのに、ストリーミング開始で落ちる。

よくある原因：

アイソクロナス帯域予約の失敗
バルクエンドポイントのタイムアウト
ホストコントローラの帯域圧迫
ハブのボトルネック
USB 2.0／USB 3.xモード不一致
ファームウェアのバッファオーバーフロー
ドライバが未対応のAlternate Settingを選択

切断がストリーム開始リクエストやAlternate Setting変更の後に起きるなら、リセット直前の正確な転送を観察してください。たいてい最も重要な手がかりはそこにあります。

取得すべきキャプチャ

再現性のある切断事象に対しては、接続前または失敗アクション前からキャプチャを開始してください。フルストーリーを残すには：

デバイス接続
ポートリセット
ディスクリプタ読み取り
アドレス割り当て
コンフィギュレーション選択
インターフェースドライバリクエスト
最初の通常のアプリ転送
失敗前の最後の成功転送
タイムアウト／STALL／リセット／切断
失敗後の再列挙

すでに失敗した後のキャプチャでは、最も重要な証拠を取り逃します。

デバッグチェックリスト

次の順で確認します。

短くて健全なケーブルで再現する
最初のテストではパッシブハブを避ける
接続時から列挙をキャプチャする
失敗が SET_CONFIGURATION の前か後かを確認する
最後に成功したリクエストを特定する
STALL／タイムアウト／繰り返されるリセットを探す
アイドル失敗と負荷時失敗を比較する
別のUSBポート／ホストコントローラを試す
証拠を集めてからSelective Suspendを無効化する
可能なら別OSで同じデバイスを比較する

最終的な診断

「USB device keeps disconnecting」は症状であって根本原因ではありません。電源不安定／ファームウェアリセット／ディスクリプタ失敗／ドライバのクラスリクエスト失敗／エンドポイントSTALL／サスペンド・レジューム問題／高帯域オーバーロードのどれかは、証拠を見てからでないと決まりません。

Bus Scopeは、障害発生時のUSBトランザクションをそのまま可視化するので、デスクトップ通知からの推測をやめ、実際のバス挙動に基づいてデバッグを進められます。