从故障转储中查找 GDI/用户资源使用情况
我有一个据称泄漏 GDI 的应用程序的故障转储。 该应用程序在 XP 上运行，我可以毫无问题地将其加载到 WinDbg 中查看。 之前我们使用Gdikdx.dll扩展来查看Gdi信息，但是XP 或 Vista 不支持此扩展。
有没有人有任何关于在 WinDbg 中查找 GDI 对象用法的指针。
或者，我确实可以访问失败的程序（及其压力测试套件），因此如果您知道任何适用于 XP 和 Vista（或 Windows 2000，尽管这不是我们的目标）的“实时”调试工具，我可以在正在运行的系统上进行重现。
I have a crash dump of an application that is supposedly leaking GDI. The app is running on XP and I have no problems loading it into WinDbg to look at it. Previously we have use the Gdikdx.dll extension to look at Gdi information but this extension is not supported on XP or Vista.
Does anyone have any pointers for finding GDI object usage in WinDbg.
Alternatively, I do have access to the failing program (and its stress testing suite) so I can reproduce on a running system if you know of any 'live' debugging tools for XP and Vista (or Windows 2000 though this is not our target).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
上周我一直在研究 GDI 泄漏查找工具。 我们还定期进行压力测试，并且由于用户/gdi 对象句柄过度消耗，它的持续时间从未超过一天的时间。
据我所知，我的尝试非常成功。 当然，我事先花了一些时间寻找替代且更快的解决方案。 值得一提的是，我以前有过使用上面提到的 msdn 文章中的 GDILeaks 工具的一些半幸运的经历。 更不用说在投入使用之前我必须解决一些问题，而这一次它并没有给我我想要的东西和方式。 他们的方法的缺点是重量级调试器接口（它使研究目标的速度减慢了几个数量级，我发现这是不可接受的）。 另一个缺点是它并非一直有效 - 在某些运行中我根本无法让它报告/计算任何内容！ 它的复杂性（根据代码量来判断）是另一个令人恐惧的因素。 我不太喜欢 GUI，因为我相信在没有 Windows 的情况下我的工作效率更高;o)。 我还发现很难让它找到并使用我的符号。
在开始编写自己的工具之前，我使用的另一个工具是 leakbrowser。
无论如何，我最终决定采用迭代方法来实现以下目标：
我对核心功能（它是可注入的 DLL）。 将 Javascript 用于自动代码生成（15K 脚本生成 100K 源代码 - 我不可能手动编码，也不涉及 C 预处理器！）加上用于数据分析和快照/差异支持的 Windbg 扩展。
长话短说——完成后，在另一次压力测试中收集信息只需要几个小时，再用一个小时来分析和修复泄漏。
我将非常乐意分享我的发现。
PS我花了一些时间来尝试改进之前的工作。 我的目的是最大限度地减少误报（我在开发过程中见过太多误报），因此它还将检查分配/释放一致性，并避免考虑从未泄漏的分配。
编辑：在此处找到该工具
I've spent the last week working on a GDI leak finder tool. We also perform regular stress testing and it never lasted longer than a day's worth w/o stopping due to user/gdi object handle overconsumption.
My attempts have been pretty successful as far as I can tell. Of course, I spent some time beforehand looking for an alternative and quicker solution. It is worth mentioning, I had some previous semi-lucky experience with the GDILeaks tool from msdn article mentioned above. Not to mention that i had to solve a few problems prior to putting it to work and this time it just didn't give me what and how i wanted it. The downside of their approach is the heavyweight debugger interface (it slows down the researched target by orders of magnitude which I found unacceptable). Another downside is that it did not work all the time - on some runs I simply could not get it to report/compute anything! Its complexity (judging by the amount of code) was another scare-away factor. I'm not a big fan of GUIs, as it is my belief that I'm more productive with no windows at all ;o). I also found it hard to make it find and use my symbols.
One more tool I used before setting on to write my own, was the leakbrowser.
Anyways, I finally settled on an iterative approach to achieve following goals:
I used detours (non-commercial use) for core functionality (it is an injectible DLL). Put Javascript to use for automatic code generation (15K script to gen 100K source code - no way I code this manually and no C preprocessor involved!) plus a windbg extension for data analysis and snapshot/diff support.
To tell the long story short - after I was finished, it was a matter of a few hours to collect information during another stress test and another hour to analyze and fix the leaks.
I'll be more than happy to share my findings.
P.S. some time did I spend on trying to improve on the previous work. My intention was minimizing false positives (I've seen just about too many of those while developing), so it will also check for allocation/release consistency as well as avoid taking into account allocations that are never leaked.
Edit: Find the tool here
我为此创建了一个 Windbg 脚本。 查看
命令的答案来获取故障转储中的 GDI 句柄计数
要跟踪分配堆栈，您可以在最后分配的 GDICell 对象之后设置一个 ba（访问中断）断点，以便在另一个 GDI 分配发生时中断。 这可能有点复杂，因为地址发生了变化，但它足以找到几乎任何泄漏。
I have created a Windbg script for that. Look at the answer of
Command to get GDI handle count from a crash dump
To track the allocation stack you could set a ba (Break on Access) breakpoint past the last allocated GDICell object to break just at the point when another GDI allocation happens. That could be a bit complex because the address changes but it could be enough to find pretty much any leak.
几年前有一篇 MSDN 杂志文章讨论了 GDI泄漏。 这指向几个具有良好信息的不同地方。
在 WinDbg 中，您还可以尝试使用
!poolused命令来获取一些信息。从崩溃转储（事后分析）中查找资源泄漏可能很困难 - 如果它总是在同一个地方，使用泄漏内存的同一个变量，而且你很幸运，你可以看到它最后出现的地方被泄漏等。在调试器下运行实时程序可能会容易得多。
您还可以尝试使用 Microsoft Detours，但许可证并不总是有效。 它也更具侵入性和先进性。
There was a MSDN Magazine article from several years ago that talked about GDI leaks. This points to several different places with good information.
In WinDbg, you may also try the
!poolusedcommand for some information.Finding resource leaks in from a crash dump (post-mortem) can be difficult -- if it was always the same place, using the same variable that leaks the memory, and you're lucky, you could see the last place that it will be leaked, etc. It would probably be much easier with a live program running under the debugger.
You can also try using Microsoft Detours, but the license doesn't always work out. It's also a bit more invasive and advanced.