問題タブ [seh]

この記事では、構造化された例外処理がよくない理由について概要を説明しています。この記事で言及されている問題を回避しながら、サーバーのクラッシュを防ぐ堅牢性を確保する方法はありますか?

約 400 人の接続ユーザーを同時に実行するサーバー ソフトウェアがあります。しかし、クラッシュが発生した場合、400 人のユーザー全員が影響を受けます。構造化された例外処理を追加し、しばらくは結果を楽しみましたが、サーバー全体がハングするクラッシュが発生したため、最終的に削除する必要がありました (クラッシュして再起動するよりも悪いことです)。

だから私たちはこれを持っています：

• SEH の場合: ほとんどのクラッシュで問題が発生するのは 400 人中 1 人のユーザーのみ
• SEH を使用しない場合: いずれかのユーザーがクラッシュすると、400 人全員が影響を受けます。
• ただし、SEH を使用すると、サーバーがハングすることがあります。400 人すべてが影響を受け、将来接続を試みるユーザーが影響を受けます。

関数内の戻りコードと変数に応じて、関数を終了する前に usererror 文字列を設定したいと考えています。

私は現在持っています：

return RetType.FailedParse を使用して、finally ブロックでこれにアクセスすることは可能ですか?

この質問は、ここで説明されている問題をより明確にします。さらに調査を行ったところ、次のコードではスタックの巻き戻しが行われていないことがわかりました。

VC6 SP5 コンパイラを使用してこのコードをコンパイルしたところ、出力は "Wrapper constructor :: AddRef!!!" です。(つまり、スタック上に構築されたラッパー オブジェクトのデストラクタが呼び出されません。これは予想される動作ですか?それとも VC コンパイラのバグですか?この場合、スタックの巻き戻しが発生するようにコンパイラ フラグを使用できますか?

ポインターのアクセシビリティの検証に関する質問を投稿しました。結論は、IsBadReadPtr を使用してポインターをチェックするか、SEH を使用して例外をキャッチすることでした (どちらも使用せずにアプリケーションをデバッグすることが望ましいですが、それはここでは問題ではありません)。

IsBadReadPtr は、他の理由の中でも特に、ポインターを読み取ろうとし、例外をキャッチするため、悪いと言われています。スタック ガード ページの例外をキャッチする可能性があり、スタックを拡大する必要があるメモリ マネージャーに到達できなくなります。

SEH を使用して EXCEPTION_ACCESS_VIOLATION 例外のみをキャッチすると、同じ問題が発生しますか?

別のこと: SEH を使用することの意味は何ですか? この記事では、「コンパイラは SEH で保護されたコードでフロー解析を実行できない」ことを示唆しています。__try ブロック内で関数を呼び出すとどうなりますか。コンパイラは呼び出された関数をまったく最適化しませんか?

SEH を損なうことなく、Win32 の「1 つの大きなスタック」モデルから逃れる方法はありますか? コルーチンを実装する方法として、スタック フレームをヒープに割り当てられるようにしたいと考えています。ただし、私のコードは現在 SEH に依存しており、数ページ下のこの記事には、次のように記載されています (例外ハンドラーのトラバーサル、スキャン、強調鉱山に関連):

OS は、このチェーン トラバーサル中のスタックの破損に対してかなり偏執的です。すべてのチェーン エントリがスタックの境界内にあることを確認します。(これらの境界は TEB にも記録されます)。OS は、すべてのエントリがスタック上で昇順であることも確認します。これらの規則に違反すると、OS はスタックが破損していると見なし、例外を処理できなくなります。これは、Win32 アプリケーションが、スタック オーバーフローを処理するための革新的な手法としてスタックを複数のばらばらなセグメントに分割できない理由の 1 つです。

したがって、基本的に、現在のスタック フレームが「1 つの大きなスタック」の外にあるときに例外が発生すると、プロセスは即座に終了します。理想的な行動ではありません。

この問題を回避し、ネイティブの Win32 アプリでばらばらのスタックを使用して SEH を利用できた人はいますか? また、他の Win32 固有の「落とし穴」でスタックがばらばらになっているものはありますか?

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

次のコードを Windows 7 32 ビットで実行すると、ハード フェイルが発生します。

ただし、これを Windows 7 64 ビットで試すと、出力ウィンドウに次のように表示されます。

Test.exe の 0x13929384 での初回例外: 0xC0000005: アクセス違反の書き込み場所 0x00000000。
Test.exe の 0x77c6ee42 での初回例外: 0xC0150010: 非アクティブ化されているアクティブ化コンテキストは、現在の実行スレッドに対してアクティブではありません。

これの理由は何ですか？ハードウェアの例外 ( http://msdn.microsoft.com/en-us/library/aa363082.aspx ) であることはわかっていますが、32 ビットと 64 ビットで実行したときの違いはなぜですか? この種のエラーを正しく処理するにはどうすればよいでしょうか? Windows がアプリケーションにメッセージを送り続けて実行するという現在の状況とは対照的に、それらは実際にトラップして修正する必要があるためです (したがって、ユーザーと開発者は問題が実際に発生したことにまったく気づきません)。

更新: 通常のクラッシュ レポート ソフトウェアは使用しますSetUnhandledExceptionFilterが、WndProc 内のハードウェア例外に対して x64 で呼び出されません。誰かがこれに関する情報、または回避策を持っていますか?

Update2: Microsoft Connect で問題を報告しました:
https://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-メッセージ

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

私はウィンドウズSEHについてもっと学ぼうとしています。私の最初のテストプログラムは私にいくつかの本当の問題を与えています。私はmsdnのドキュメントを見ましたが、何が間違っているのかまだよくわかりません。このプログラムをコンパイルしようとすると、次のエラーが発生します。

両方とも15行目。

ありがとう。

try-catchこれは主に好奇心ですが、C++構造でSEH例外をキャッチするVisualStudioの歴史について読んでいます。/GXフラグが有効になっている古いバージョンのVisualStudioは、C++catchブロックで構造化されたWin32例外を「時々」キャッチするという主張に出くわし続けています。

/ GXフラグを使用してビルドした場合、Visual Studio 6.0はどのような状況で次のコードのcatchブロックに入りますか？

Visual Studio 6 + SP6を使用した私自身の簡単なテストでは、プログラムの実行は手に負えない例外で停止し、「Incatch」が出力されることはありません。しかし、いくつかの記事（このcatchようなもの）は、ブロックに入ることが可能であると私に信じさせます。