2

組み込みの Windows XP ボックスで実行される DX9 アプリケーションがあります。浸漬テストのために一晩自動で放置すると、約 6 ～ 8 時間後にクラッシュします。私たちの開発で。マシン (Win 7) では、この問題を再現できないようです。また、メモリリークではないこともかなり確信しています。

  • 組み込みマシンで同じアプリケーションをデバッグで実行しても、クラッシュしません。
  • 組み込みマシンのメイン ループ更新の周りに配置する__try/__exceptと、クラッシュしません。

デバッグでは、ローカルスタックの周りに追加のバイトパディングがあり、ローカル配列へのアクセスが範囲外に「隠されている」か、初期化されていない変数が忍び寄っている可能性があります。

だから私は2つの質問があります：

  1. __try/__exceptリリースで実行した場合でも、デバッグと同様に動作しますか?
  2. デバッグ モードではなくリリース モードでクラッシュが発生した場合、どのようなコードをスキャンする必要がありますか?
4

2 に答える 2

3

使用している場合は、使用し__try{ } __except()ないでください。
それらと C++ コードはうまく混ざりません。(たとえば、関数のスタックに C++ オブジェクトをラップすることはできません。 (省略記号try {} catch() {}を使用して) C++ を使用する場合は、C++ を使用する必要があります。catch(...)基本的には、__except()

両方ともtry.. catch、__try .. __exceptデバッグとリリースで同じように動作します。

問題が予期しない例外であると思われる場合は、次のすべてについて読む必要があります。

SetUnhandledExceptionFilter()
_set_se_translator()

_CrtSetReportMode()
_RTC_SetErrorFunc()
_set_abort_behavior()
_set_error_mode()
_set_new_handler()
_set_new_mode()
_set_purecall_handler()
set_terminate()
set_unexpected()
_set_invalid_parameter_handler()
_controlfp()

最初の 2 つのいずれかを使用すると、問題をかなり迅速に特定できる可能性があります。プロセスで発生する可能性のあるすべてのエラーケースを完全に制御したい場合は、残りがあります。

具体的にはSetUnhandledExceptionFilter()、例外の原因となったコードのアドレスをログに記録する関数フィルターを設定できます。その後、デバッガーを使用してそのコードを特定できます。DbgHelp ライブラリを使用し、フィルター関数に与えられた情報を使用して、シンボルや行番号を含むクラッシュの完全なスタック トレースを出力するコードを記述できます。

リリース ビルドのデバッグ シンボルも出力するようにビルド構成を設定してください。それらはアプリケーションを遅くするのを助けるだけで、何もしません (ただし、アプリケーションを大きくする可能性があります)。

于 2012-05-21T21:37:09.280 に答える
0

__try組み込みマシンのメイン ループ更新の前後に/を配置する__exceptと、クラッシュしません。

次に、それを行います。

プログラム全体 (および各ワーカー スレッドのエントリ ポイント) を1 つの__tryブロックで囲むことをお勧めします。これにより、終了する前にクラッシュ ダンプを書き出し、エラー レポートを作成できます。さまざまな障害を有効に区別するのに十分な情報が例外に含まれていないため、SEH で実行できる回復はあまりありません。ただし、プログラム全体の状態を保存してデバッガーにプルすることは非常に便利です。

注: 一部のビデオ ドライバーは、キャッチする SEH 例外を引き起こします。おそらく、一部のロジックは、__tryブロックが提供する複数の SEH スコープがインストールされていることを想定しています。

于 2012-05-21T21:44:47.187 に答える