外れているかも知れませんが、過去の経験では、

１．HUBが怪しい
他のHUBではどうですか？（まさかセルフパワーHUBでは無いでしょうね。セルフパワーHUBはテストに使うべきではありません。）
以前USB2.0が出たばかりの頃、HUBが原因でUSBのHCTが通らずに苦労した記憶があります。
4つ持っていたBus Powerd HUBのうち、HCTをパスするのは1番安かったヤツ1個だけでした。

２．SHボードが怪しい
組み込みボード側のUSBコントローラやファームウェアって時々怪しい場合があります。
ERRATAは出ていませんか？（決してSHだから怪しいという訳ではありません）

３．USBメモリが怪しい
> 通信中に別ポートにUSBメモリを挿した後、取り外すと通信エラー
というので、他のUSBメモリでも同じなのかが気になります。

４．PCが怪しい
怪しい処ばかりですが…
USBは今でも多少なりとも相性問題があるように思います。
特にホスト・コントローラは各社が作っているので、必ず同じように動くとは限りません。
他のPCでも同じ現象でしょうか？

もしかしたら、USB 2.0 Single Transaction Translator (Single TT) の Hub を使用されているのでは？
勝手な推測ですけど、別ポートに接続する USB メモリが USB 1.1 で、かつ使用している USB Hub が Single TT の場合、
ファンクション ドライバ側の実装に依存して、他のデバイスの挿抜が影響する可能性があると思います。

USB 2.0 対応の Hub デバイスでは、USB 1.1 デバイスとの互換性を維持するために Split Transaction をサポートしているはずですが、
この機能の実現方式にはには Single TT と Multi TT の2種類があります。
Multi TT の Hub の場合は問題ないのですが、Single TT の場合、その Hub デバイスが提供しているポートのうち、
バッファリングできるのは常に１つのポートだけになるので、ファンクション ドライバ側の実装に依存して、他のデバイスが影響を受ける
可能性があると思います。

USB 2.0 の Hub が Single TT / Multi TT のいずれかなのかは、製品説明書にも書いていない場合があるので、
直接メーカに聞いた方が早いかもしれません。

１つの判断目安としては、デバイス マネージャで Hub デバイスを接続している USB EHCI ホストコントローラを無効にして、
強制的に UHCI ホストコントローラとして動作させた場合に、現象が変わるかどうかです。
もし、Hub デバイスを介在させても UHCI ホストコントローラでなら動作するようであれば、Transaction Translator に
起因する問題を疑った方がいいかもしれません。

それ以外の切り分け方法としては、XP でも再現するのであれば、以下の KB で公開されている方法が有効だと思います。
（私が試した限りでは、残念ながら Vista ではこの方法うまくいきませんでした。）
ちょっと面倒かもしれませんが、usbhub.sys や usbport.sys が吐き出すデバッグ ログを丹念にトレースすると、結構原因が見えてきたりします。

さまざまなドライバやサブシステムで詳細なデバッグ トレースを有効にする方法
http://support.microsoft.com/kb/314743/ja

HUBのTTの見分け方について

かつて、とあるデバイスとHUBの相性が問題になったことがありました。
そのときは僕もTTを疑ったんですが、そこまで追求する余裕も無くその問題は見なかったことにしたのですが(苦笑)
Phooさんのご指摘で記憶の底から蘇ってしまいました。

でと、それならば Single TTと Multiple TTsを見分ける方法はないかなぁ と探してみるとUSBの仕様書で
「USB HUB Class descriptorに書かれているよ」という記述を見つけました。

ネットでも情報が公開されているので、ちょっとコードを書けばどちらか判定できそうです。
http://www.usb.org/developers/defined_class/#BaseClass09h

確認が一過性のものならば手っ取り早く(有償の)ツールの試用期間を使うのもいいかもしれません。
http://www.usblyzer.com/usb-hub-class-decoder.htm

バッキー@今日は寝不足です、とほほ。。。

済みません。
今、見直してみたらば、2個目に私が記述した「バスパワー」と「セルフパワー」が全く逆になっているのに気付きました。
セルフパワーHUBとは、HUBに外部から電源を供給して使うものです。
バスパワーHUBは、USBバスの電源だけで動作させて使うものです。正しくは、次の通りです。

