問題タブ [seh]

私は簡単なコードを持っています:

Visual Studio のデフォルトのデバッグ設定。デバッグ -> 例外 -> すべてリセット。

デバッグ構成でこのコードを実行した後の結果 - exc.exe の 0x77d315de (ntdll.dll) で例外未処理の例外が発生しました: 0xC0000005: アクセス違反の書き込み場所 0x00000000。VS オープン ファイルostream、ポインターはここにとどまります。

スタックトレース：

デバッグで「スロー」チェックボックスを設定すると、-> Win32 Exceptions -> C0000005 Visual Studio が適切な場所で停止します。

私の同僚は、同じ Visual Studio、Windows 7 x64、および同じハードウェアを使用しています。しかし、彼の VS は例外設定を変更せずに適切な場所で停止します。

Visual Studio の設定の何が問題になっていますか?

最大の問題 - .net 例外の動作も一般的ではありません。現時点では、VS はデバッグ モードでほとんどすべての例外を無視します。グローバル例外フィルターがあり、すべての例外が処理されたようです。リリース モードでプログラムを実行し、ダイアログを表示できます Catel mvvm ツールキットは、登録されていないモデルとファイル システムの例外に関する例外を私にスパムで返します。

「スロー」チェックボックスを設定せずに修正するにはどうすればよいですか。

[編集]

わかりました、私は奇妙なものを見つけました。Debug -> Exceptions を変更した後、例外のある行で停止しました。しかし、Continue を押すと、ostream ファイルに移動します。VSデバッガーはデフォルトで「続行」を押しているようです。

[編集]

それが出力に表示されるものです。唯一の例外があります。例外が何らかの形で処理されたように見え、後で別の場所にスローされました。

c++ファイルをコンパイルしたい。私はチュートリアルに従っています。このチュートリアルでは、ファイルはVisual Studioでコンパイルされていますが、持っていません。g++でも同じことをしたいです。チュートリアルでは、VSの/GSおよび/SafeSEHを使用します。g++コンパイラでこれらのフラグを使用してファイルをコンパイルする方法を知りたいです。

質問が単純な場合は申し訳ありませんが、これまでg++を使用したことはありません。そして、私の英語でごめんなさい。ありがとうございました。

出力：

ScopedShit()

継続中...

私はこの記事http://www.codeproject.com/Articles/2126/How-aC-compiler-implements-exception-handlingを読んでいます。

しかし、それ (例外ハンドラー) が catch ブロックを呼び出す前に (funcinfo 構造体から catch ブロックのアドレスを認識しています。図 4 を参照)、スタックの巻き戻しを実行する必要があります。つまり、この関数のフレームの下にある関数のスタック フレームをクリーンアップします。スタック フレームのクリーニングには、ちょっとした複雑さが伴います。例外ハンドラーは、例外発生時にフレーム上でアクティブな関数のすべてのローカル オブジェクトを見つけて、それらのデストラクタを呼び出さなければなりません。

何か不足していますか？

私はインターネットからいくつかのコードを取得しました。これはSEHで例外を処理することになっています。

しかし、FS:[0]代わりにハンドラーのアドレスを保持する必要がありますか？

現在、オリジナルを指しているのでmov fs:[0], esp、間違っています：espfs:[0]

スタックは次のようになります。

だから、それはもののようにすべきではありませんesp + 4か？私は明らかに間違っていますが、理由はわかりません。

WindowProcコールバック内でエラーをキャッチすることは可能ですか? try/catch動作しません。__try __exceptまた、ハードウェア例外 ( など) も動作しAVません。

アップデート：

確かに、コールバックで例外をスローし、ブロックの外側WindowProcでキャッチすることが可能であることがわかりました。テスト済みで動作します。私は、WndProc で関連する質問64 ビット例外がサイレントに失敗することを発見しました。catchWindowProcWindows XP x86Windows 7 x64

それで、どうにかして例外をスローし、ブロックの外側WindowProcでキャッチすることは可能ですか? Microsoft ホットフィックスをインストールし、レジストリで 1 に設定しましたが、私の例外ではなく、最高の結果が得られました。catchWindowProcDisableUserModeCallbackFilterFATAL_USER_CALLBACK_EXCEPTION

