none
一般的なパッケージソフトのJust-In-Timeデバッガの設定について RRS feed

  • 質問

  • いつもお世話になります。mkmarimoです。

     

    題記のとおりJust-In-Timeデバッガの設定について質問させてください。

     

    現在初めて、Visual Studio 2005でC#を用いた開発を行っており、Just-In-Timeデバッガの設定に関する

    最適な設定値がわからず悩んでいます。

    MSDNなども参照しましたが、いまひとつ納得できない状態です。

     

    .NET FrameworkにおけるJust-In-Timeデバッガに関するキーワードとして以下のようなものを見つけました。

     

    ・アプリケーション構成ファイルかmachine.configに以下の設定を追記する。

     

    <configuration>

              <system.windows.forms jitDebugging=”true” />

    </configuration>

     

    ・レジストリHKEY_LOCAL_MACHINE\Software/Microsoft/.NETFramework\DbgJITDebugLaunchSettingに何か値を設定する。

     (0、1、2、16?)

     

    ・WindowsFormsSection.JitDebugging プロパティ。

     

    ・構成(DebugかReleaseか)による違い。

     

    一般的な.NET Frameworkで実装されたパッケージソフトなどはこれらの値をどのように設定して出荷すべきでしょうか。

    何をやりたいかによってケースバイケースだとは思いますが、最適解的な設定があればご教授ください。

     

    というか、そもそもこれらの値はパッケージソフト出荷後、ユーザの環境にインストールされた後も効くものでしょうか。

     

    私の理想としては、パッケージソフトが出荷され、ユーザの手元で使用されているときに、ハンドルされない例外などで、

    アプリケーションが落ちた場合でも、ダンプなどを出力して、原因追究の足がかりとなる情報が残るような設定です。

    そもそもJust-In-Timeデバッガが有効ならアプリケーションクラッシュ時にダンプが残るというものなんでしょうか。

     

    この点に関して調べていると、.NET Frameworkのスタック情報を残すにはレジストリDbgJITDebugLaunchSettingは

    0に設定するといった記事も見たことがあります。

    ということは、パッケージソフトのインストーラはユーザ環境の上記レジストリやmachine.configファイルを

    勝手に書き換えたりしているのでしょうか。

     

    知識が未熟で申し訳ありませんが、徐々にでもこのへんの知識を身につけていきたいので、わかる範囲で

    構いませんのでご教授ください。

    2007年10月16日 1:11

回答

  • .NET でのアプリケーションを出荷していますが、そういった設定は特に行なっておりませんね。
    ぽてくりさんの書いた通り、アプリケーション自身でログを出力して、
    それを使って診断にあたる開発スタイルが多いようです。

    C や C++ で開発が主であった頃は、ちょっとしたコーディングミスだけで、
    簡単にメモリアクセス違反等が起こっていました。
    これら例外は、OS にとってはルール違反ですので、プロセスが即時停止する要因になりました。

    これら例外をアプリケーションで処理する方法には非常に制約が多いため、
    結果的に OS の力を借りて、アプリケーションがクラッシュした際のダンプ情報を取得する必要がありました。
    これらダンプ情報は、診断を行う際にも大事な情報源となります。

    .NET のアプリケーションは少し性質が違い、
    .NET 例外であれば、アプリケーション内部で処理することが可能です。

    わざわざハンドルされていない例外が発生した際のスタックトレースを出力して診断しなくても、
    コードに例外ハンドラを仕込み、アプリケーション自身が診断用のログを吐く方が原因究明が簡単なのです。
    ロジックによるミスはほとんどが .NET 例外でしょうから、これだけでも十分な事が多いです。

    マネージアプリケーションが「クラッシュする」ということは、
    CLR の問題か、ハードウェア等のアンマネージリソースに関係したトラブルでしょうから、
    アプリケーションの機能の枠を超えた問題として、別に処理を考え、
    .NET アプリケーション側では考慮しないようにしていますね。

    マネージアプリのクラッシュで CLR に遡ってデバッグするのは、
    アンマネージアプリで、OS に遡ってをデバッグするようなものですから……。
    2007年10月31日 14:35

