私は問題を抱えています。私が開発しているアプリケーションのユーザーの 1 人が、時折、しかし定期的にアプリケーションのハングを経験しています。
これが発生すると、マシンのイベント ログに「アプリケーション ハング」のソースを含むエントリが見つかります。情報メッセージは、「アプリケーション [my app]、バージョン [正しいバージョン] をハングしています。モジュール hangapp、バージョン 0.0.0.0 をハングしています。アドレス 0x00000000 をハングアップします。」
アプリケーションがスローする未処理の例外をすべてログに記録していますが、これが発生してもログ ファイルにはエントリがありません。
私の現在の作業仮説は、アプリケーションが安全でないレガシー API を呼び出しているときに、このハングが発生しているというものです。これは私を驚かせません。私はこの API を何年も使用してきましたが、これまでハングしたことはありませんでしたが、本当にくだらないコードです。また、プログラムがランダムにハングするように見えるというユーザーの報告。これは真実ではないと思います。私が彼女を信じていないわけではありませんが、従来の API と対話するコードは、BackgroundWorker によって呼び出されるメソッド内で実行されています。バックグラウンド スレッドがアプリケーションをハングさせていた場合、これはユーザーにとってランダムに発生しているように見える可能性があります。
では、2 つの質問があります。1 つは具体的なもので、もう 1 つは一般的なものです。
具体的な質問: 非 UI スレッドで実行されているメソッドがハングした場合、スレッドが強制終了されるだけだと思います。それは実際にアプリケーション全体を殺しますか?
一般的な質問:
未処理の例外はすべてログに記録しています。私のプログラムは既にトレースを使用するように設定されています (ただし、疑わしいメソッドのアクティビティをトレースするには、インストルメンテーション コードを追加する必要があります)。他にやるべきことはありますか？.NET アプリケーションがハングしたときにクラッシュ後の分析を可能にする診断ツールはありますか? より多くの (そしてより使いやすい) データを取得するために呼び出すことができる .NET フレームワーク内のメカニズムはありますか?
編集: 私のコードを詳しく調べると、BackgroundWorker の使用はすべて、例外ハンドラーで呼び出されたメソッドをラップする、実装したユーティリティ クラスを介して行われていることを思い出しました。このハンドラーは例外をログに記録し、それをユーティリティ オブジェクトのプロパティとして返します。UI スレッドの完了イベント ハンドラーが例外を再スローし (コール スタックを失ったので、理想的とは言えませんが、既にログに記録されています)、UI のメインの例外ハンドラーが例外をメッセージ ボックスに報告し、終了します。アプリ。
そのようなことは何も起きていないので、バックグラウンド スレッドで例外がスローされることはないと確信しています。とにかく、.NET 例外はありません。
さらなるフォローアップ:
幸いなことに、ユーザーから十分なデータを取得して、レガシー API 内でハングが発生していないことを確認しました。これは、明らかに私が間違っていることを意味します。つまり、私はそれを修正できるので、勝ちます。また、トレースによって問題を切り分けることができることも意味します。これは、もう 1 つのメリットです。この質問に対する回答にとても満足しています。私は、おそらくこの問題にそれらを必要としないことをさらに嬉しく思います.
また、PostSharp は優れています。インストルメンテーション コードを既存のアプリケーションに追加する必要がある場合は、ほぼ確実にそれを使用する必要があります。