libusbのアクセス拒否とWinUSBドライバのデバッグ：権限・Zadig・カーネルドライバ・インターフェースクレーム

USB開発ツールを使っていると、LIBUSB_ERROR_ACCESS、access denied、cannot claim interface、WinUSB driver not found、Zadig driver install failed、resource already exists といったエラーに遭遇することがよくあります。OS上にはデバイスが見えているのに、診断ツールやファームウェアツールから開けず、「libusb access denied」「WinUSB driver not binding」「Zadig failed」「libusb cannot claim interface」「USB permission denied」で検索する羽目になります。

Bus Scopeが威力を発揮するのは、こうした「アクセスできない」問題が、USBディスクリプタ・OSのドライババインド・アプリレベルのインターフェースクレームのちょうど境界線上で起きているからです。デバイスは物理的に繋がっており、正しく列挙されているにもかかわらず、libusbからはアクセスできない——そんなケースにきちんと切り込みます。

デバイスが見えている ≠ インターフェースにアクセスできる

USBデバイスは一見正しく列挙されているように見えます。

• デバイスディスクリプタが読めた
• コンフィギュレーションが選択された
• インターフェースが表示されている
• エンドポイントが記述されている
• OSがデバイスを認識している

それでもlibusbが対象インターフェースをオープン／クレームできないことがあります。原因は、別ドライバがそのインターフェースを掴んでいる、権限が足りない、WinUSBがバインドされていない、対象インターフェースを間違えている、のいずれかです。

WindowsとWinUSB

Windowsでlibusb系アクセスを行うには、WinUSBのように互換性のあるドライバが対象インターフェースにバインドされている必要があります。ベンダー固有インターフェースに対しては、Zadigのようなツールでドライバを置き換えたりインストールしたりするのが一般的です。

よくある落とし穴：

• Zadigで選んだインターフェースを間違えている
• 複合デバイスでインターフェースが複数ある
• HIDドライバがそのインターフェースを所有している
• 既存ドライバパッケージと競合する
• ポリシーによりドライバインストールがブロックされる
• ブートローダーモードでVID/PIDが別物になっている
• Microsoft OSディスクリプタが誤ったインターフェースを指している

特に複合デバイスで、誤ったインターフェースに対してドライバを置き換えると、目的のツールを直さないまま別の機能を壊すことがあります。

Linuxの権限問題

Linuxで LIBUSB_ERROR_ACCESS が出る多くの場合、ユーザーはデバイスノードをオープンする権限を持っていません。デバイスは存在しているのに、udevルールやグループ membership がアクセスを許していない、というケースです。

USBトラフィックが流れていることはキャプチャで確認できますが、権限エラーはOSレベルの証拠で切り分ける必要があります。区別すべきポイントは以下のとおりです。

• デバイスが列挙されていない
• 列挙はされているが権限がない
• カーネルドライバがすでにバインド済み
• アプリが間違ったVID/PIDまたはインターフェースをターゲットにしている

カーネルドライバがすでにインターフェースを掴んでいる

カーネルドライバがインターフェースを所有している場合、libusb側で detach するか、アプリは kernel driver API を使う必要があります。HID・CDC・ストレージ・オーディオインターフェースは、標準で inbox ドライバが押さえることが多いです。

正しい対処は製品の意図次第です。キーボードやストレージデバイスなら、カーネルドライバを detach すると通常のシステム挙動を壊します。一方、ベンダー固有の診断インターフェースであれば、WinUSB/libusb のバインドが正解でしょう。

デバッグチェックリスト

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

1. 列挙とディスクリプタをキャプチャする
2. 対象インターフェース番号を特定する
3. デバイスが複合デバイスかを確認する
4. Windowsでは、そのインターフェースにドライバがバインドされているかを確認する
5. Linuxでは、権限とudevルールを確認する
6. カーネルドライバがすでにインターフェースを所有していないか確認する
7. 通常モードとブートローダーモードでVID/PIDを確認する
8. アプリが正しいインターフェースをターゲットにしているか確認する
9. 無関係なインターフェースに対してドライバを置き換えない
10. ドライババインドを変更する前に、ディスクリプタの証拠を保全する

最終的な診断

libusb access denied や WinUSBバインドの失敗は、ほぼ確実にUSBの電気信号レベルの問題ではありません。インターフェースの所有権・権限・ドライババインド・ディスクリプタとインターフェースのマッピングの問題です。

Bus Scopeは「どのインターフェースが存在し、デバイスがどう列挙されているか」を可視化するので、闇雲にドライバを再インストールするのではなく、正しい層に切り分けて原因を辿ることができます。