質問：
実行中のアプリケーションでリークするリソースの種類のリストを取得する簡単な方法はありますか？アプリケーションに接続してIOW？
memproofでそれができることは知っていますが、速度が非常に遅くなるため、アプリケーションは1分も持続しません。ほとんどのタスクマネージャーのいいねは番号を表示できますが、タイプは表示できません。
チェック自体が壊滅的である（アプリプロセスを停止する）ことは問題ではありません。近づいているかどうかをタスクマネージャーでチェックできるからです（または少なくとも私は願っています）
リソースリークハンティング（メモリではない）に関するその他の洞察も歓迎します。
バックグラウンド：
私はDelphi7/2006/2009アプリ（3つすべてでコンパイル）を持っていて、約数週間後におかしな動作を開始します。ただし、実行する場所の1つでのみ、他のいくつかのシステムでは、電源が切れるまで実行されます。
問題を絞り込むために、いくつかのデバッグコードを挿入しようとしました。そして、ファイルの保存時に例外がEOutofResourcesであることがわかりました。（ファイルの保存は1日に何千回も発生する可能性があります）。
私はメモリリークを（fastmmで）推論しようとしましたが、データフローが非常に高いため（ギガビット産業用カメラから60MByte / s）、fastmmでのみ「忍び寄る」メモリリークを除外できます。それが起こる頃の記憶。何か問題が発生した場合、アプリは30分以内にメモリをいっぱいにします。
主な容疑者は、何らかのエラーとTMetafiles（これらのファイルにストリーミングされる）に何らかの形で残されたファイルハンドルです。マイナーな容疑者はVST、popupmenu、tframesです
更新：
もう1つの考えられるヒント：D7では2年間正常に動作しましたが、現在問題はTurbo Explorer（D2009に変換されていない安定したプロジェクトに使用しています）にあります。
Paul-Jan：それは週に一度だけ起こるので（そしてそれは夜に起こる可能性があります）、情報の取得は遅いです。それが私がこの質問をする理由です、私が木曜日にそこにいるときのためにものを組み合わせる必要があります。要するに：いいえ、100％確実かどうかはわかりません。Systemtoolsコレクション全体を持ってきて、何かを見つけることができるかどうかを確認するつもりです（それから、それは数日間実行されるためです）。開いているファイルが表示される可能性もあります。（たぶん、いくつかのmingw lsofを見つけて、それをスケジュールする必要があります）
しかし、アプリはGUIアクションをほとんど認識しません（マシンビジョン検査アプリです）。ただし、画面の更新+/- 15/sはtbitmapstretchdraw+ tmetafileですが、ディスク（TFileStream）ハンドルに保存するときにこのエラーが発生する可能性があります。疲れ果てた。ただし、同じストリームで、TMetafileもsavetostreamedされます。これは、後のアプリにはもう存在しないものであり、数か月から実行できます。
- - - - - - - - - - アップデート
私は検索し、検索し、検索し、invitroで問題を2、3回再現することができました。問題は、memusageが+/- 256MB（システムには2GB）、ユーザーオブジェクト200、gdiオブジェクト500、予想よりも開いているファイルが1つではない場合に発生しました。
これは本当に例外ではありません。おそらくフレームの親を変更したために、少量のハンドルがリークしていることに気付きましたが（VCL内の何かがHPaletteをリークしているようです）、主な原因は別の問題であると思われます。TMetafileを再利用し、その間に.clearします。メタファイルをクリアしても、リソースのサイズは実際には（常に？）変更されないと思います。最終的には、tmetafileのプール全体の各メタファイルが最大サイズになります。20〜40以上のtmetafile（それぞれ数100ksになる可能性があります）を使用すると、デスクトップにヒットします。ヒープ制限。
それは理論ですが、お客様のデスクトップ制限を10MBに設定して確認しようと思いますが、変更がないか確認するまでに数週間かかります。この理論は、このマシンが特別である理由も確認しています（このマシンには、平均してわずかに大きいメタファイルがある可能性があります）。場合によっては、プール内のtmetafileを解放して再作成することも役立つ場合があります。
幸いなことに、これらすべての問題（tmetafileと親の変更の両方）は、新しい世代のアプリですでに設計されています。
特別な状況（およびテストウィンドウが非常に限られているという事実）のため、これはしばらくの間ですが、今のところ例としてデスクトップヒープを受け入れることにしました（GDILeaksのものも多少役に立ちましたが）。
監査でスレッドでのGDIタイプの使用が明らかになったもう1つのこと（ただし、（他の方法で使用または接続されていない）tmetafileのみをストリームに保存します。
-------------アップデート2。
デスクトップの制限を増やすと、問題が発生するまでの時間がわずかに増えるように見えました。
残念ながら、マシンが問題のない新しいバージョンのフレームワークに更新されたため、これについてこれ以上フォローアップすることはできません。
要約すると、古いフレームワークから新しいフレームワークへの3つの主要な変更が何であったかを述べることしかできません。
- フレームの親を変更して画面を変更することはなくなりました。現在、非表示にして表示するフォームを使用しています。これが原因で非常にまれなクラッシュや例外（クリックするとクリックされる可能性があります）も発生したため、これを変更しました。クラッシュはすべてGUIの操作中に発生しましたが、主な問題のように自発的に発生したわけではありません。
- クラッシュが発生したルーチンはTMetafileを処理しました。TMetafileは設計されており、より単純な独自の形式に置き換えられています。（基本的にOpengl頂点を持つ配列）
- 描画は、tmetafileオーバーレイstrechdrawedがその上にあるtbitmapでは発生しなくなりましたが、OpenGLを使用しています。
もちろん、上記の部分の書き直しで変更され、非常に厄介な詳細のバグを修正したものもあります。上記のシステムを可能な限り分析したので、それは非常に悪いものでなければなりません。
プライベートメールでの議論の後、 2012年11月に更新：振り返ってみると、次のステップはメタファイルオブジェクトにカウンターを追加し、x * 1000回程度使用するたびにそれらを再インスタンス化して、何かが変わるかどうかを確認することでした。同様の問題が発生した場合は、動的に割り当てられた長寿命のリソースを定期的に破棄して再初期化できるかどうかを確認してください。