none
アプリケーションのアドレスマップから落ちた場所を特定したい。 RRS feed

  • 質問

  • 環境:WinXP VS2005 C#2.0

    お世話になっております。

    ユーザーからアプリケーションが落ちたという報告があり、

    デバッグ情報は出なかったようですが、イベントビューワにNULL参照エラーで落ちたと出力されており、「4e1fef1c」というアドレスが出力されていました。

     

    VC++6.0を使っていたときはMAPファイルやCODファイルを出力して、

    イベントビューワ出力のアドレスから落ちた場所を特定できましたが、

    C#ではそのようなことができますでしょうか。宜しくお願い致します。

     

     


    2011年7月15日 7:50

回答

  • C#というか.NET Frameworkアプリケーションは、.NET VMというかある種の仮想マシン上で動作しています。

    そのため、NULL参照を含むほぼ全てのエラーをプログラム内で処理でき、プログラムを強制終了させる必要はありません。try-catch文で例外を適切に処理してください。

    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 13:56
  • デバッガ上でならともかく、オフラインではまず無理だと思いますよ。

    クラッシュダンプでもあれば別ですが、それも無いんですよね?

    そもそも同じ実行環境でも実行タイミングによってはモジュールが読み込まれるアドレスがずれる可能性がありますし、今時は OS がモジュールをわざと毎回違うアドレスに読み込んだりしますし。

    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 14:57
  • イベントビューワ出力のアドレスから落ちた場所を特定できましたが、
    C#ではそのようなことができますでしょうか。宜しくお願い致します。

    無理かと思っています。
    なぜなら、実行時にコンパイルされるため、アドレスが一定ではないと予想されるためです。

    ダンプファイルが取得できるのであれば、それとシンボルファイル(pdb)から解析は可能かもしれませんね。

    # いきなり落ちたのなら、ネイティブコード部分の可能性が高いけれども。バックグラウンドスレッドで落ちたりとかしているのかな?


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 15:00
    モデレータ
  • その情報だけではなんとも言えませんが、以下のようなEvent logは出ていませんか?

    [Unhandled Exception Processing In The CLR]
      http://msdn.microsoft.com/en-us/magazine/cc793966.aspx
      Figure 6です。調べ方も記述されています。

    また、そのEvent Logの前後にソースが.NET Runtimeの以下のようなlogは出ていませんか?
      Application: XXX.exe
      Framework Version: vXXX
      Description: The process was terminated due to an unhandled exception.
      Exception Info: System.NullReferenceException
      Stack: at System.Windows.Forms.XXX at System.Windows.Forms.XXX.XXX ・・・

    このlogが出ていれば、例外が発生した場所ぐらいは分かるでしょう。

    Event logの確認ができる状況なら、調べてみては如何でしょうか。


    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 4:00
  • クラッシュダンプとかダンプファイルというのはすみません、どのようなものでしょうか。

    ダンプファイル(クラッシュダンプ)は、そのときのメモリの状態などを保存することで、どのスレッドがどの関数を実行中か、どのような例外が起きていたのかを知る手がかりになります。
    ただし、これを活用するためには、ダンプファイルの取得に協力してもらえること、ビルド時のシンボルファイル(pdb)が残っていること、WinDbg などのダンプファイルを解析するソフトウェアをある程度使いこなすことが必要です。

    http://msdn.microsoft.com/ja-jp/library/d5zhxt22.aspx

    リリース版で出すのは辞めようかなという気がしてきました・・・

    デバッグ版にどのような価値をお考えですか?
    例外発生時にコールスタックなどが見えるダイアログが表示されない状況であれば、デバッグ版であろうと、リリース版であろうと、このダイアログは表示されません。
    従って、デバッグ版を出すことによる価値はないと思っています。

    なお、このダイアログが表示されないのは、メインスレッド以外で例外が発生した可能性が高いと思っていますが、確実ではありません。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 23:37
    モデレータ
  • 皆様ご回答ありがとうございました。

     

    バックグラウンドスレッドで落ちたのかどうかもわからない状況です。

    クラッシュダンプとかダンプファイルというのはすみません、どのようなものでしょうか。

     

    Unhandled Exception Processing In The CLRの例外と言うのは出ておりませんでした。

    このような情報が出てくれば非常に助かるのですが・・・


    リリース版で出すのは辞めようかなという気がしてきました・・・


    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 14:56

