仮想シリアル ポートとして認識される Windows で USB デバイスを使用しています。CreateFile および ReadFile 関数を使用してデバイスと通信できますが、アプリケーションが CloseHandle を呼び出さない場合があります (開発中のアプリケーションがクラッシュした場合)。その後、CreateFile へのすべての呼び出しが失敗し (ERROR_ACCESS_DENIED)、唯一の解決策はコンピューターに再度ログインすることです。プログラムで開いているハンドルを強制的に閉じる (または再度開く) 方法はありますか?
6 に答える
これは確かに正常ではありません。Windowsは、プロセスの終了後に開いたままになっているハンドルを自動的に閉じます。これはUSBデバイスドライバの欠陥であるに違いありませんが、これがどのように混乱するかはわかりません。ただし、シリアルポートをエミュレートするものは、ひどいことで有名です。さて、あなたができることは何もありませんが、メーカーからのドライバーの更新を期待しています。または別のメーカーのデバイス。
以前の両方の投稿に同意します。
- これは通常の状況ではありません。
- 通常、USBデバイスのプラグを抜くと役立ちます。
この問題は、仮想COMポートの実装を担当するFTDIドライバーの不具合に関連しています。一方、これらの「グリッチ」は、USBデバイスのさまざまな誤動作に関連しています。(もちろん、これはFTDIドライバーを正当化するものではありません)。
ところで、いくつかのFTDIドライバーには他にもいくつかの既知の問題があります。
- toを呼び出すと
CloseHandle
、呼び出し元のスレッドがハングすることがあります。 - また、アプリケーションを閉じた後でも、アプリケーションがタスクマネージャに「表示」されている場合もあります。タスクマネージャーはアプリケーションを終了できず、デバッガーをアプリケーションに接続できません。そのEXEファイルはロックされています(消去できません)。
通常、USBデバイスのプラグを抜くと、このような状況ですぐに役立ちます。「何かを待っている」ように見えるFTDIドライバーが目覚めます。
クラッシュしたプログラムの一部のスレッドまたは子プロセスがまだ実行されており、ファイルハンドルのコピーを保持している可能性はありますか?おそらくデバッガプロセスはまだ開いていますか?もしそうなら、それらはデバイスを開いたままにしている可能性があります。念のため、タスクマネージャーを確認します。その場合、残りのプロセスを強制終了すると問題が解決する可能性があります。
あなたが起こりたくないもう1つのことは、開いているUSBシリアルポートを持ち、ユーザーがUSBからシリアルへのアダプターを引っ張ることです。そのバグは長い間存在しています。ここにバグへの答えがありました
「2009 年 3 月 27 日午後 4 時 3 分に Microsoft が投稿 こんにちは。この問題を報告していただきありがとうございます。私たちはこの問題を認識しており、.NET フレームワークの次のメジャー リリースで修正しました。
ご不明な点がございましたら、この問題を再度有効にしてください。できるだけ早く対応いたします。ありがとう、キム・ハミルトン基本クラス図書館」
問題が関連しているかどうかはわかりません。Microsoft Connect には、いくつかの USB シリアル バグが報告されています。
おそらく、メイン コードの周りに Try キャッチ クローズを追加し、キャッチ クローズで CloseHandle を呼び出すことができます。その後、プログラムがクラッシュしても、CloseHandle が呼び出されます。
try
{
HANDLE hPort = NULL;
hPort = CreateFile(...);
// You code...
}
catch (...)
{
if (hPort != NULL)
CloseHandle(hPort);
}
デバイスのプラグを抜いてから再度差し込んでみてください。Windowsは、そのポートに誰も接続していないことを通知する必要がある場合があります。