前言

在前面文章中（这里）总结了使用 windbg 和 IDA 找出 cvtres.exe 报错的根本原因，并把一些细节问题弄清楚了。但是还剩下一个小细节没有深究 —— 如果启动 cvtres.exe 的时候没有指定全路径，windbg 会报系统找不到指定的文件的错误。当时只是根据经验判断需要使用完整路径，但是为什么只使用文件名不行呢？今天就把这个问题也格尽。

说明： 写完本文，我犹豫了很久要不要发表出来。因为这个问题其实很简单（在设置 PATH 环境变量时，路径多加了双引号）。但是当时的我真的是当局者迷，完全没意识到这个问题，导致花费了很长时间。process monitor，gflag，IDA，windbg，轮番上场，甚至都调试起 windbg 来了（嗯，你没看错，不是用 windbg 调试，而是调试 windbg），好一阵忙活，中间还走了很多弯路（自以为是的在错误的函数中下断）。最后幡然醒悟，原来真理就在那躺着，静静的等着被发现。

之所以决定发出来有几点原因：

1. 介绍了让进程自动中断到调试器中的方法，甚至是让一个调试器自动中断到另外一个调试器中的方法。
2. 介绍了只对特定线程设置断点的方法、使用 wt 追踪函数调用的方法等。
3. 提醒自己，在调试过程中一定要保持清醒的头脑。

没耐心的朋友直接跳到最后即可。

问题回顾

相信小伙伴儿们都已经知道可以通过 gflags 设置 Image File Execution Option 来让指定程序启动时自动中断到调试器。但是当启动 cvtres.exe 的时候，如果只指定文件名，windbg 会报错。报错截图如下：

猜测应该是 windbg 在创建进程的时候根据文件名不能找到相应的应用程序。

我依稀记得创建进程时，CreateProcess() 会到 PATH 环境变量指定的路径中查找文件。所以我在脚本开始的地方把 cvtres.exe 所在的路径添加到 PATH 环境变量。使用 process explorer 查看 windbg 对应的 PATH 环境变量的值，发现 PATH 环境变量已经包含了 cvtres.exe 所在的路径。因为 PATH 环境变量太长了，我把它拷贝到文件中并省略了大部分：

提示： 注意上图中高亮部分。一切皆因它而起。

难道 windbg 不是通过 CreateProcess() 创建的新进程？看来需要调试一下 windbg 了。但是 windbg 也是自动启动的，该如何调试呢？

螳螂捕蝉，黄雀在后

还记得我们是怎么调试 cvtres.exe 的吗？可以用同样的方法调试 windbg —— 通过 gflags 为 windbg 设置 Image File Execution Option。

但是有一个细节需要注意：Debugger 字段需要写一个其它调试器的路径。

cdb 与 windbg 同源，大多数命令与 windbg 一样，是一个非常合适的调试器。

按上图设置后，windbg.exe 在启动时会自动中断到 cdb.exe 中。

双击启动脚本，cvtres.exe 会自动中断到 windbg 中，而 windbg 会自动中断到 cdb 中。下图是 windbg 中断到 cdb 中的截图。

小提示： 可以使用 | 命令查看正在被调试的进程模块名。非常实用的小技巧。

windbg 已经中断下来了，应该在哪里下断点呢？

断错函数了？

创建进程应该会走 CreateProcess() 系列中的一个，猜测 windbg 应该也是调用 CreateProcess() 创建的子进程，与创建普通进程不同的是，windbg 需要调试新启动的进程。当为 CreateProcess() 函数的 dwCreationFlags 参数设置一个特殊的标志位 DEBUG_PROCESS 时，在进程创建过程中就会建立相关的调试对象，windbg 就能调试对应的进程了。

按照上面的理论，在 cdb 中输入 x *!*CreateProcess* 查看相关函数，发现了一堆相关函数。想着最终肯定会调用 ntdll 模块中的函数，于是在 cdb 中输入 bp ntdll!NtCreateProcessEx，然后执行 g 命令重新运行 windbg。 但是居然没断下来。难道 windbg 不是通过 NtCreateProcessEx() 启动新进程的吗？还是在调用 NtCreateProcessEx() 之前就检查到异常返回了？

对比正常流程

通过全路径启动 cvtres.exe 的时候，windbg 可以正常启动对应的程序。可以对比查看正常情况下 windbg 调用的是哪些函数。

通过 process monitor 监听相关事件，只查看进程相关的事件，可以看到启动 cvtres.exe 时的调用栈，如下图所示：

看来 windbg 是通过 kernelbase!CreateProcessW() 启动进程的，该函数内部最终会调用 ntdll!NtCreateUserProcess()。看来，前面草率了，在错误的函数中设置了断点。赶紧在 ntdll!NtCreateUserProcess() 处下断点。您猜怎么着？还是没断下来！！！

看来，应该是在前面就出错了。尝试在 kernelbase!CreateProcessW() 中设置断点，再试试运气。

重新下断

在 kernelbase!CreateProcessW() 中设置断点，再次运行程序，这次终于断下来了。执行 gu 退出 kernelbase!CreateProcessW() ，然后查看返回值，也就是查看 eax 的值，发现 eax 的值是 0，根据 msdn CreateProcess 文档 中的描述可知，返回 0 表示出错了。执行 !gle 查看错误码，发现 Last Error 的值是 2，也就是 ERROR_PATH_NOT_FOUND。System Error Codes (0-499) 中对应的描述如下：The system cannot find the file specified.，翻译过来就是 系统找不到指定的文件，与 windbg 的错误提示完全吻合。

看来问题出在 kernelbase!CreateProcessW() 函数内部 ，用 IDA 看了下 kernelbase!CreateProcessW() 的反汇编代码，发现该函数只是直接调用了 kernelbase!CreateProcessInternalW()。而 kernelbase!CreateProcessInternalW() 的反汇编代码超级多，即使用 IDA 的 F5 得到的伪代码都非常多，实在没耐心看完。那该怎么办呢？脑子中突然想起一个很久之前就知道但是一直没真正使用过的命令 —— wt。

wt 立功了

重新运行程序，当 windbg 中断到 cdb 后，输入 bp kernelbase!CreateProcessInternalW 设置好断点，输入 g 重新运行 windbg。中断下来后，输入 wt -l1 只追踪一层调用。

[注意]看雪招聘，专注安全领域的专业人才平台！