6

GDI をリークしていると思われるアプリケーションのクラッシュ ダンプがあります。アプリは XP で実行されており、WinDbg に読み込んで確認しても問題ありません。以前は、Gdikdx.dll 拡張機能を使用して Gdi情報を確認していましたが、この拡張機能は XP または Vista ではサポートされていません。

WinDbg で GDI オブジェクトの使用法を見つけるためのポインタはありますか。

または、失敗したプログラム (およびそのストレス テスト スイート) にアクセスできるので、XP および Vista (または Windows 2000 のターゲットではありません) 用の「ライブ」デバッグ ツールを知っていれば、実行中のシステムで再現できます。 .

4

3 に答える 3

5

私は先週、GDI リーク検出ツールの作業に費やしました。また、定期的なストレス テストも実施していますが、ユーザー/gdi オブジェクト ハンドルの過剰消費による停止なしで、1 日以上かかることはありませんでした。

私が知る限り、私の試みはかなり成功しています。もちろん、私は事前に時間をかけて、代替のより迅速な解決策を探しました。言及する価値があるのは、上記の msdn 記事の GDILeaks ツールを使用して、以前に半幸運な経験があったことです。言うまでもなく、それを機能させる前にいくつかの問題を解決する必要がありましたが、今回は、私が望んでいたものと方法が得られませんでした。彼らのアプローチの欠点は、デバッガーのインターフェースが重いことです (調査対象の速度が桁違いに低下するため、受け入れられませんでした)。もう 1 つの欠点は、常に機能しないことです。一部の実行では、何も報告/計算することができませんでした。その複雑さ (コードの量から判断すると) は、もう 1 つの恐るべき要因でした。私は GUI の大ファンではありません。m ウィンドウがまったくない方が生産性が高くなります ;o)。また、シンボルを見つけて使用するのが難しいこともわかりました。

自分で作成する前に使用したもう 1 つのツールは、leakbrowserです。

とにかく、最終的に次の目標を達成するための反復的なアプローチに落ち着きました。

  • 軽微なパフォーマンスのペナルティ
  • 実装のシンプルさ
  • 非侵襲性（複数の製品に使用）
  • 可能な限り利用可能なものに依存する

コア機能 (インジェクト可能な DLL) には回り道 (非営利目的) を使用しました。自動コード生成 (15K スクリプトから 100K ソース コードを生成するための Javascript を使用する - これを手動でコーディングする方法はなく、C プリプロセッサを使用する必要もありません!) に加えて、データ分析とスナップショット/差分サポートのための windbg 拡張機能を使用します。

簡単に言えば、作業を終えた後、別のストレス テストで情報を収集するのに数時間、リークを分析して修正するのにさらに 1 時間かかりました。

私の発見を喜んで共有します。

PS、以前の作品を改善するために時間を費やしました。私の意図は、誤検知を最小限に抑えることでした (開発中にあまりにも多くの誤検知を見てきました)。そのため、割り当て/解放の一貫性をチェックし、決してリークされない割り当てを考慮に入れることも避けます。

編集：ここでツールを見つけます

于 2008-10-17T19:33:13.697 に答える
4

数年前のMSDN Magazine の記事で、 GDI リークについて取り上げられていました。これは、良い情報を持ついくつかの異なる場所を示しています。

WinDbg では、!poolusedいくつかの情報についてコマンドを試すこともできます。

クラッシュ ダンプ (事後分析) からリソース リークを見つけるのは難しい場合があります。メモリ リークが発生した場所が常に同じで、同じ変数を使用している場合、運が良ければ、最後にリークする場所を確認できます。デバッガーの下で実行されているライブプログラムを使用すると、おそらくはるかに簡単になります。

Microsoft Detoursを使用することもできますが、ライセンスが常に機能するとは限りません。それはまた、もう少し侵襲的で高度です。

于 2008-09-19T18:05:33.030 に答える