我想做的是在我指定的模块调用的nt中的所有函数上设置一个条件断点。
我这样做的目标是在每次 X 模块调用 x nt 函数时编写调用堆栈，从而能够“映射”出混淆代码内部发生的事情。
在入口点中断后，我在 x nt 函数上设置了一个断点。恢复我的断点后，调用堆栈看起来像
nt!函数
moduleIspecified!0x123
....
那时我的想法是，我可以使用它为条件断点编写代码，例如：“IF caller is x module, and module is calling function inside y module THEN log callstack. ”。
值得注意的是，x64 内核模式不支持 watch 和 trace。 还值得一提的是，我决定使用这种方法，因为我无法通过静态分析来确定调用，也无法通过步进分析来确定调用。
另外：是否有更好/理想的方法来实现这一目标？
问候
【问题讨论】：
标签： kernel conditional windbg breakpoints callstack
您无法精确地做到这一点，但您可以考虑一些替代方案。
首先 - 为什么不简单地使用Sysinternals' Process Monitor 或者Rohitab's API Monitor？
如果你一心想自己做，你面临的第一个问题是内核调试器可以设置的断点数量有限（32 是我记得的最后一个数字）。此限制不是由于主机 WinDbg/kd，而是由于目标计算机中的内核调试器组件。您可以在 WRK 中看到这一点。但即使你可以，它也会非常缓慢。
您的第一个选择是在syscall/sysenter 例程（nt!KiFastCallEntry、nt!KisystemCall64 或今天的任何内容）中设置一个断点，然后将您的命令放在那里。正如我所说，它会非常缓慢。不信也欢迎你自己试一试（即使没有聪明的条件，随便放一个命令，哪怕只是一个简单的gc，更不用说.echo...）。
我能想到的第二种选择是编写一个驱动程序来挂钩您感兴趣的系统调用（或syscall 例程）。这可以节省主机和目标机器之间的往返时间。请注意，您仍然需要附加调试器来禁用 KPP (PatchGuard) 或使用 32 位机器。而且它可能比使用 ProcMon、API Monitor 或 xperf/WPT 更复杂。
我建议在使用过于复杂的东西之前使用简单明了的东西（ProcMon/API Monitor）。
【讨论】：