从崩溃转储中查找GDI /用户资源使用情况

Question

我有一个应用程序的崩溃转储,据说可能泄漏GDI.该应用程序在XP上运行,我可以将它加载到WinDbg中查看它.以前我们使用Gdikdx.dll扩展来查看Gdi信息,但XP或Vista不支持此扩展.

有没有人有任何指针在WinDbg中找到GDI对象使用.

或者,我可以访问失败的程序(及其压力测试套件),这样我就可以在运行的系统上重现,如果你知道XP和Vista的任何"实时"调试工具(或Windows 2000,虽然这不是我们的目标) .

Answer 1

我花了最后一周的时间研究GDI泄漏查找工具.我们还进行定期压力测试,由于用户/ gdi对象处理过度消耗,它永远不会持续超过一天的值.

据我所知,我的尝试非常成功.当然,我花了一些时间事先寻找替代和更快的解决方案.值得一提的是,我之前使用上面提到的msdn文章中的GDILeaks工具获得了一些半幸运经验.更不用说我必须在把它投入工作之前解决一些问题,这次它只是没有给我什么以及我想要它.他们的方法的缺点是重量级调试器接口(它减慢了我发现不可接受的数量级的研究目标).另一个缺点是它不能一直工作 - 在某些运行中我根本无法报告/计算任何东西!它的复杂性(根据代码量来判断)是另一个吓跑因素.我不是GUI的忠实粉丝,因为我相信我' 更高效,没有窗户; o).我也发现很难找到并使用我的符号.

在我开始编写自己的工具之前,我使用的另一个工具是leakbrowser.

无论如何,我最终决定采用迭代方法来实现以下目标:

• 轻微的性能处罚
• 实现简单
• 非侵入性(用于多种产品)
• 依靠尽可能多的可用

我使用了绕道(非商业用途)来实现核心功能(它是一个可注入的DLL).把Javascript用于自动代码生成(15K脚本到gen 100K源代码 - 我没办法手动编码,也没有涉及C预处理器!)加上一个windbg扩展,用于数据分析和快照/差异支持.

长话短说 - 在我完成之后,在另一次压力测试期间收集信息需要几个小时,而另一个小时则需要分析和修复泄漏.

我非常乐意与大家分享我的发现.

PS我花了一些时间试图改进以前的工作.我的意图是最大限度地减少误报(我在开发过程中看到过多的误报),因此它还会检查分配/释放的一致性,同时避免考虑从未泄露的分配.

编辑:在此处找到该工具

Answer 2

几年前有一篇MSDN 杂志文章谈到了 GDI 泄漏。这指向几个具有良好信息的不同地方。

在WinDbg中，您也可以尝试该!poolused命令来获取一些信息。

从崩溃转储（事后分析）中查找资源泄漏可能很困难 - 如果它总是在同一个地方，使用泄漏内存的同一个变量，而且你很幸运，你可以看到它最后出现的地方被泄漏等。在调试器下运行实时程序可能会容易得多。

您还可以尝试使用Microsoft Detours，但许可证并不总是有效。它也更具侵入性和先进性。