問題タブ [seh]

しぶしぶ、Win32 構造化例外を再び処理する必要があります。例外を説明する文字列を生成しようとしています。そのほとんどは簡単ですが、基本的なことに行き詰まっています: 例外コード ( の結果GetExceptionCode()、または のExceptionCodeメンバーEXCEPTION_RECORD) を例外を説明する文字列に変換するにはどうすればよいでしょうか?

たとえば、0xC0000005 を「アクセス違反」に変換するものを探しています。への呼び出しだけFormatMessage()ですか？

以下を実行するコードを実行時に生成する必要があります。

または同等の C:

cleanup() 関数は例外がないことが保証されていますが、 do_some_danger_thing() は例外をスローする場合があります。このランタイム コードはスタックを使用してはなりません。つまり、do_some_danger_thing() を呼び出すとき、ランタイム コードに設定された戻りアドレスを除いて、スタックはランタイム コードに入るときと同じ状態でなければなりません (元の値は "jmp に保存されました)。 " ターゲット、呼び出し元に戻るため)。

動的マシン コードを使用しているため、ターゲット プラットフォームは x86 CPU 上の WIN32 に固定されており、x64 CPU は現在注目されていません。

これを行うには、例外を処理する必要があります。WIN32 では、C++ 例外は SEH ベースであるため、それに対応する必要があります。問題は、これを行う方法を見つけられず、他のコードと互換性がないことです。いくつかの解決策を試しましたが、どれも機能しません。ユーザーがインストールした例外ハンドラーが呼び出されなかったり、外部の例外ハンドラーがバイパスされたりして、「ハンドルされていない例外」エラーが発生することもありました。

アップデート：

SEH 例外ハンドラ チェーンが EXE イメージ内のコードのみをサポートしているようです。例外ハンドラーが生成されたコードを指している場合、それは決して呼び出されません。私がしなければならないことは、静的例外ハンドラー関数スタブを作成し、生成されたハンドラーを呼び出させることです。

サードパーティのライブラリを使用して 1 つの単純なタスク (ラスタライズ) を実行する小さなユーティリティ (VC 2010、clr なし) を作成しています。後のユーティリティは、より大きなアプリケーションで使用されます。サード パーティ製ライブラリのヒープ破損が原因で、ユーティリティがクラッシュすることがあります。それは問題ありませんが、Windows (Vista/2008) では、「プログラムが動作を停止しました... プログラムを閉じる/デバッグする」というよく知られたダイアログが表示されます。私の場合（サーバー側）には適切ではありません。ユーティリティは、目に見える影響を与えることなく、静かにクラッシュ/終了する必要があります。

そのために、未処理の例外 (SetUnhandledExceptionFilter) 用に SEH をインストールしました。ハンドラーは、AV ( *(PDWORD)0 = 0 ) のような例外に対して完全に呼び出されますが、何らかの理由で、ヒープ破損の場合には呼び出されません。アンロード中に、サード パーティ製ライブラリ dll の 1 つの dllmain で破損が発生します。

いくつか質問があります。ハンドラーが呼び出されない理由を誰か説明できますか? そのダイアログを防ぐ別の方法はありますか?

結果を（の古いバージョン）に__CxxFrameHandler3委任できる実装を提供するために名前が付けられたVisual C ++2008SEHハンドラーをリバースエンジニアリングしようとしています。__CxxFrameHandlermsvcrt.dll

（このページとこのページmsvcrt.dllには、SEHに関する詳細が記載されています。）

注： msvcrt_winxp.obj（32ビット）とmsvcrt_win2003.obj（64ビット）はすでに同じことを行っています。これらはWindows DriverKit7.1の一部です。ただし、それらは他の多くのコードにもバンドルされているため、リンカーが台無しになります。

私は32ビットバージョン（msvcrt_winxp.obj）の逆アセンブル、抽出__CxxFrameHandler3、および適切な実装を提供する代替案の作成に成功しました。

ただし、64ビットバージョン（msvcrt_win2003.obj）で問題が発生しました。

私の64ビット実装はまったく同じように見えますが、機能しません。ただし、Microsoftが提供する実装は実際に機能します。

これは32ビットバージョンです（正しく動作します）：

これは（問題のある）64ビットバージョンです。

Microsoftの実装（DumpBinonで抽出lib\wnet\amd64\msvcrt_win2003.obj）は次のとおりです。

両方の形式をデバッグしようとすると、という行に到達するとすぐにpush r12、Visual Studioの呼び出しスタックが私のバージョンで混乱します（無効なアドレスを指す表面的なエントリがスタックフレームの間にポップアップします）が、 Microsoftのバージョンでも同じです。

実際、実行の続行を許可すると、プログラムは私のバージョンでは内部でクラッシュ__CxxFrameHandlerしますが、Microsoftのバージョンでは完全に正常に動作します。

私が両方のソースをテストしているプログラムは次のとおりです。

適切なコンパイラフラグ（/MD /GS- /Od）を使用します。

したがって、私は理解できません：

提供された実装とまったく同じであると思われる私のコードが、の内部でアクセス違反を引き起こすmsvcrtのは__CxxFrameHandlerなぜですか？

プログラムのbase64エンコーディングがここにあるので、生成された実際のバイナリを確認できます。

私の悪いバージョン：

Microsoftのバージョン：

編集：

好奇心旺盛な人のために、レイモンドのリンクのおかげで解決策を見つけました。

交換する必要があることが判明しました

と

__tryWindows 用の C コードをプログラミングするとき、SEH の...ブロックを使用するように「デフォルト」する__finally必要がありますか?

言い換えれば、以下のどれが (たとえば) より良いプラクティスと見なされますか? また、その理由は何ですか?

対

明確化

私は言及するのを忘れました：

