そういえば、似たようなトラブルで「Vista64でバルク転送でエラー発生」(http://www.wdddc.net/node/28)というのがありましたね。

このときはWinUSB経由でしたが、バルク転送中にUSBメモリーやUSBハブを抜き差しすると、通信エラー(::GetLastError=31)が発生するというものでした。

残念ながら元ネタ投稿者の vritra13_krishna13さんが調査を続けられなくなったので、解決しないまま中断となってますね。

でも、WinUSBでこんな現象がでるのなら、オリジナルのドライバでもでそうな気がします。

バッキー@誤るのは人の常、バグをつぶすのは神の業

> でも、だとしたら問題は Hub ではなくて、せれさんのドライバ（あるいはデバイス）自身の可能性
> も考えられますね。

HUBを介した場合、介さない場合を意識しないでドライバの実装を行っていたのですが、
もしかしてそういう実装が実は必要だったのでしょうか。

> もし私だったら、以下のことを行い、問題の切り分けを行います。

Pooh 様のおっしゃるように、問題がターゲットとホストのどちらにあるか切り分けていきたいと
思いますが、今のところ、下記ページに記載されている問題が原因のように感じています。
この場合、実装側でなんとかすることはできるんでしょうか・・・。

http://support.microsoft.com/kb/945360/

> そういえば、似たようなトラブルで「Vista64でバルク転送でエラー発生」
> (http://www.wdddc.net/node/28)というのがありましたね。

こちらの内容と現象は同じように感じています。

> http://support.microsoft.com/kb/945360/
今までお伺いした現象から見ると、これに該当する可能性はかなり高いですね。
この KB に書かれている回避方法で現象が解消されなら、Device Manager からターゲット デバイスの
無効/有効を行えば、もしかしたら同じように通信が復帰（もちろんそれまでのセッションは切れますが）
できるかもしれませんね。

>HUBを介した場合、介さない場合を意識しないでドライバの実装を行っていたのですが、
>もしかしてそういう実装が実は必要だったのでしょうか。

USB Function Driver の実装において、そのドライバが USB Hub や USB Host Controller を
意識する必要はありません。
というか、「基本的に」そのような H/W 構成に依存するようなコードは書くべきではありません。

（なぜ「基本的に」かというと、usbhub.sys や usbport.sys など Windows OS が提供している
USB スタックのドライバは、XP / Vista / 7 などのプラットフォームの違いとその H/W 構成に
起因して、微妙に振る舞いが変わるケースがあります。
その違いがバグであるか否かに関しては MS が判断することなのでここでは割愛しますが、
このような OS 標準ドライバ側に起因する動作の違いを Function Driver や Filter Driver
で吸収できるケースも多々あります。
なので、問題現象の深刻度に応じてこのような対応もする場合がありますが、本来の USB の規格と
WDM アーキテクチャを考えるなら、そのような回避手段はとるべきではありません。）

ですので、基本的にせれさんの考えていらっしゃることは正しいと思います。
ただ USB ドライバの場合、Function Driver が URB 構造体にセットする一部のメンバ値に不備があると、
Hub 介在の有無などの H/W 構成、あるいは OHCI/UHCI/EHCI などの使用する Controller の種類など、
さまざまな要因によって現象が変化する問題を何度も経験しました。（私だけかもしれませんが。。。。ｗｗｗ）
この手の問題は、一部の H/W 構成ではちゃんと動作するので、初めは
「デバイスや自分のドライバ以外の他のコンポーネントが悪いのでは？」
と思いがちですが、実際に丹念にデバッグしていくと、
「実は自分のドライバの実装が悪かった！」
という、恥ずかしいオチになります。

今回の現象も、事実としてわかっているのは「Hub の介在」だけであり、その本当の問題がどこにあるかは、
未だ不明であると思います。
そのような状況においては、すべての可能性を疑う必要がある、と私は考えています。
そして、すべての可能性を疑う場合に一番必要なことは、
「疑うべきは、まず自分！！」
だと思っています。

ですので、せれさんのドライバやデバイスの実装を疑ったことに別に他意はなかったのですが、
もしお気に障ったのでしたら、言葉が足らず申し訳ありませんでした。

ちなみに、KB945360 の問題を自作ドライバ側で回避できるかは不明（たぶん無理っぽい）ですが、
MS のサポート部門に問い合わせれば、もしかしたら何か教えてくれるかもしれません。
（実は、すでに Hotfix が用意されていた！！。。。なんてことも、あるかもしれません。）

> 今までお伺いした現象から見ると、これに該当する可能性はかなり高いですね。
> この KB に書かれている回避方法で現象が解消されなら、Device Manager からターゲット デバイスの
> 無効/有効を行えば、もしかしたら同じように通信が復帰（もちろんそれまでのセッションは切れますが）
> できるかもしれませんね。

パイプリセット後にデバイスを再開させることで通信は再開できる所まで確認しています。
後は通信エラーが起こる状況を回避できれば万々歳なのですが・・・

> ただ USB ドライバの場合、Function Driver が URB 構造体にセットする一部のメンバ値に
> 不備があると、Hub 介在の有無などの H/W 構成、あるいは OHCI/UHCI/EHCI などの使用する
> Controller の種類など、さまざまな要因によって現象が変化する問題を何度も経験しました。

ありがとうございます。参考にさせていただきます。

> ですので、せれさんのドライバやデバイスの実装を疑ったことに別に他意はなかったのですが、
> もしお気に障ったのでしたら、言葉が足らず申し訳ありませんでした。

いえ、私も「疑うべきは、まず自分！！」だと思っています。

皆様からの意見を元にして、とりあえず原因を、①KB945360 の問題、②ドライバやデバイスの実装
のどちらかと仮定して以下のように調査を進めたいと思います。

①については、
1)KB945360 の問題についてMSのサポート部門に問い合わせる
2)H/Wの組み合わせを変更して、再現性を調査する

② については、
USB メモリを抜く直前から Bulk-In を発行するまでの間にドライバに渡されてくるすべての IRP
とその結果 (NTSTATUS コードや、URB_HEADER 構造体 Status メンバにセットされる USBD_STATUS
コード etc.)をログとして吐き出させ、汎用 Hub デバイスを使用した場合と使用しない場合で、
どこに差異があるかを確認する。

直近で調査の時間がしばらくとれなくなったので、進展があり次第また相談させていただきたいと思います。
ありがとうございました。