The Crash Course といくつかの投稿を読んだ後、非常に基本的なバージョンを実装しました。私の唯一の要件は、例外を「キャッチ」し（スロー/発生させないため、「Win32」のみ）、それを発生させたスレッドを終了できることです。「ExitThread」を呼び出すだけの適切にプロトタイプ化された関数と、それをハンドラー プロパティに含む「EXCEPTION_REGISTRATION」構造体と、前のプロパティに実際の前のハンドルがあります。このハンドラーを設定するために私が行うことは、次の呼び出しです。

問題： 例外を引き起こしたとき（次のように言う：

set_my_handler を呼び出したのと同じスコープで、ハンドラーが期待どおりに呼び出されます。しかし、内部ブロックで同じ例外を発生させた場合、それを実行する関数を呼び出すと、機能しません。Unhandled Exception メッセージ ボックスが表示されます。デバッグ中に、内部関数で FS:[0] が同じ (ハンドラーを指している) ままであることに気付きました。ところで、私は何も使用していません（私のコードではtry/catchまたはtry/_except）

私はあなたの助けに感謝します、ありがとう。

私の問題に対する答え( Raymond Chenに感謝): スタック セグメント レジスタに対してその場所を検証するセキュリティ メカニズムがあるため、例外登録エンティティをスタックに割り当てる必要があることがわかりました。

私はSEHでいくつかの実験をしていました。私のコードでは、エラーの原因となるブロックを __try 句に記述し、ハンドラーを __except() に記述しました。

__except() の 2 番目のパラメーターは、次のいずれかです。

EXCEPTION_CONTINUE_SEARCH 例外は認識されません。最初に try-except ステートメントを含むハンドラー、次に優先順位の高いハンドラーのスタックを検索し続けます。

EXCEPTION_CONTINUE_EXECUTION 例外は認識されますが、無視されます。例外が発生した時点で実行を続行します。

EXCEPTION_EXECUTE_HANDLER 例外を認識しました。__except 複合ステートメントを実行して例外ハンドラーに制御を移し、例外が発生した時点で実行を継続します。

EXCEPTION_CONTINUE_EXECUTION/EXCEPTION_EXECUTE_HANDLER を使用すると、例外発生時点で実行が継続されません (例外発生時点の意味を誤解している可能性があります)。デバッグモードで実行すると、出力は

リリースモードで実行すると、出力は

なぜ動作が異なるのか理解できませんでした。誰でも助けてください。

失敗した場合に例外が発生するコードを単体テストする必要があります。簡単に言えば、スタック フレームをアンワインドするか、エラーをローカル ジャンプして、例外を処理する必要があります。MSVC の使用はオプションではありません。

AddVectoredExceptionHandlerのMSDN の例は、eip を変更してから EXCEPTION_CONTINUE_EXECUTION を返してローカル ジャンプを実行できることを示しています。明らかな問題は、どのアドレスにジャンプするかです。GCC のLabel as Value機能は、まさにそのように思われます。

以下の例は、エラーが発生した関数から単一の戻り値がある場合に機能します。ただし、2 番目の return ステートメントが追加されると、ジャンプのオフセットが疑わしいほど小さくなり、ジャンプは失敗します。なんで？

バックグラウンド スレッドで、アプリケーションは定期的にネットワーク フォルダー (UNC パス) を調べて、アプリケーションの更新を確認します。次のように、ファイルのアセンブリ バージョンを読み取ります。

このスニペットは非常に頻繁に実行されます。これまでのところ、複数の顧客サイトで 100.000 回以上実行されていると思いますが、問題はありません。

場合によってGetAssemblyNameはFileNotFoundException、ネットワーク フォルダに到達できない場合などに が発生します (これは発生する可能性があり、対処する必要があります)。この例外はCatchすぐ下のブロックによってキャッチされ、すべて正常に動作します。

ただし、報告された 3 つのケースでは、GetAssemblyName呼び出しでSEHException. 奇妙なことに、この例外はCatchすぐ下のブロックではなく、グローバルなハンドルされていない例外ハンドラー ( System.AppDomain.CurrentDomain.UnhandledException) によってキャッチされました。その結果、アプリケーションがクラッシュします。

例外の詳細は次のとおりです (残念ながら、例外のフィールドErrorCodeとCanResumeフィールドは、エラー処理ルーチンによってログに記録されません)。

Catchすぐ下のブロックで例外がキャッチされないのはなぜですか?

(これは関連している可能性があります。これは、UNC パスがローカル ネットワークの一部ではなく、VPN 上のリモート サーバーを指しているサーバーを指している顧客サイトでのみ発生しています。)