１．HUBが怪しい
他のHUBではどうですか？（バスパワーHUBでは無いでしょうね。バスパワーHUBはテストに使うべきではありません。）
以前USB2.0が出たばかりの頃、HUBが原因でUSBのHCTが通らずに苦労した記憶があります。
4つ持っていたセルフ・パワーHUBのうち、HCTをパスするのは1番安かったヤツ1個だけでした。

> 差し支えなければ、HUBの何が原因だったのか教えて頂けますか？
原因はわからないままでした。通常の使い方では4台とも使用できていました。
ダメなHUBは、確かHCTのUSB Enumeration Testテストで、ターゲットデバイスをHUBに接続したまま、USB機器のON-OFFを
繰り返すといったような操作で50回～100回に1回ぐらいの割合でエラーになる場合があるという様な状況でした。

HUBのTTの件は、取りあえずは確実にUSB2.0（Hi Speed）対応のUSBメモリを使用して試してみてはいかがでしょう。

backy さんの仰るとおり、TT の確認は Device Descriptor を見ればすぐにわかりますね！！
言われてみれば当たり前の話ですが、今の今までそこまで頭がまわりませんでした。。。
（これで、またひとつ賢くなれたかも！！）

ちなみに、WDK の USBView でも TT の種類を確認できるみたいです。

そうそう、Poohさんのおっしゃるとおり WDKの USBViewでTTを確認できました。