My idea behind this was that, if someone inserts more code later into the block (e.g. an early return from the function), my code would still perform the cleanup, rather than exiting prematurely. So it was supposed to be more preventive than anything else. Should I still avoid using SEH anyway?

私はネイティブファイバー/コルーチンの実装に取り​​組んでいます–かなり標準的で、ファイバーごとに個別のスタックが割り当てられ、コンテキストを切り替えるために、レジスタがソースコンテキストスタックにプッシュされ、ターゲットスタックからポップされます。それはうまく機能しますが、今私は少し問題にぶつかりました：

ファイバー内で動作するSEHが必要です（プログラムが終了したり、ファイバーの最後のスタックフレームまで例外が処理されないときに奇妙なことが起こり始めても問題ありません）。FS:[0]コンテキストスイッチ中に（FS:[4]および、明らかに）保存/復元しFS:[8]、最初にFS：[0]をに設定します（コンテキスト0xFFFFFFFFスイッチの後に設定された例外ハンドラーがチェーンのルートになるように）。

正確には、テストしたすべての非サーバーWindows OSで動作します。問題は、Windows Server2008および2008R2で例外チェーン検証（SEHOP、SEH上書き保護）機能がデフォルトで有効になっていることです。これによりRaiseException、元のハンドラーがチェックされます。 （ntdll.dllのどこかに）はまだチェーンのルートであり、ハンドラーがインストールされていないかのようにプログラムをすぐに終了します。

したがって、検証コードを満足させるために、スタック上に適切なルートフレームを構築するという問題に直面しています。それを行うために呼び出すことができる（隠された？）API関数はありますか、それともRtlDispatchException友人を幸せに保つために何が必要かを理解し、適切な_EXCEPTION_REGISTRATIONエントリを自分で作成する必要がありますか？間違ったアドレスにあるため、作成スレッドからWindows提供のものを再利用することはできません（SEH実装は、ハンドラーアドレスがとで指定された境界内にあるかどうか、場合によってはアドレスの順序が一貫しているかどうかもチェックしFS:[4]ますFS:[8]） ）。

ああ、私はWinAPIファミリーの関数に頼らないことを強く望んでいます。CreateFiber

Visual C++ ランタイムによって x64 で C++ 例外処理がどのように実装されているかを理解しようとしています。

http://www.nynaeve.net/?p=110にあるx64 での SEH 実装に関する Nynaeve ブログを読むと、RtlUnwindExは、フレーム統合アンワインドのために ExceptionCode を STATUS_UNWIND_CONSOLIDATE に設定して RtlRestoreContext を呼び出しているようです。

私には完全に明確ではないのは、RtlRestoreContext が次に何をするかということです。MSDN はhttp://msdn.microsoft.com/en-us/site/ms680605で次のように述べています。「RtlRestoreContext は、コールバック関数を呼び出す前に、そのフレームとコンテキスト レコードで指定されたフレームとの間の呼び出しフレームを統合します。これにより、例外からフレームが隠されます。コールバック関数で発生する可能性のある処理。」

「そのフレームとコンテキスト レコードで指定されたフレームとの間の呼び出しフレームを統合する」とはどういう意味ですか? これはどのように「コールバック関数で発生する可能性のある例外処理からフレームを隠す」のですか? 「フレーム統合」とは何を意味し、フレームが統合されている正確な場所はどこですか?

C++ キャッチ ハンドラーが RtlRestoreContext によって呼び出され、別の例外がスローされたとします。その (再) スローされた例外は、ある種の SEH ブロックによって保護されていますか? または、このフレーム統合ビジネスは何とかそれを処理しますか? はいの場合、どのように？

Olly Debugger でプログラムをデバッグしています。次のように実行中に例外ハンドラをインストールします。

したがって、アドレス 004010a9 にある例外ハンドラがインストールされます。

次の命令は、次に示すようにメモリ アクセス違反をトリガーします。

コードにはコード セクションへの書き込み権限がないため、メモリ アクセス違反が発生して停止します。

ここで、Shift + F9 キーを押して例外をプログラムに渡すオプションがあります。

ただし、押しても何も起こらず、プログラムは一時停止状態のままです。

この時点での私の SEH チェーンは次のようになります。

Olly Debugger のデバッグ オプションは、次のように設定されています。

[例外] タブで、次のオプションのみをオンにしました。

Kernel32 のメモリ アクセス違反を無視する

Shift + F9 を押したときに、プログラムが 004010a9 にある例外ハンドラーに例外を渡さない理由を理解できません。これは現在のスレッドの例外ハンドラーであるためです。

ありがとう。

サードパーティのCOMオブジェクトの例外から自分のC++コード（Windows x86）を保護し、次のSEH擬似コードを使用してそれらの例外をログに記録しています。

このアプローチは、SEHコードが存在しない場合に処理される例外をキャッチする可能性がありますか？

以下のMSDNの記事では、デフォルトの未処理の例外フィルターが、ロードされたリソースのメモリにコードが書き込まれるケースをキャッチして修正すると述べています。SEHを使用すると、望ましいデフォルトのOSの動作が妨げられる他のケースはありますか？

Win32™構造化例外処理の深さに関するクラッシュコース

私のプロジェクトは突然機能しなくなりました。ローカルストレージを使用していますが、ロール環境を初期化しようとすると、次のように表示されます。

"Microsoft.WindowsAzure.ServiceRuntimeエラー：102：ロール環境。初期化に失敗しました"

エラーコード「-2147467259」でSEH例外が発生します。プロジェクトのクラウド部分の新しいインスタンスを開始してから、同じソリューションでWPFアプリケーションの新しいインスタンスを開始しようとします。WPFアプリケーションを実行すると、クラウドインスタンスの展開が停止すると思います。しかし、私にはわかりません。