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

Question

我有一个应用程序的崩溃转储，据说可能会泄漏GDI。该应用程序在XP上运行，我可以将它加载到WinDbg中查看它。以前我们使用Gdikdx.dll extension来查看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扩展，用于数据分析和快照/差异支持。

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

我非常乐意分享我的发现。

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

修改：找到工具here

Answer 2

有一个MSDN Magazine article from several years ago谈到了GDI漏洞。这指向了几个具有良好信息的不同地方。

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

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

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

Answer 3

我为此创建了一个Windbg脚本。看看

的答案

Command to get GDI handle count from a crash dump

要跟踪分配堆栈，您可以设置一个ba（Break on Access）断点，超过最后分配的GDICell对象，以便在发生另一个GDI分配时突破。这可能有点复杂，因为地址发生了变化，但它足以找到任何泄漏。