問題タブ [structured-exception]

バックグラウンド

• Poof-Crash [ 1 ]のあるアプリケーションがあります。吹き飛ばされたスタックが原因であると確信しています。
• アプリケーションはマルチスレッドです。
• " " でコンパイルしていEnable C++ Exceptions: Yes With SEH Exceptions (/EHa)ます。
• SE トランスレーター関数を作成し、それを呼び出し_set_se_translator()ました。
• set_terminate()と setupとの関数を書きましset_unexpected()た。
• スタック オーバーフローを取得するには、負荷の高い状態でリリース モードで数日間実行する必要があります。アプリケーションは、問題を確認するために必要なランタイムを達成するのに十分な速度で実行できないため、デバッガーの下で実行することはできません。
• 関数の 1 つの実行時に無限再帰を追加することで問題をシミュレートし、EXCEPTION_STACK_OVERFLOW例外のキャッチをテストできます。
• クラッシュ ダンプ プログラムとして WinDBG をセットアップしましたが、他のすべてのクラッシュの問題に関する適切な情報が得られますが、この問題に関する情報は得られません。クラッシュ ダンプには、'Sleep()'ing である 1 つのスレッドのみが含まれます。他のすべてのスレッドは終了しました。

質問

EXCEPTION_STACK_OVERFLOW私が試したことのどれも、例外を拾うことにはなりませんでした。

リリースモードでの実行時にこの例外が発生する可能性を保証する方法を知っている人はいますか?

定義

1. Poof-Crash : アプリケーションがクラッシュし、"poof" して跡形もなく消えます。

(このサイトの名前を考えると、この質問がまだここにないことに驚きました!)

ノート

1. スタックサイズを調整して問題をより早く強制し、デバッガーでキャッチできるようにすることについての簡単な回答が投稿されました。それは賢明な考えですが、残念ながら、それが役立つとは思えません。この問題は、無限再帰につながるコーナー ケースが原因である可能性があります。スタックを短くしても、問題がすぐに明らかになることはなく、有効に深いコードで無関係なクラッシュが発生する可能性があります。良いアイデアですが、削除してしまったにもかかわらず、投稿していただきありがとうございます。

今日、私は興味深いジレンマに遭遇しました。情報を処理し、重複する値をチェックして、重複していない次の数値を返す関数があります。だから、私はこのようなものを持っています：

次に、関数の下部に、次のように、重複がなくなるまでインクリメントして重複を処理するcatchブロックがあります。

ご覧のとおり、例外を具体的に処理したいのですが、関数外の他のコードにアラートを送信したいので、終了時に例外をスローしたいと思います。

問題は、単にそれをスローすると、null値を使用して関数が終了することです。私try/catchは間違った方法を考えていますか、それともこれを回避する方法がありますか？

(Win32 プラットフォーム c++) __try と __finally を使用して、例外の原因のモジュール名 (およびアドレス) を取得するにはどうすればよいですか? GetExceptionInformation() を呼び出しますが、この情報がどこにあるのかわかりません。

オンラインおよび MSDN の他のリソースを考えると、Minidump ハンドラーと他のサンプル コードはそれを取得できるようですが、方法はわかりません。

参考文献またはより啓発的なリソースを歓迎します。

誰かがVB6にSEHを実装する例を教えてもらえますか？これまでに見たものはすべてC++です。

すべての C++ 開発者が知っておくべき構造化例外に関する重要なポイントは何ですか?

MSDNはUnhandledExceptionFilter、次のように説明しています。「プロセスがデバッグされている場合に、未処理の例外をデバッガーに渡すアプリケーション定義関数。」

しかし、この関数は、同じページによると、kernel32.dllのOSによって明確に提供されています。

では、なぜ彼らはそれをアプリケーション定義関数と呼ぶのでしょうか？

私は、管理されていないユーザーモードのWindowsプロセスが「クラッシュ」する方法を理解しようとしています（これは、実際にはあまりにも多くの包括的な用語です）。

これまでに私が知っている方法は次のとおりです。

• 未処理の構造化例外
  • デフォルトのUnhandledExceptionFilter：pre-Vistaの事後デバッガ。Vista+のWerFault
  • カスタムUnhandledExceptionFilter：静かに終了するなど、好きなことを実行できますか？
• 「ハード」クラッシュ（これに専門用語があるかどうかはわかりません）
  • たとえば、スタックオーバーフローの処理中にスタックオーバーフローガードページにアクセスする：OSは、トレースなしでプロセスを単に非表示にしますか？
• 「通常の」終了：
  • たとえば、言語が独自のエラー処理メカニズムを提供し、アプリケーションが正常にシャットダウンしたように、致命的なクラッシュをOSに見せます。

これは大まかに正しいですか？ユーザーモードのWindowsプロセスを終了させる他の方法はありますか？

::fgetpos を呼び出すコードがあり、キャッチできないカーネル例外が発生します (私の VS 2008 プロジェクトにはオプション /ehs があります)。しかし、標準ライブラリ ルーチンがこの種の例外をスローする べきではないと思わずにはいられません。

update : ::fgetpos(0, &foo) を呼び出してみましたが、これは明らかに間違っていて、実際にカーネル レベルの例外を受け取りました。私は困惑しています。C++ 標準ライブラリが最も基本的な引数チェック (null ポインターのチェック) を実行せず、std::invalid_argument を発生させないのはなぜですか?

そのような基本的なチェックを実行する標準ライブラリルーチンはありますか?それとも、それらはすべて喜んでプログラムを終了させますか?

Doug Harrison が、構造化された例外を使用する (つまり、キャッチする) ことの何が「間違っている」かについて良い意見を述べているのを見ました (質問 #3を参照)。しかし、他にどのような結果がありますか？たとえば、/eha でコンパイルされた複数のプロジェクトが、/ehs でコンパイルされた他のプロジェクトと混在している場合はどうなりますか? ライブラリが相互にリンクされているとき (コンパイル時または実行時) に問題はありますか?

しかし、それはほんの一例です。他にどのような問題が考えられますか?

Visual Studio 2008 C ++プログラムがあり、プログラムは__try/__exceptブロックでラップされてSEH例外をキャプチャします。例外フィルターはエラーログを作成し、ユーザーに欠陥レポートの送信方法に関する詳細な指示を提供します。

__tryフィルタ内のコードを別の/__exceptブロックでラップする必要がありますか？そうでない場合、それを除いてどうなりますか？もしそうなら、それはどのように扱われるべきですか？

ありがとう、PaulH

編集：例外が発生した 場合MyFilter、私は無限の例外ループに入ります。だから、それは必要__try/__except処理をしているように見えます。私はこれを行うことを検討しています：

この場合、プログラムは異常終了し、OSに例外を渡して処理する必要があります。あれは正しいですか？