我有一个应用程序的故障转储，据说该应用程序正在泄漏 GDI。该应用程序在 XP 上运行，我可以毫无问题地将其加载到 WinDbg 中查看它。以前我们使用Gdikdx.dll 扩展来查看 Gdi 信息，但 XP 或 Vista 不支持此扩展。
有没有人有任何指针可以在 WinDbg 中查找 GDI 对象的使用情况。
或者，我确实可以访问失败的程序（及其压力测试套件），因此如果您知道 XP 和 Vista（或 Windows 2000，尽管这不是我们的目标）的任何“实时”调试工具，我可以在正在运行的系统上重现.
上周我一直在研究 GDI 泄漏查找工具。我们还执行定期压力测试，并且由于用户/gdi 对象句柄过度消耗，它的持续时间永远不会超过一天的价值。
据我所知，我的尝试非常成功。当然，我事先花了一些时间寻找另一种更快的解决方案。值得一提的是，我之前在上面提到的 msdn 文章中对 GDILeaks 工具有过一些半幸运的经验。更不用说在投入使用之前我必须解决一些问题，而这一次它只是没有给我想要的东西和方式。他们的方法的缺点是重量级的调试器接口（它使研究目标减慢了几个数量级，我认为这是不可接受的）。另一个缺点是它并非一直有效 - 在某些运行中，我根本无法让它报告/计算任何东西！它的复杂性（从代码量来看）是另一个吓人的因素。我不是 GUI 的忠实粉丝，因为我相信我 完全没有窗户的情况下，我的工作效率更高；o)。我还发现很难让它找到并使用我的符号。
在开始编写自己的工具之前，我还使用了另一种工具，即泄漏浏览器。
无论如何，我最终确定了一种迭代方法来实现以下目标：
我为核心功能（它是一个可注入的 DLL）使用了 detours（非商业用途）。将 Javascript 用于自动代码生成（15K 脚本生成 100K 源代码 - 我无法手动编写代码，也不涉及 C 预处理器！）加上用于数据分析和快照/差异支持的 windbg 扩展。
长话短说——在我完成之后，在另一个压力测试期间收集信息只需要几个小时，而分析和修复泄漏则需要另外一个小时。
我很乐意分享我的发现。
PS我花了一些时间来尝试改进以前的工作。我的意图是尽量减少误报（我在开发过程中看到的误报太多了），因此它还将检查分配/释放的一致性，并避免考虑从未泄露的分配。
编辑：在这里找到工具
几年前有一篇MSDN 杂志文章谈到了 GDI 泄漏。这指向了几个具有良好信息的不同地方。
在 WinDbg 中，您也可以尝试该!poolused命令以获取一些信息。
从崩溃转储（事后分析）中查找资源泄漏可能很困难——如果它总是在同一个地方，使用泄漏内存的同一个变量，而且你很幸运，你可以看到它会出现的最后一个地方被泄露等等。使用在调试器下运行的实时程序可能会容易得多。
您也可以尝试使用Microsoft Detours，但许可证并不总是有效。它也更具侵入性和先进性。
我为此创建了一个 Windbg 脚本。看答案
要跟踪分配堆栈，您可以在最后分配的 GDICell 对象之后设置一个 ba（访问中断）断点，以便在另一个 GDI 分配发生时中断。这可能有点复杂，因为地址发生了变化，但它可能足以找到几乎任何泄漏。