调试打印机驱动程序中的资源泄漏
我正在尝试调试打印机驱动程序中的内存泄漏。我很确定这是资源泄漏，而不仅仅是普通的内存泄漏，因为在 Windbg 中使用 !heap -s 分析堆并没有显示任何增加。如何使用 Windbg 监视其他类型的对象？ GDI 对象和打开句柄的数量也没有增长，那么这可能是什么？
内存泄漏的症状是私有字节增长到 180Mb，然后打印开始遇到随机问题。
I'm trying to debug a memory leak in a printer driver. I'm pretty sure it's a resource leak, not just a plain memory leak because analyzing heap with !heap -s in windbg doesn't show any increase. How do I monitor other kinds of objects with windbg? Number of GDI objects and open handles is not growing either, so what could it be?
The symptom of memory leak is that private bytes are growing up to 180Mb and then printing starts experiencing random problems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它可以直接调用
VirtualAlloc。尝试使用!address -summary隔离内存类型。更好的是，从旧资源工具包中找到 vadump.exe 的副本。它提供了更具可读性的细分。通过比较两次运行 WinDbg 的
!vadump命令的输出，然后转储一些新分配的 RAM，您可能会得到一些线索。如果您有符号文件并使用 dps 命令转储 RAM，WinDbg 将显示每个 DWORD 的符号匹配。换句话说，如果某个值在符号文件中有名称，您就会看到它。一个很好的例子是使用 VTable 转储 C++ 对象。 VTable 有一个符号，因此您可以看到它是什么类型。最后但并非最不重要的一点是，您可以在 VirtualAlloc 上设置断点并转储每次调用的堆栈。即使没有对分配和释放进行严格比较，您也可能会注意到有趣的调用堆栈或分配大小。转储堆栈并继续的断点语法是
此外，在 VirtualAllocEx 上指定断点。 AFAIK，大多数进程启动的 VAD 分配应该会遇到断点，除了那些在内核中实现的分配，例如文件映射 (CreateFileMapping/MapViewOfFile) 以及 LoadLibrary。
It could be direct calls to
VirtualAlloc. Try to isolate the memory type using!address -summary. Better yet, find a copy of vadump.exe from an old resource kit. It gives a more readable breakdown.You might get some clues by diffing the output from two runs of WinDbg's
!vadumpcommand, and then dumping some of the newly allocated RAM. If you have symbol files and you dump RAM using thedpscommand, WinDbg will display symbol matches for each DWORD. In other words, if a value has a name in the symbol file, you'll see it. A nice example of that is when dumping C++ objects with VTables. The VTable has a symbol, so you'll see what type it is.Last but not least, you could set a breakpoint on
VirtualAllocand dump the stack for each call. Even absent a rigorous comparison between allocs and frees, you might notice an interesting call stack or allocation size. The breakpoint syntax to dump the stack and continue isIn addition, specify a breakpoint on VirtualAllocEx. AFAIK, most process-initiated VAD allocations should hit the break point, except those that are implemented in the kernel, such as file mappings (CreateFileMapping/MapViewOfFile) and maybe
LoadLibrary.