すべての返信

  • 質問内容に関する直接的な回答ではありませんが…。

     

     mkmarimo さんからの引用

    私の理想としては、パッケージソフトが出荷され、ユーザの手元で使用されているときに、ハンドルされない例外などで、

    アプリケーションが落ちた場合でも、ダンプなどを出力して、原因追究の足がかりとなる情報が残るような設定です。

    そもそもJust-In-Timeデバッガが有効ならアプリケーションクラッシュ時にダンプが残るというものなんでしょうか。

     

    .NET のアセンブリはアンマネージドのバイナリと違って、ダンプファイルの出力を行いたい場合にはレジストリキーの変更等が必要になってきます。

    ですので、提供するアプリケーション、システムの要件によってはクラッシュダンプファイルが生成できない場合もあるかと思います。

     

    # というのは、

    # http://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=2108520&SiteID=7

    # でもお話させていただいてましたね…。

     

    インストーラを作成する場合には合わせてレジストリの変更等を行うことで要件を満たせる可能性はありますが、市販の製品はどうなのでしょう…。おそらくはアプリケーションの起動スイッチのようなものでより詳細なアプリケーションのログを取得したりしてるんじゃないかと邪推したりしてますが、基本的にはそのアプリケーションごとに違うものでしょうね。

     

    クラッシュダンプファイルの取得はアプリケーションをデバッグする上で非常に有益な方法だと思うんですが、ダンプファイルの解析には、例えば WinDbg で SOS.DLL を使ったりとかなり大変な分野になってくるはずです。

     

    作成されているアプリケーションの性質にもよるかと思いますが、アプリケーション側でログを出力する方が解析がしやすい場合もあるかと思います。

     

    ちなみに、個々のアプリケーションが Machine.Config を勝手に書き換えたりすることは考えにくいですね…。他の .NET アプリケーションの動作まで変わってくる可能性がありますし。せいぜい App.Config で対応してるくらいじゃないでしょうか。

    2007年10月16日 16:08
  • ぽてくりさん

     

    お世話にないrます。mkmarimoです。

     

    毎度、私のわけのわからない質問にご回答くださり、ありがとうございます。

     

     ぽてくり さんからの引用

    .NET のアセンブリはアンマネージドのバイナリと違って、ダンプファイルの出力を行いたい場合にはレジストリキーの変更等が必要になってきます。

    ですので、提供するアプリケーション、システムの要件によってはクラッシュダンプファイルが生成できない場合もあるかと思います。

     

    やっぱり、.NETではレジストリやApp.configなどを変更しないとダンプファイルは出力できないのですね。

    これらを変更するとJust-In-Timeデバッガが有効になるわけですが、以下の関係式が成り立つという認識で間違いないでしょうか。

     

     Just-In-Timeデバッガを有効化する = .NETのスタック情報を持つダンプを出力できるようになる

     

    これが成り立つとしてもパッケージソフトがユーザの手元に渡ってから、machine.configやレジストリを勝手に

    書き換えるというのは影響範囲も大きいので現実無理ということは、上で書いた私の理想は実現できないという答えにたどり着きます。

     

    なぜ、.NETではダンプファイルをデフォルトで出力できないようになったのか疑問です。。。

    その分、ぽてくりさんのおっしゃるようにログの出力の方に力を入れていきたいと思います。

     

    本質問についてはもう少し、いろんな意見も聞きたいのでオープン状態にしておきます。

    他に回答があるかどうか微妙ですが・・・。

    2007年10月17日 2:37
  • .NET でのアプリケーションを出荷していますが、そういった設定は特に行なっておりませんね。
    ぽてくりさんの書いた通り、アプリケーション自身でログを出力して、
    それを使って診断にあたる開発スタイルが多いようです。

    C や C++ で開発が主であった頃は、ちょっとしたコーディングミスだけで、
    簡単にメモリアクセス違反等が起こっていました。
    これら例外は、OS にとってはルール違反ですので、プロセスが即時停止する要因になりました。

    これら例外をアプリケーションで処理する方法には非常に制約が多いため、
    結果的に OS の力を借りて、アプリケーションがクラッシュした際のダンプ情報を取得する必要がありました。
    これらダンプ情報は、診断を行う際にも大事な情報源となります。

    .NET のアプリケーションは少し性質が違い、
    .NET 例外であれば、アプリケーション内部で処理することが可能です。

    わざわざハンドルされていない例外が発生した際のスタックトレースを出力して診断しなくても、
    コードに例外ハンドラを仕込み、アプリケーション自身が診断用のログを吐く方が原因究明が簡単なのです。
    ロジックによるミスはほとんどが .NET 例外でしょうから、これだけでも十分な事が多いです。

    マネージアプリケーションが「クラッシュする」ということは、
    CLR の問題か、ハードウェア等のアンマネージリソースに関係したトラブルでしょうから、
    アプリケーションの機能の枠を超えた問題として、別に処理を考え、
    .NET アプリケーション側では考慮しないようにしていますね。

    マネージアプリのクラッシュで CLR に遡ってデバッグするのは、
    アンマネージアプリで、OS に遡ってをデバッグするようなものですから……。
    2007年10月31日 14:35
  • kes@さん

     

    はじめまして。mkmarimoです。

     

    本件の回答はもうないと思ってましたが、久し振りに見るとあったのでうれしかったです。

    ありがとうございます。

     

    本質問を投稿してから、私も本件を継続して調べて培ってきた知識と、

    今回のkes@さんからの回答でこのあたりのマナーがわかってきました。

     

    今回、私が携わるプロジェクトでも特に設定は行わず、出荷する方針にしようと思います。

     

    ただ、そうなると今度は新たに例外処理に関するところで??なことが出てきていますので、

    またここで投稿させてもらうと思います。

     

    以上、ありがとうございました。

    2007年11月6日 10:07