USB に関する FAQ: 中級レベル(http://www.microsoft.com/japan/whdc/connect/usb/usbfaq_intermed.mspx)によると

USBデバイス ディスクリプタの bDeviceProtocol フィールドおよび USB インターフェイス ディスクリプタの
bInterfaceProtocol フィールドの値は、ハブが単一 TT とマルチ TT のどちらであるかを示します。

Single-TT. bDeviceProtocol == 0x01
Multi-TT. bDeviceProtocol == 0x02

ということですので、USBViewで該当HUBのデバイス ディスクリプタをみれば一目瞭然でした。

P.S.
先の書き込みで Poohさんの名前を撃ち間違えておりました。
寝不足でバッキーの意識が遠のいた折に指先の小人さんがおちゃめなことをしてしまったようです。
申し訳ありませんでした。(_O_)

バッキー@以前は90時間ぐらいなら闘えたのに。。。

わぉ！ ダメダメじゃん！

タイポですね。

誤：撃ち間違い
正：打ち間違い

バッキー＠撃ってどうするんだ、撃って。。。

再びこんにちは。

>先の書き込みで Poohさんの名前を撃ち間違えておりました。
>寝不足でバッキーの意識が遠のいた折に指先の小人さんがおちゃめなことをしてしまったようです。
>申し訳ありませんでした。(_O_)

いえいえ、どうかお気になさらず。
（そーいえば、以前「Phoo!!」と叫んでいる、危ない恰好をした芸人がいたなぁーーーと、一人で笑ってました！！）
別のフォーラム（別のハンドル名ですが）でも、やっぱり間違えられちゃってますし。ｗｗｗ
こちらの方こそ的確なご教授、ありがとうございました！！

でも、今回のせれさんの問題、Hub の介在の有無で現象が変わるということは、usbhub の
DevNode が１つ増えるか増えないか。。。ということだと思ったので、一番 Hub（か usbhub.sys）が怪しいと思ったのですが、
もしかして、
「別（の USB ホストコントローラ上の）ポートにUSBメモリを挿した後」
ってことなのかな？
だとしたら、Hub は関係ないかもしれませんね。。。

編集したら、ツリーの位置変わっちゃうんですね(汗

皆様早速のご返信ありがとうございます
現時点でわかっていることについて答えさせていただきます。

> １．HUBが怪しい
> 他のHUBではどうですか？（バスパワーHUBでは無いでしょうね。
> バスパワーHUBはテストに使うべきではありません。）

複数のHUBで起きています。バスパワーについては意識しておりませんでしたが、
製品仕様を確認してみるとセルフ/バスパワー両対応となっていました。

> > 以前USB2.0が出たばかりの頃、HUBが原因でUSBのHCTが通らずに苦労した記憶があります。
> > 4つ持っていたBus Powerd HUBのうち、HCTをパスするのは1番安かったヤツ1個だけでした。
> 差し支えなければ、HUBの何が原因だったのか教えて頂けますか？
> 原因はわからないままでした。通常の使い方では4台とも使用できていました。
> ダメなHUBは、確かHCTのUSB Enumeration Testテストで、ターゲットデバイスをHUBに接続したまま、
> USB機器のON-OFFを繰り返すといったような操作で50回～100回に1回ぐらいの割合でエラーになる場合
> があるという様な状況でした。

なるほど、そういう問題が発生することもあるのですね。

> HUBのTTの件は、取りあえずは確実にUSB2.0（Hi Speed）対応のUSBメモリを使用して試してみては
> いかがでしょう。
> でも、今回のせれさんの問題、Hub の介在の有無で現象が変わるということは、usbhub の
> DevNode が１つ増えるか増えないか。。。ということだと思ったので、一番 Hub（か usbhub.sys）
> が怪しいと思ったのですが、もしかして、「別（の USB ホストコントローラ上の）ポートにUSBメモリ
> を挿した後」ってことなのかな？だとしたら、Hub は関係ないかもしれませんね。。。

Pooh様のおっしゃる通り、別（の USB ホストコントローラ上の）ポートにUSBメモリを挿して(下図1)、
抜いた「後」に通信エラーが発生します。ですのでTTの話は関係がないかと思っておりました。
但し、2の状態では問題が発生しません。

1. PC-HUB-SHボード
　　└USBメモリ

2. PC-SHボード
　　└USBメモリ

> ２．SHボードが怪しい
> 組み込みボード側のUSBコントローラやファームウェアって時々怪しい場合があります。
> ERRATAは出ていませんか？（決してSHだから怪しいという訳ではありません）

プロファイラで見る限り、USB通信が中断された時にHUB-SHボード上は正常に通信が行われている
(ように見える)が、PC-HUB間ではバルクイン通信時にエラーが出ています

> ３．USBメモリが怪しい
> 通信中に別ポートにUSBメモリを挿した後、取り外すと通信エラー
> というので、他のUSBメモリでも同じなのかが気になります。

こちらは未確認です。

> ４．PCが怪しい
> 怪しい処ばかりですが…
> USBは今でも多少なりとも相性問題があるように思います。
> 特にホスト・コントローラは各社が作っているので、必ず同じように動くとは限りません。
> 他のPCでも同じ現象でしょうか？

３、に続いて未確認です。

現象の内容を読み返してみたら、複数の Hub デバイスで発生しているんですね。
適当なことを書いてしまって、申し訳ありません。

でも、だとしたら問題は Hub ではなくて、せれさんのドライバ（あるいはデバイス）自身の可能性も考えられますね。
もし私だったら、以下のことを行い、問題の切り分けを行います。
（既に実施されているかもしれませんが、一応。。。）

1. せれさんがターゲットとしているデバイスを、他の類似するデバイスに置き換えて、同様の現象が発生するか確認する。

もし、Hub や Host Controller の問題であるならば、他のデバイスでも発生するはずだと思います。
もし他のデバイスでも発生するのであれば、使用している PC (Hub or Host Controller) あるいは Hub など、
関連しそうな H/W を変更して、どこに問題がありそうなのかを探ります。

2. NT カーネルから渡されてくるすべての IRP とその結果を確認する。

逆に、（上記 １ の）他のデバイスで発生しないのであれば、自分のドライバあるいはデバイスの実装を疑います。

今回の現象は、USB メモリを抜いた直後の Bulk-In で起きているんですよね？
だとしたら、問題は USB メモリを抜いた直後から Bulk-In を発行するまでの間に、既に発生している可能性もあると思います。
なので、WinDbg などのデバッガを接続して、USB メモリを抜く直前から Bulk-In を発行するまでの間にドライバに渡されてくる
すべての IRP とその結果 (NTSTATUS コードや、URB_HEADER 構造体 Status メンバにセットされる USBD_STATUS コード etc.)
をログとして吐き出させ、汎用 Hub デバイスを使用した場合と使用しない場合で、どこに差異があるかを確認します。
（このとき出力するログに漏れがあると、結果的に見落しにつがることがあるので、かなり手間ですが例外なくすべての
IRP をチェックするように、私はしています。）

もし仮に、デバッグ ログを出力させることにより現象が変わるようであれば、タイミング的な問題を考慮する必要も
出てきますので、その場合は、今せれさんが実施されているようなアナライザでの確認を再度行います。

あくまでも私だったら、このような泥臭いデバッグを行うというだけで、これが正しいアプローチなのかはわかりませんが、
私の場合、この方法で大抵バグの箇所は特定できています。