すべての返信

  • C#というか.NET Frameworkアプリケーションは、.NET VMというかある種の仮想マシン上で動作しています。

    そのため、NULL参照を含むほぼ全てのエラーをプログラム内で処理でき、プログラムを強制終了させる必要はありません。try-catch文で例外を適切に処理してください。

    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 13:56
  • デバッガ上でならともかく、オフラインではまず無理だと思いますよ。

    クラッシュダンプでもあれば別ですが、それも無いんですよね?

    そもそも同じ実行環境でも実行タイミングによってはモジュールが読み込まれるアドレスがずれる可能性がありますし、今時は OS がモジュールをわざと毎回違うアドレスに読み込んだりしますし。

    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 14:57
  • イベントビューワ出力のアドレスから落ちた場所を特定できましたが、
    C#ではそのようなことができますでしょうか。宜しくお願い致します。

    無理かと思っています。
    なぜなら、実行時にコンパイルされるため、アドレスが一定ではないと予想されるためです。

    ダンプファイルが取得できるのであれば、それとシンボルファイル(pdb)から解析は可能かもしれませんね。

    # いきなり落ちたのなら、ネイティブコード部分の可能性が高いけれども。バックグラウンドスレッドで落ちたりとかしているのかな?


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク Myon 2011年7月17日 1:35
    2011年7月15日 15:00
    モデレータ
  • その情報だけではなんとも言えませんが、以下のようなEvent logは出ていませんか?

    [Unhandled Exception Processing In The CLR]
      http://msdn.microsoft.com/en-us/magazine/cc793966.aspx
      Figure 6です。調べ方も記述されています。

    また、そのEvent Logの前後にソースが.NET Runtimeの以下のようなlogは出ていませんか?
      Application: XXX.exe
      Framework Version: vXXX
      Description: The process was terminated due to an unhandled exception.
      Exception Info: System.NullReferenceException
      Stack: at System.Windows.Forms.XXX at System.Windows.Forms.XXX.XXX ・・・

    このlogが出ていれば、例外が発生した場所ぐらいは分かるでしょう。

    Event logの確認ができる状況なら、調べてみては如何でしょうか。


    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 4:00
  • 皆様ご回答ありがとうございました。

     

    バックグラウンドスレッドで落ちたのかどうかもわからない状況です。

    クラッシュダンプとかダンプファイルというのはすみません、どのようなものでしょうか。

     

    Unhandled Exception Processing In The CLRの例外と言うのは出ておりませんでした。

    このような情報が出てくれば非常に助かるのですが・・・


    リリース版で出すのは辞めようかなという気がしてきました・・・


    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 14:56
  • クラッシュダンプとかダンプファイルというのはすみません、どのようなものでしょうか。

    ダンプファイル(クラッシュダンプ)は、そのときのメモリの状態などを保存することで、どのスレッドがどの関数を実行中か、どのような例外が起きていたのかを知る手がかりになります。
    ただし、これを活用するためには、ダンプファイルの取得に協力してもらえること、ビルド時のシンボルファイル(pdb)が残っていること、WinDbg などのダンプファイルを解析するソフトウェアをある程度使いこなすことが必要です。

    http://msdn.microsoft.com/ja-jp/library/d5zhxt22.aspx

    リリース版で出すのは辞めようかなという気がしてきました・・・

    デバッグ版にどのような価値をお考えですか?
    例外発生時にコールスタックなどが見えるダイアログが表示されない状況であれば、デバッグ版であろうと、リリース版であろうと、このダイアログは表示されません。
    従って、デバッグ版を出すことによる価値はないと思っています。

    なお、このダイアログが表示されないのは、メインスレッド以外で例外が発生した可能性が高いと思っていますが、確実ではありません。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    • 回答としてマーク Myon 2011年7月17日 1:34
    2011年7月16日 23:37
    モデレータ
  • Azulean様ご回答ありがとうございました。

    別スレッドの例外はデバッグ版でもコールスタックが出ないのですね。

    てっきり出るものと思っておりました。勉強になりました。

    実際試してみましたが、確かに別スレッドの例外ではダイアログが出ませんでした。

     

    勿論TryCatchによる対処が基本ですが、

    ダンプファイルについて勉強してみようと思います。

    皆様ご協力ありがとうございました

     

    2011年7月17日 1:34
  • あとは AppDomain.UnhandledException イベントにハンドラを登録して、そこでログを書き出すとかでもヒントになるかもしれませんね。

    http://msdn.microsoft.com/ja-jp/library/system.appdomain.unhandledexception.aspx

    このイベントは別スレッドであっても例外発生時にある程度呼び出されます。

    # 例外のコールスタックダイアログは Application クラスがメッセージループの中で try-catch を使って実装しているダイアログです。
    # 従って、メインスレッド以外ではコールスタックがでませんし、また、Application.ThreadException イベントに何か登録しているとメインスレッドでもダイアログがでません。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    2011年7月17日 4:10
    モデレータ