アプリケーションがクラッシュして閉じ、[送信しない]ボタンと[エラーレポートを送信する]ボタンを含むダイアログが表示された場合に実行する必要のある手順を教えてください。
これを解決するためにイベントビューアを見る以外に何ができるでしょうか?
ありがとう
アプリケーションがクラッシュして閉じ、[送信しない]ボタンと[エラーレポートを送信する]ボタンを含むダイアログが表示された場合に実行する必要のある手順を教えてください。
これを解決するためにイベントビューアを見る以外に何ができるでしょうか?
ありがとう
エントリ メソッドの本体のtry/catch/finally
周りに構造を追加できます。Main()
ThreadException
WinForms の場合、Application.Run() の直前にハンドラーを追加して、WinForms UI イベント ハンドラーでスローされた例外をキャッチできます。
Application.ThreadException +=
new ThreadExceptionEventHandler(Application_ThreadException);
他のすべての未処理の例外は、次を使用してキャッチできます。
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
ただし、これは例外のログ/レポートのみを許可することに注意してください。この最終ハンドラーを終了すると、アプリケーションが閉じないようにすることはできません。
Visual Studio は初回例外で中断するように構成することもでき、外部デバッガー (管理された SoS 拡張機能を持つ WinDbg など) も初回例外をキャッチできます ( http://www.codeproject.com/KB/debug/windbg_part1.aspx ) 。 .
また、log4net などのロギング フレームワークを使用して、便利なロギングをアプリに追加し、アプリケーションを閉じる前に例外情報をダンプします。
「送信/送信しない」エラーは、バックグラウンド スレッドで未処理の例外がある場合に発生する傾向があります (メイン スレッドは、スタック トレースを使用して .NET ダイアログを続行/終了することを示します)。
スレッドの関数に例外ハンドラーを追加し、そこからログを記録します。
void RunMyThread()
{
try
{
// background thread code
}
catch (Exception ex)
{
// Log the exception
}
}
これは非常に単純化されており、例外を処理したい方法ではない場合があります。しかし、うまくいけば、これがあなたを正しい方向に動かしてくれるでしょう。
それが顧客のサイトで発生し、開発者のデバッガー内で簡単に再現できない場合は、事後分析デバッグを行うことができます。Userdumpを使用してメモリ ダンプ ファイル (.DMP) を収集するのが好きです。次に、windbg を使用して分析します。
WinDBG を使用して問題をデバッグします。例外がスローされたときに (ブレークポイントでの停止のように) 中断させてから、スタックトレースを調べることができます...スコープ内のオブジェクトなど...