4

Windows 2003 サーバーには、純粋な .NET 3.5C#アプリ (アンマネージ コードなし) があります。ソケットを介して他のさまざまなリモート システムに接続し、データ ハブのように機能します。問題なく10〜15時間動作しますが、時々消えるだけです. タスク マネージャーを使用してアプリを監視すると、メモリ使用量は一定のままです。

関数ではMain()、アプリの残りの部分の呼び出しをtry .. catch完全に吹き飛ばすブロックにラップします。例外をファイルに記録する catch ブロックは無視されます。テストのために手動で例外を発生させると、catch ブロックが呼び出されます。

try .. catchI doに入る前に:

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);

システムにはワトソン博士がいますが、DRWTSN32.EXE指しているディレクトリには何も書き込まれません。

これを引き起こしている例外をキャッチするにはどうすればよいですか?

4

5 に答える 5

7

Microsoft のデバッグ ツールを使用してみてください。ここからダウンロードできます。

adplus を使用してクラッシュをキャプチャしてから、windbg を使用して分析します。

adplus -crash -pn your.exe -quiet

このブログには、Windows でのデバッグに関するすばらしい情報がたくさんあります。

于 2008-11-06T12:36:00.307 に答える
3

これが Windows フォーム アプリの場合、未処理の例外がウィンドウ メッセージ ポンプによってキャッチされている可能性が高いため、表示されません。これに対処するには、こちらの回答を参照してください。

Windows サービスの場合、例外がバックグラウンド スレッドに表示され、メイン スレッドにマーシャリングされていない可能性があります。これに対処するには、バックグラウンド スレッドをメイン スレッドにマーシャリングする必要があります。例外はそこで再スローされ、キャッチできるようになります。

コンソール アプリの場合は、少し当惑します。

編集: あなたのコメントは、これは Windows フォーム アプリであると述べています。その場合、既定で次の処理を行う組み込みの Windows フォーム例外ハンドラーによって例外が処理されるため、おそらく例外は表示されません。

  • 次の場合に、未処理のマネージ例外をキャッチします。
    • デバッガーが接続されていない。
    • ウィンドウ メッセージの処理中に例外が発生し、
    • App.Config で jitDebugging = false。
  • ユーザーにダイアログを表示し、アプリの終了を防ぎます。

この動作を無効にするには、App.Config で jitDebugging = true を設定します。次に、イベント Application.ThreadException に登録することで、未処理の例外を確認できるはずです。たとえば、C# では次のようになります。

Application.ThreadException += new Threading.ThreadExceptionHandler(CatchExceptions);
于 2008-11-06T13:05:57.890 に答える
1

EventLogにアプリケーションの痕跡がある可能性があります。

例外をキャッチする可能性なしに.Netアプリが消えてしまいました。これが発生するたびに、EventLogにエントリがありました。

イベントログを表示するには、コマンドプロンプトでEventVwrと入力するか、ボックスを実行します。

于 2008-11-07T11:27:34.903 に答える
1

また、起動時に WinDBG をアタッチし、.NET 例外でブレークポイントを有効にすることもできます。次に、!printexception何が起こっているかを確認するために a を実行できます。

于 2008-11-06T16:43:41.460 に答える
0

Windows フォーム アプリケーションの場合は、 を試すことができますApplication.ThreadException。

于 2008-11-06T12:33:14.303 に答える