定制调试诊断工具和实用程序(6)

核心提示： 防止泄漏文档中关于 Win32 调试 API 的另一方面的描述是必须释放不同的 XXX_DEBUG_EVENT 结构返回的句柄，Matt Pietrek 在其 November 1995 MSJ“Under the Hood”专栏文章中指出：在 XXX_DEBUG_

防止泄漏

文档中关于 Win32 调试 API 的另一方面的描述是必须释放不同的 XXX_DEBUG_EVENT 结构返回的句柄。Matt Pietrek 在其 November 1995 MSJ“Under the Hood”专栏文章中指出：在 XXX_DEBUG_EVENT 结构中返回到调试器的句柄应该被关闭。事实上，几乎每个句柄都必须用 CloseHandle 关闭。只有一个例外，就是存储在 CREATE_THREAD_DEBUG_EVENT 中的线程句柄，它应该在进程终止时由系统来关闭。其它的句柄如果不关闭，便会造成增长速度非常快的系统资源泄漏，有关的句柄如 Figure 7 所示。这类垃圾的收集由 CApplicationDebugger::HandleDebugEvent 自动处理。

不论你使用哪种清除方法，每次你调试某个进程时，系统不可避免地要泄漏两个句柄：信号机（semaphore ）和端口（port），两者都没有命名。为了让你确信 CApplicationDebugger 不负责处理这种泄漏，请允许我指出：用 sysinternals 的 ProcessExplorer 或 Windows Resource Kit 中的 DH.EXE 可以观察到 Visual Studio 6.0 和 Visual Studio .NET 中同样的泄漏行为。

现在你已经看到了如何用 Win32 调试 API 来获取某个进程执行期间在其地址空间中加载和卸载的 DLLs 确切列表。Windows 本身提供了另外一个途径来获取有关 DLLs 的其它详细信息。

参考资料

The Win32 Debugging Application Programming Interface；

Bugslayer: Windows 2000 and LDR Messages, A COM Symbol Engine, Finding Bloated Functions, and More DEB Sample: Debug Event Browser；

Spawn Console Processes with Redirected Standard Handles；

GetWindowModuleFileName & GetModuleFileName Work Only with the Calling Process

在后续文章中，我将介绍 Windows Loader，它知道一切。

（待续）