问题:
是否有一种简单的方法来获取正在运行的应用程序中泄漏的资源类型的列表？通过连接到应用程序的IOW？
我知道memproof可以做到，但是它的速度非常慢，以至于应用程序甚至都不会持续一分钟。大多数任务管理员喜欢可以显示数字，但不能显示类型。
检查本身就是灾难性的(停止应用程序进程)，这不是问题，因为我可以通过taskmgr检查我是否接近(或者至少希望如此)
也欢迎任何其他有关资源泄漏搜寻的见解(而不是内存)。
背景:
我有一个Delphi 7/2006/2009应用程序(可以同时编译所有三个程序)，大约几个星期后，它开始表现得很有趣。但是，它只在其中一个运行的位置上运行，在其他几个系统上运行，直到断电为止。
我试图放入一些调试代码来缩小问题的范围。并发现文件保存中的异常(exception)是EOutofResources。 (文件保存一天可能发生数千次)。
我试图推断出内存泄漏(使用fastmm)，但是由于数据流非常高(千兆位工业相机的流量为60MByte/s)，我只能排除fastmm导致的“蠕动”内存泄漏，而不是快速耗尽内存的快速泄漏内存发生的时间。如果出现问题，该应用会在不到半分钟的时间内填充内存。
主要可疑对象是在某种程度上留在某些错误和TMetafiles(流式传输到这些文件)上的文件句柄。较小的可疑对象是VST，popupmenu和tframe
更新:
另一个可能的提示:D7可以运行两年，现在问题出在Turbo Explorer(我用于未转换为D2009的稳定项目)。
Paul-Jan:由于它每周只发生一次(并且可能在晚上发生)，因此信息获取速度很慢。这就是为什么我问这个问题，为什么我在星期四需要结合一些东西。简而言之:不，我不知道100％确定。我打算带整个Systemtools集合，看看是否可以找到某些东西(因为它将运行数天)。我还有机会看到打开的文件。 (也许应该尝试找到一些mingw lsof并安排它)
但是该应用程序只看到很少的GUI操作(这是一个机器视觉检查应用程序)，除了屏幕刷新+/- 15/s(这是tbitmap Stretchdraw + tmetafile)之外，但保存到磁盘(TFileStream)句柄时可能会收到此错误筋疲力尽的。但是，在同一流中，TMetafile也将保存到流中，这是后来的应用程序所没有的，并且可以几个月运行。
- - - - - - - - - - 更新
我进行了搜索，搜索和搜索，并设法在体外重现了两到三遍问题。当内存为+/- 256MB(系统有2GB)，用户对象200，gdi对象500，而不是一个比预期的文件打开度更高的文件时，就会发生问题。
这并不是真正的异常(exception)。我确实注意到我泄漏了少量的句柄，可能是由于重定了帧(VCL中的某些内容似乎泄漏了HPalette的原因)，但是我怀疑核心原因是另一个问题。我重用TMetafile，并在两者之间清除它。我认为清除图元文件并不会真正(总是吗？)调整资源大小，最终整个tmetafile池中的每个图元文件都将以最大大小显示，并且具有20-40个以上的tmetafile(每个文件可能有几百个ks)，这将在桌面上实现堆限制。
从理论上讲，但是我会尝试通过将客户的桌面限制设置为10MB来验证这一点，但是要确认这是否有任何变化，还需要几周的时间。该理论还证实了为什么该计算机是特殊的(平均而言，该计算机自然可能具有稍大的元文件)。偶尔释放和重新创建池中的tmetafile也可能有所帮助。
幸运的是，所有这些问题(tmetafile和reparenting)都已经在新一代应用程序中被设计出来了。
由于特殊情况(而且我的测试窗口非常有限)，这将需要一段时间，但是我决定暂时接受桌面堆作为示例(尽管GDILeaks的东西也很有用)。
审计发现的另一件事是，线程中使用了GDI类型(尽管仅将tmetafile(未使用或未连接的)保存到流中)。
-------------更新2。
增加桌面限制似乎只会稍微增加直到问题发生的时间。
不幸的是，由于机器已更新为没有问题的较新版本的框架，因此我将无法继续进行后续操作。
总而言之，我只能说明从旧框架到新框架的三个核心修改:
当然，也可能是其他事情，在重写上述部分时进行了更改，修复了一些非常讨厌的细节错误。这将是一个非常糟糕的系统，因为我尽可能地分析了上述系统。
在进行一些私有(private)邮件讨论后更新了2012年11月:回想起来，下一步是向图元文件对象添加一个计数器，并在每x * 1000次使用后简单地重新实例化它们，然后看是否有任何改变。如果您有类似的问题，请尝试查看是否可以一定程度地定期销毁并重新初始化动态分配的长期使用的资源。
最佳答案
如果它们是GDI handle 泄漏，则可以使用工具MSDN Magazine January 2003查看GDILeaks。其他工具是GDIObj或GDIView。另请参见here。
EOutOfResources的另一个来源可能是Desktop Heap已满。我在大屏幕的繁忙终端服务器上遇到了这个问题。
如果有很多文件句柄泄漏，您可以 checkout Process Explorer，查看进程的打开文件句柄，看看有什么异常。或通过!htrace命令使用WinDbg。
关于delphi - 寻找EOutOfResources，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2180345/