.NET Runtime エラー発生時のダイヤログ表示を省くには？

Question

C# (.NET Framework 3.0) ベースで Windows サービスアプリケーションを開発しています。

発生条件が不明なのですが、時として イベントログ（アプリケーションログ）に

.NET Runtime version : 2.0.50727.4234 - アプリケーション エラー アプリケーションで、ハンドルできない例外が発生しました。

処理ID=****、スレッドID=****

アプリケーションを終了するには [OK] をクリックしてください。

アプリケーションをデバッグするには、[キャンセル]をクリックしてください。

が記録されています。

処理ID は、C#のサービスプログラムに該当しているため、サービスプログラム内の処理で

捕捉できていない例外が発生しているとは思われますが、肝心のスタックトレース情報が取得できないため、

問題点が特定できずに至っています。

質問としては

(1) 上記のように [OK] [キャンセル] のユーザー入力画面を出さずに、即時終了させるような

     設定はないでしょうか？(なんらかのconf設定で可能ならその設定内容を知りたいです)

(2) 同、異常発生時のスタックトレース（または ダンプ）を自動的に出力するような設定はないでしょうか？

になります。

知識不足申し訳ありませんが、よろしくお願いいたします。



Answer 1

納田さん、こんにちは。

ひとまず、UnhandledExceptionを使ってみて、補足できない例外をチェックしてみてからの方が良いと思います。

具体的には、Mainなどスタートアップ関数や、その他初期処理の場所などで、

System.AppDomain.CurrentDomain.UnhandledException +=
    new UnhandledExceptionEventHandler(UnhandledExceptionHandler);

としておいてから、

以下のような関数を作成しておきます。

static void UnhandledExceptionHandler(object sender, UnhandledExceptionEventArgs e)
{
    try
    {
    　  // ここで例外の内容を確認する
        Exception ex = (Exception)e.ExceptionObject;
    }
    finally
    {
        Environment.Exit(1);
    }
}

いずれにしても、どこまで処理が進んでいるかは、確認してみてください。

動作ログを、テキスト形式でもなんでもよいですので。

Answer 2

回答ありがとうございます。

ただ、現状でも UnhandledException や ThreadException 機構は宣言して独自のログに記録が残るようにしているのですが、何故か記録されないので、

（ポップアップダイヤログが上がったままだと残らない？）

別手段が講じられないかというのが、本質問の背景になっています。

Answer 3

ネイティブコードが作成したスレッドでハンドルされていない例外が発生した場合、それらのイベントで捕捉できない可能性があります。
そういった可能性は考えられますか？

Answer 4

納田さん、こんばんは。

ログについては、了解しました。

全くログが出力されない、ということではないのですよね？

In/Outなど、どこまでトレースできていますでしょうか？

いつも同じ箇所でログがきれてしまうのでしょうか？

など、他に教えていただける範囲でよいのですが、状況をお教えいただけませんか？

Answer 5

アドバイスありがとうございます。

内部処理でアンマネージを呼び出している箇所は確かに存在します。

ただ、そういった処理は結構な頻度（例.数分毎）で使用されているのですが、

必ず異常となるものではなく、一定の長期運転（例.一週間）＋

限られた端末環境下で 冒頭のエラー（はい／いいえ確認）発生に至っています。

Answer 6

返信遅くなりました。

目下稼働ログの内容（レベル）を変更して、より直前の処理箇所が把握できないかを採取試行中ではありますが、如何せん 今の所は意図的な再現そのものが難航しています。

現状残っている稼働ログからは、定期的に実行しているスレッド内で、一週間といった長期スパン（連続運転）で何か捕捉外エラーが起きているように推測しているのですが、もともと然程ログ箇所は多くないため、どの定期スレッド（複数が内部実行されます）かも不明な状況です。

（ソースチェックでは、スレッド内で起きうる例外捕捉は考慮できており、またTickCount といったような桁あふれ考慮不足もありません。パフォーマンスモニタ計測からもメモリ枯渇やリークといった傾向は見られておりません）

メインスレッドを止めてしまう程の何が起きているのかが目下は謎でして、「はい／いいえ」確認が現出してしまうのさえ止められれば、ひょっとしてサービスの死活監視・自立回復で 取り急ぎは運用回避できるのでは？と（安易ではありますが）期待もしています。