ある実稼働サイトで、アプリケーション(*)が繰り返しクラッシュしますが、再現性はありません。クラッシュ ダンプを分析すると、ヒープの破損であることが明確に示されます。クラッシュは別の場所にありますが、常にkernel32!HeapFree/内の違反にアクセスしますntdll!RtlpLowFragHeapFree。Win Dbg!analyze -vは、ヒープの破損も報告します。
これまで試したことは、アプリケーションをGFlagsオプションのPage Heapで実行することです。問題は、ページ ヒープのメモリ オーバーヘッドにより、アプリケーションが動作しなくなることです (32 ビット プロセスの仮想メモリ制限に達します)。
したがって、Page Heap は使用できません。他にどのフラグを追加すると便利でしょうか。
- 破損サイトでクラッシュする
- または、少なくとも、クラッシュしたときに最終的に生成されるクラッシュ ダンプからより多くの情報を取得できます
HeapFreeか?
現在、次のフラグを試しています。
次回のクラッシュ ダンプに何が問題なのかについての詳細情報が含まれることを期待しています。
これらのフラグを検討しましたが、今のところ省略しました。
- ヒープ パラメータ チェックを有効にします... ヒープ関数が呼び出されるたびにシステムがチェックする場合、かなりのオーバーヘッドが予想されます
- ヒープフリーチェックを有効にします...これが実際に何かを買うかどうかはわかりません
- 呼び出し時にヒープ検証を有効にします...ここでもドキュメントで高いオーバーヘッドが警告されます
私が (また) 抱えている問題の 1 つは、メモリ破損が発生したときにこれらのフラグがどのように役立つかがわからないことです。ガード ページに何かが書き込まれると、明らかにページ ヒープがアクセス違反を生成しますが、他のフラグはどのように機能するのでしょうか。
これらの他のフラグを有効にするには、Application Verifier を使用してアプリを実行する必要がありますか? または、チェック コードが何かを検出したときに例外が発生しますか?
これらのフラグのどの組み合わせが最も理にかなっており、本番環境でアプリケーションが適切なパフォーマンスとメモリ消費で実行できるようになりますか?
(*) : 産業オートメーション向けの 32 ビット Windows デスクトップ アプリケーションです。この場合、Win7 64 ビットで実行されます (他の多くのサイトでは問題なく実行されます)。