IDA Pro调试功能怎么使用 IDA Pro调试程序无法运行怎么办

一个小工具平时双击就能打开，放进IDA Pro，按F9却马上结束。这种情况不必先怀疑安装出了问题。双击、命令行启动、调试器启动，带给程序的条件可能不同。下面以Windows本机调试为例，从启动设置讲到断点，再看这几种运行问题分别查哪里。

一、IDA Pro调试功能怎么使用

1、确定程序在哪里运行

下面以Windows本机调试为例。分析Linux程序、设备固件或另一台电脑上的文件时，调试器需要另行选择。IDA能打开文件，只说明它可以分析其中的内容；目标还得有相应的运行环境。

①打开目标文件，等待自动分析结束。

②点击【Debugger】→【Select debugger】，选择本地Windows调试器。

如果打开的是DLL，启动对象应是加载它的宿主程序。DLL本身不能当成普通EXE启动，【Application】因此对应宿主路径。

2、把启动路径和参数填清楚

【Process options】里几个字段容易混淆。【Application】决定启动谁，【Input file】对应当前分析的文件；调试EXE时二者可以相同，调试DLL时就可能不同。【Directory】是工作目录，程序通过相对路径读取配置时会用到它。

①点击【Debugger】→【Process options】，核对【Application】。

②在【Directory】填写程序所需的工作目录。

③把原有启动参数填入【Parameters】，没有参数则留空。

④点击【OK】，按F9启动。

例如工具会读取当前目录下的config.ini，工作目录换了，它就可能找不到配置。文件明明还在，却照样启动失败。

3、放一个能触发的断点

首次调试不用把所有函数都设上断点。想看某次输入为何校验失败，就从相关调用或判断指令附近开始。断点命中以后，高亮位置表示当前暂停处，旁边的寄存器值才是这次运行的实际数据。

①在【IDA View】选中目标指令，按F2设置断点。

②按F9运行，在程序里触发对应操作。

③停住后查看【Registers】、【Stack view】，按F7单步进入或按F8单步越过调用。

F7可能把你带进库函数；只关心调用结果时，F8更省事。两者的区别在于是否进入被调用函数内部。

二、IDA Pro调试程序无法运行怎么办

先看报错发生的时间。按F9立刻弹窗，与进程出现后又退出，检查方向不同。程序还在响应，只是断点没停，也要单独处理。保留具体提示，比笼统记一句“调试失败”更方便查找原因。

1、提示无法创建进程

文件搬过位置、改过名称，旧数据库里的启动路径未必跟着变。先确认IDA启动的是哪个文件，尤其是电脑里留着几份同名程序的时候。

①进入【Debugger】→【Process options】，重新选择【Application】中的有效文件路径。

路径有效但调试器不支持目标的系统和架构，程序同样无法启动。调试DLL时，这里的启动文件应为宿主EXE。

2、进程出现后马上退出

这种情况至少说明启动已经发生了。程序可能缺参数，也可能读不到配置；控制台工具做完任务后正常退出，看起来也像“一闪而过”。退出码和程序提示能帮助区分这些情况。

①对照程序平时的启动方式，核对【Directory】、【Parameters】。

②重新按F9，查看【Output window】中的退出信息。

③需要观察入口时，在【Debugger】→【Debugger options】启用【Suspend on process entry point】，再次启动。

若程序在系统里也打不开，就先处理缺失依赖、配置错误等运行问题。入口之前便已终止的程序，业务函数上的断点自然不会命中。

3、程序正常响应，断点不触发

例如点击了按钮，窗口内容也变了，说明程序正在执行。没停在断点，可能只是那次操作没有经过目标分支。还有一种容易忽略的情况：分析的是旧版文件，启动的却是新版。

①核对【Application】所指版本，在【Modules】确认目标模块已经加载。

②打开【Debugger】→【Breakpoints】，检查断点是否启用、位置是否正确，再触发目标操作。

运行时模块基址可能变化。手工填地址的断点，还应结合实际加载位置核对，不能只照抄另一轮调试的地址。

4、附加进程失败

由启动器拉起的程序，可以在运行后附加。但进程已经退出、选错进程，或者当前账号没有调试权限，都可能导致失败。管理员权限也不保证能附加所有受保护的进程。

①点击【Debugger】→【Attach to process】，按进程名称和PID选择目标。

②出现权限错误时，核对目标进程与IDA的权限；目标需要提升权限时，以相应权限重启IDA后再试。

5、远程调试连接不上

远程调试分两头：IDA在本机，程序和调试服务在目标机器。连接参数正确，也不代表目标文件路径正确。本机的下载目录填到远程配置里，服务端并不会有那个文件。

①在目标机器启动与目标架构匹配的IDA远程调试服务。

②在【Debugger】→【Select debugger】选择相应的远程调试器。

③进入【Process options】，填写【Hostname】、【Port】，设置过密码则填写【Password】。

④将【Application】、【Input file】和【Directory】改为目标机器上的实际路径。

服务端收不到连接，问题还在地址、端口或网络放行情况；已经连接却无法启动，则与目标路径、启动条件更相关。

三、程序运行以后，怎样查得更具体

1、给这次调试留一个参照

同一条判断，每次输入不同，寄存器值当然也可能不同。记录“这次用了什么输入”，比单独抄一个数值有用。否则第二次停住时，看到值变了，却不知道是正常变化还是故障。

①准备一组能重复触发问题的输入。

②在同一位置记录相关寄存器值和返回值。

③换一组正常输入再次运行，比较分支及数据差异。

2、从调用链里找回上下文

暂停位置落在库函数里时，函数名未必能说明问题。调用链可以告诉你程序怎样来到这里，帮助找回自己关心的那次操作。

①打开【Stack trace】，查看当前函数的上层调用。

②双击相关调用位置，在自己的代码里继续核对参数与返回结果。

总结

有些调试故障，最后找到原因时会让人有点哭笑不得：文件没坏，IDA也没坏，只是程序换了个目录，就不认识自己的配置文件了。碰过这种问题，才会留意平时双击程序时那些看不见的条件。调试当然也会遇到复杂的调用和异常，但看到“无法运行”四个字，未必就意味着接下来要研究一大段汇编。你有没有遇到过类似的小差异？当时是哪条报错让你终于发现问题的，评论里聊聊。