none
Just-In-Time デバッガーの起動 RRS feed

  • 質問

  • Visual Studio Just-In-Time デバッガー

    ~.exe [????] でハンドルされていない Win32 例外が発生しました。
    利用可能なデバッガー(P):
    新しいインスタンス Mircrosoft Visual Studio 2015


    配布しているプログラムで使ってるユーザーさんの環境で
    上記のデバッガーが立ちあがってしまいました。
    ユーザーさんが Visual Studio をインストールしていても、
    このデバッガーが起動しないようにするにはどうしたらいいでしょうか?
    2016年9月6日 5:07

回答

  • 実行時に例外で終了してしまうというのは、言い方を変えるとクラッシュバグを含んだままリリースされているということを意味します。

    ほかの皆さんが提示してくださっているような、小手先テクニックで逃げる方法もあると思いますが

    「クラッシュバグを含んだままリリース」するという選択肢をとるよりは、デバッグして修正する方がその後のことも考えれば工数が少なく済むと思います。

    ちなみに、ハンドルされない例外をシステムがとらえた場合、「システムレベルのイベント」として該当アプリをデバッグするか?というイベントが発生します。

    この時、デバッグ機能を持つプログラムが登録されていると、ユーザーに選択肢としてデバッガでアタッチしてデバッグするか?という選択肢が与えられます。

    残念ですが、特定のプログラムのみこの機能を発生させないというオプションは存在しません。


    とっちゃん@わんくま同盟, Visual Studio and Development Technologies http://blogs.wankuma.com/tocchann/default.aspx

    • 回答としてマーク あか 2016年9月7日 3:39
    2016年9月6日 8:14
  • 工数的な問題と言われると無償で回答する側としては萎えますね。時間がないというのも回答者には関係ありませんし。

    とはいえSetUnhandledExceptionFilter()でハンドルされていない例外に対する処理を追加できます。

    SetUnhandledExceptionFilter([](auto) { return LONG(EXCEPTION_EXECUTE_HANDLER); });

    等をプログラムの先頭の方で実行することで、プロセス内でハンドルされていない例外が発生した場合に黙って終了してくれそうです。

    ただし、Visual C++には構造化例外とC++例外の2種類の例外機構が存在します。「ハンドルされていない例外」がどちらの機構で発生したものか、またコンパイルオプションException Handling Modelの設定によっても左右されます。ですので、上記方法ですべての例外を処理できるとは限りません。やはり、kenjinoteさんが提案されているようにきちんと例外をキャッチすべきです。

    • 回答としてマーク あか 2016年9月7日 3:39
    2016年9月6日 6:46
  • まず思いつくことは、コード側の修正です。例外が発生している箇所で例外をキャッチ(構造化例外の場合は__try、__except)することですが、その対応は難しいのでしょうか?

    • 回答としてマーク あか 2016年9月7日 3:39
    • 編集済み kenjinoteMVP 2016年9月12日 5:27
    2016年9月6日 5:17

すべての返信

  • VS2005のページですが、下記のページに記載されていました、

    https://msdn.microsoft.com/ja-jp/library/k8kf6y2a(v=vs.80).aspx

    2016年9月6日 5:17
  • まず思いつくことは、コード側の修正です。例外が発生している箇所で例外をキャッチ(構造化例外の場合は__try、__except)することですが、その対応は難しいのでしょうか?

    • 回答としてマーク あか 2016年9月7日 3:39
    • 編集済み kenjinoteMVP 2016年9月12日 5:27
    2016年9月6日 5:17
  • こちらは Visual Studio をインストールしている人が
    デバッガーが立ちあがるかどうかを設定するものであって、
    特定のプログラムに対してデバッガーを立ちあがらせないように
    する為のものではないように見えるのですが如何でしょうか?

    何かこうコンパイルオプション的な感じで抑制出来ないのかなと。
    2016年9月6日 5:23
  • その例外が起きてると思われる場所が外部の人にdllで組んで貰った所な物で、
    工数的な問題であまりもう時間がないという現状でして…。
    2016年9月6日 5:25
  • 工数的な問題と言われると無償で回答する側としては萎えますね。時間がないというのも回答者には関係ありませんし。

    とはいえSetUnhandledExceptionFilter()でハンドルされていない例外に対する処理を追加できます。

    SetUnhandledExceptionFilter([](auto) { return LONG(EXCEPTION_EXECUTE_HANDLER); });

    等をプログラムの先頭の方で実行することで、プロセス内でハンドルされていない例外が発生した場合に黙って終了してくれそうです。

    ただし、Visual C++には構造化例外とC++例外の2種類の例外機構が存在します。「ハンドルされていない例外」がどちらの機構で発生したものか、またコンパイルオプションException Handling Modelの設定によっても左右されます。ですので、上記方法ですべての例外を処理できるとは限りません。やはり、kenjinoteさんが提案されているようにきちんと例外をキャッチすべきです。

    • 回答としてマーク あか 2016年9月7日 3:39
    2016年9月6日 6:46
  • 実行時に例外で終了してしまうというのは、言い方を変えるとクラッシュバグを含んだままリリースされているということを意味します。

    ほかの皆さんが提示してくださっているような、小手先テクニックで逃げる方法もあると思いますが

    「クラッシュバグを含んだままリリース」するという選択肢をとるよりは、デバッグして修正する方がその後のことも考えれば工数が少なく済むと思います。

    ちなみに、ハンドルされない例外をシステムがとらえた場合、「システムレベルのイベント」として該当アプリをデバッグするか?というイベントが発生します。

    この時、デバッグ機能を持つプログラムが登録されていると、ユーザーに選択肢としてデバッガでアタッチしてデバッグするか?という選択肢が与えられます。

    残念ですが、特定のプログラムのみこの機能を発生させないというオプションは存在しません。


    とっちゃん@わんくま同盟, Visual Studio and Development Technologies http://blogs.wankuma.com/tocchann/default.aspx

    • 回答としてマーク あか 2016年9月7日 3:39
    2016年9月6日 8:14
  • なるほど、お二人ともご丁寧に説明して頂き、ありがとうございます。
    それとご不快にさせてしまって申し訳ありませんでした。
    確かにクラッシュバグが入ったままというのが問題なのですが、
    実際に修正して貰うにしても時間が掛ってしまうので
    一先ずの対処が出来ないかと思った次第なのです。

    ですので SetUnhandledExceptionFilter 可能な範囲でカバーしつつ、
    あとは時間を見つつ例外をキャッチする修正を入れて貰う方向にしようと思います。
    2016年9月7日 3:39