调试问题时可能面临的一个常见任务是记录有关对一个或多个函数的调用的信息。如果你想知道你的程序中有一个你有源代码的函数，你可以添加一些调试打印和重建程序，有时这是不实际的。例如，您可能不总是能够重现一个问题，因此可能不可行的是，必须重新启动调试生成，因为您可能会吹走您的重现。或者，更重要的是，您可能需要记录对没有源代码的函数的调用（或者不作为程序的一部分构建，或者不想修改）。
例如，您可能希望记录对各种Windows api的调用，以便获得有关正在排除故障的问题的信息。现在，根据您正在做的工作，您可以在每次调用特定API之前和之后添加调试打印来完成这项工作。但是，这通常不太方便，如果您不是要记录的函数的直接调用方，那么无论如何，您都不能走这条路。
有许多API spy/API日志记录软件包（Windows发行版的调试工具甚至附带了一个名为Logger的软件包，尽管它往往相当脆弱——就我个人而言，我经常遇到它崩溃，而不是实际工作中遇到的问题）。尽管您可以使用其中的一个，但是“收缩包装”日志工具的一个很大的限制是，它们不知道如何正确地记录对自定义函数的调用，或者日志工具不知道的函数。更好的日志工具在一定程度上是用户可扩展的，因为它们通常提供某种脚本语言或编程语言，允许用户（即您）描述函数参数和调用约定，以便对它们进行日志记录。
但是，通常很难（甚至不可能）向这些工具描述许多类型的函数，例如包含指向包含指向其他结构的指针的结构的指针的函数，或其他此类不重要的结构。因此，在许多情况下，我倾向于建议不要在需要记录对函数的调用的情况下使用所谓的“收缩包装”API日志工具。

但是，如果在源代码中实现调试打印不是一个可行的解决方案，那么表面上看，这会使一个没有可用的解决方案来记录调用。事实上并非如此——事实证明，通过谨慎地使用所谓的“条件断点”，您可以经常使用调试器（例如WinDbg/ntsd/cdb/kd，这是本文其余部分将要提到的）来提供这种调用日志记录。使用调试器有许多优点；例如，您可以“动态”执行此类API日志记录，并且在可以在进程启动后附加调试器的情况下，您甚至不需要特别启动程序来记录它。然而，更好的是，调试器对以有意义的形式向用户显示数据有广泛的支持。
如果你仔细想想，向用户显示数据实际上是调试器的主要功能之一。这也是调试器通过扩展具有高度可扩展性的主要原因之一，这样复杂的数据结构就可以以有意义的方式显示和解释。通过使用调试器来执行API日志记录，您可以利用丰富的功能来显示已烘焙到调试器中的数据（及其扩展，甚至是您自己编写的任何自定义扩展），从而兼作调用日志记录功能。
更好的是，因为调试器可以基于符号文件（如果您有私有符号，例如您编译或提供的程序）以有意义的方式读取和显示许多数据类型，而这些数据类型没有用于显示它们的特定调试器扩展名（如！把手！错误（错误代码）！devobj和soforth），通常可以利用调试器基于符号中的类型信息格式化数据的能力。这通常是通过dt命令完成的，并且通常为大多数自定义数据类型提供一个可行的显示，而不必像处理日志程序那样进行任何复杂的“训练”。（某些数据结构（如树和列表）可能需要比dt中提供的更多的智能来显示数据结构的所有部分。对于“container”数据类型，这通常是正确的，尽管即使对于那些类型，您仍然可以经常使用dt以有意义的方式显示容器中的实际成员。）利用符号文件（通过调试器）中包含的信息进行API日志记录也使您不必确保日志记录程序对所有结构和其他类型的定义与您的程序同步正在调试，因为调试器自动接收基于符号的正确定义（如果使用的符号服务器包含自己内部符号的索引版本，调试器甚至可以自己找到符号）。

这种方法的另一个优点是，如果您对调试器相当熟悉，那么您可能不必像使用API日志程序那样学习新的描述语言。这是因为您可能已经熟悉了调试器从每天的调试器使用中为显示数据而提供的许多命令。（即使您对调试器不太熟悉，但默认情况下调试器附带的大量文档说明了如何通过各种调试器命令格式化和显示数据。此外，还有许多示例描述了如何在Internet上使用大多数重要或有用的调试器命令。）
好吧，关于为什么要考虑使用调试器来执行调用日志记录已经足够了。下一次，快速浏览并逐步介绍如何做到这一点（正如前面提到的那样，这非常简单），以及一些可能需要注意的注意事项和问题。

使用调试器执行调用日志记录并没有那么困难。所涉及的基本思想是在您感兴趣的函数的开头设置一个“条件”断点（例如，通过bp命令）。从那里，断点可以有显示输入参数的命令。但是，在某些情况下（例如，显示返回值、输出参数中的值等），您也可以变得更聪明一些，尽管根据正在调试的程序的特性，这可能是问题，也可能不是问题。
举一个简单的例子，我的意思是，有一个经典的“显示通过Win32 CreateFile打开的所有文件”。为此，方法是在kernel32!CreateFileW上设置一个断点。（请记住，大多数“A”win32api都会跳到“W”api，因此您通常可以仅在“W”版本上设置一个断点来同时获取这两个api。当然，这并不总是正确的（有些bizzare api，比如WinInet，实际上是从“W”到“A”的重击），但作为一般的经验法则，情况往往是这样的。）kernel32断点需要具备如何根据所讨论例程的调用约定显示第一个参数的知识。因为CreateFile是stdcall，所以应该是[esp+4]（对于x86）和rcx（对于x64）。

在最基本的情况下，breakpoint命令可能如下所示：

0:001> bp kernel32!CreateFileW "du poi(@esp+4) ; gc"

标签: none

添加新评论