最近有朋友发来一个求助：某个 Qt 项目用 Qt Creator 一点“调试”就崩，报错信息五花八门，有“During startup program exited with code 0xc0000135”，有“The inferior stopped because it received a signal”，甚至直接弹 Windows 的系统框“由于找不到某个 dll，无法继续执行代码”。最让人抓狂的是，他新建一个空窗口项目，同一个调试器、同一套 Qt 版本，Debug 起来完全正常。折腾半天，最后发现根因很简单：项目里链接了第三方库的 lib，但对应的 dll 没有被复制到可执行文件旁边。
这个场景我太熟了，十个人里有八个遇到过。它并不难解决，但第一次碰到时很容易走弯路：有人重装 Qt Creator，有人换调试器，有人怀疑编译器坏了，还有人把.pro文件翻来覆去改了一通，问题依旧。这篇文章就从“为什么新项目能调试、老项目一调就崩”这个现象入手，把 lib 和 dll 之间的关系、Windows 加载程序时的搜索逻辑、以及 Qt Creator 下最省心的解决办法一次说清楚。
1. 问题现场：调试一启动就崩，换新项目却一切正常
1.1 典型报错长什么样
先说最直观的东西——报错本身。Qt Creator 里调试启动失败，通常会在三个位置留下痕迹：
- Qt Creator 底部的“应用程序输出”窗口会显示进程启动失败或退出码异常；
- “调试器输出”窗口会显示 GDB 或 CDB 报告加载失败、进程终止等信息；
- Windows 系统本身可能弹一个对话框，明确写着“由于找不到 xxx.dll，无法继续执行代码”。
我自己遇到最多的是 0xc0000135 这个退出码。它是 Windows 的 STATUS_DLL_NOT_FOUND，意思是程序启动时，系统加载器发现 exe 的导入表里列出的某个 dll 根本不存在。进程还没走到 main 函数，Windows 就把进程枪毙了。
有时候还会遇到 0xc000007b，这个更迷惑，字面意思是“映像格式不正确”。实际上它往往也是 dll 的问题——不是缺，而是坏的：比如 64 位 exe 找到了 32 位 dll，或者 Debug 版 exe 加载了 Release 版的运行库。这类问题后面单独讲。
1.2 新项目能调试反而是最重要的线索
很多人在这种时候容易慌，觉得是 Qt Creator 坏了、调试器坏了、工程文件坏了。但其实恰恰相反，“新项目调试一切正常”是一条极其重要的线索，它直接把问题范围从“工具链”缩小到了“当前项目自身”。
可以这样想：如果 Qt Creator 或者调试器本身有问题，那么新项目一样应该崩。新项目不崩，说明 Qt 构建套件、编译器、调试器、运行环境这一整套链路都是通的。那么问题只能是当前项目链接了什么新项目没链接的东西。
这个“多了的东西”在实际工程里通常是两条：一是多了一个第三方库的依赖，二是多了一段特殊构建逻辑（比如手动修改了输出目录、或者通过 LIBS 指到了一个外部库目录）。其中第三方库依赖又是最常见的。接下来的排查重点就非常明确了：检查这个项目里到底引入了哪些外部库，这些库的 dll 去了哪里。
2. 先把概念掰正：lib 和 dll 的真实关系
2.1 不是所有.lib都是静态库
很多人会把.lib和“静态库”画等号，其实在 Windows 下有两种 .lib 文件：
- 真正的静态库（static library）：编译时库代码被完整拷进 exe，运行时不依赖任何同名 dll；
- 导入库（import library）：它本身只是 dll 的“链接存根”，里面只有符号定义和跳转信息，真正代码在对应的 dll 里。链接时靠它通过编译，运行时则必须找到那个 dll。
标题里说的“使用静态库 lib 的时候，没有放动态库 dll 在旁边”，严格来说大概率不是静态库，而是导入库。很多第三方 SDK 提供的 lib 都是导入库，比如 FFmpeg 的 avcodec.lib、avformat.lib，OpenCV 的 opencv_world.lib 等，它们对应的是一堆 dll。你链接时的确只需要 .lib 就能编译通过，但 exe 一旦开跑，Windows 加载器就会按导入表去找 dll。
顺便给一个区分技巧：看文件大小。静态库内部有真实的函数实现，体积通常有几 MB 到几十 MB；导入库往往只有几十 KB 到几百 KB。也可以用 VS 自带的 dumpbin 查看，命令是 dumpbin /headers xxx.lib，导入库的头部信息里能明显看到它是“import”类型。
2.2 程序启动时 Windows 是按什么顺序找DLL的
搞懂 Windows 的动态库搜索顺序，很多问题就不需要猜了。程序启动时，系统加载器会在以下路径顺次查找依赖的 dll（简化版，但足够排查日常问题）：
- exe 所在目录；
- 系统目录（C:\Windows\System32）；
- 16 位系统目录（C:\Windows\System，基本不用管）；
- Windows 目录；
- 当前工作目录（Current Directory）；
- PATH 环境变量中列出的各个目录。
注意第一条——exe 所在目录。在 Qt Creator 的构建体系里，默认采用 shadow build，编译产物通常在一个单独的 build 目录里，比如 build-xxx-Desktop_Qt_5_15_2_MinGW_64_bit-Debug。这个目录下只有 exe 和一堆中间文件，第三方 dll 不会自动出现。所以程序启动时，加载器在第一步就找不到 dll，后面几条路径再找不到，就只能报错。
这也是为什么复制 dll 到 exe 旁边会立刻有效——它命中了搜索顺序的第一位，优先级最高，最不容易受环境变量干扰。
2.3 几种容易被误判成“缺dll”的情况
排查时很容易遇到一些看似是缺 dll，实际是别的问题的情况，提前打个预防针：
- 缺 Qt 平台插件：报错信息是“could not find or load the Qt platform plugin 'windows'”，这个看着像 dll 缺少，其实问题是 plugins/platforms/qwindows.dll 不在加载路径里。常见于把 exe 拷到别的机器上运行，Qt Creator 里因为会自动带上 Qt 目录的环境变量，一般不会触发；
- 后缀带 d 的 debug 版 Qt dll 缺失：比如 qsvgd.dll、Qt5Cored.dll，构建套件选了 Debug，但部署时只部署了 Release 版文件；
- 系统运行库缺失：MSVC 编译的 exe 依赖 msvcp140.dll、vcruntime140.dll，MinGW 依赖 libstdc++-6.dll、libgcc_s_seh-1.dll，这些不是 Qt 的 dll，但同样会触发“找不到 dll”的报错。
遇到问题别急着下结论，先用后面的方法确认到底缺什么，再对症处理。
3. 一步一步排查：五分钟定位到底缺哪个DLL
3.1 先看 Qt Creator 自带的输出
不用急着下工具，Qt Creator 自己就能提供第一批线索。点击“调试”后，立刻看底部面板：
- “应用程序输出”窗口：如果程序启动失败，这里往往有进程退出码，比如 0xc0000135；
- “调试器输出”窗口：GDB 会给你一行类似“During startup program exited with code 0xc0000135”的记录，CDB 的表达方式不同，但含义一样；
- 如果 Windows 弹了系统错误对话框，那就更省事了，对话框里直接写着缺失 dll 的完整文件名。
看到这个文件名，先记录好。如果 Qt Creator 没弹系统对话框，可以手动去 Windows 事件查看器里翻一翻：Windows 日志 -> 应用程序，找时间点对应的“应用程序错误”事件，里面会有加载失败的模块名。
3.2 用依赖分析工具确认依赖链
有时候报错信息不直接给出缺失文件名，或者你复制了 dll 之后又报缺第二个、第三个，一个一个试很浪费时间。这时候应该直接看 exe 的完整依赖链。
在 Windows 下最常用的是依赖分析工具，经典的有国外的 Dependency Walker，以及它的现代替代品 Dependencies。把构建目录里的 exe 拖进去，工具会列出 exe 直接和间接依赖的所有 dll，并标出哪些缺失、哪些存在但位数不匹配。
如果你装了 Visual Studio，也可以直接用 dumpbin 命令行工具，在开发者命令行里执行：
dumpbin /dependents 你的程序.exe它会输出 exe 直接导入的 dll 列表。这个列表比较短，适合快速判断“这个 exe 到底引了哪些库”。
3.3 判断缺失的dll是Qt自己的，还是第三方引入的
拿到缺失文件名之后，按来源分两类处理：
- 如果是 Qt 的 dll，比如 Qt5Widgets.dll、Qt5Core.dll，说明部署环节出了问题。开发环境下最稳妥的做法是用 Qt 自带的 windeployqt 工具，它会把插件、翻译文件、依赖的全部 Qt dll 一并复制到目标目录；
- 如果是第三方库的 dll，比如 avcodec.dll、opencv_world4100.dll，说明你编译时链接了第三方导入库，但忘了把执行时需要的 dll 放到构建输出目录。这个没有自动工具，只能自己复制或配置构建后拷贝动作。
还有一个容易被忽略的点：某些第三方库的 dll 自身还会依赖其他 dll。比如你用了一个依赖 libcurl 的库，那运行时还得有 libcurl 的 dll。这类“间接依赖”在 Dependencies 工具里也能看到，排查时要顺着依赖树多看一层。
4. 让Qt Creator顺利调试的三类落地解法
4.1 把DLL直接放到exe旁边：最直接、最无脑
如果你只是想赶紧让项目跑起来，最省事的办法就是把缺失的 dll 复制到构建目录里，和 exe 放一起。
具体路径要看 Qt Creator 的构建套件。以 MSVC 2019 + Qt 5.15 为例，构建目录通常在项目同级目录下，名字格式是 build-项目名-套件名-配置名，进去之后 Debug 配置下还有一层 Debug 子目录，exe 在那一层。MinGW 套件有时没有额外子目录，exe 就在构建目录根下。
复制时注意一个原则：Debug 构建用 Debug 版 dll，Release 构建用 Release 版 dll。Qt 的 debug 版 dll 通常带 d 后缀，比如 Qt5Cored.dll、Qt5Widgetsd.dll，第三方库则往往不区分，但你自己得知道来源。
这个方法定位是第一位的——它命中搜索顺序第一条，不依赖任何环境变量。缺点是治标不治本：下次清理构建目录、换一台电脑、或者项目挪了位置，问题还会再出现。
4.2 通过 PATH 或 Qt Creator 运行环境配置解决
如果你不想每次手动复制，可以走环境变量路线。在系统 PATH 里加上 dll 所在目录，Windows 加载时会在搜索顺序末尾找到它们。
这里有两个注意点：
- 不推荐直接改系统全局 PATH。三个月后你可能忘了这个目录是谁加的，某个同名但版本不对的 dll 会导致各种诡异崩溃；
- Qt Creator 里可以在“项目 -> 构建与运行 -> 运行环境”中，对当前套件的 PATH 做追加。这样只在 Qt Creator 内生效，影响范围可控。
具体操作：打开项目后点击左侧的“项目”图标，进入“运行”页签，在“运行环境”一栏找到 PATH 变量，双击后在值末尾追加 dll 所在路径，用分号分隔。
PATH 方案有一个隐蔽的风险：如果系统其他目录下存在同名 dll，搜索顺序会决定最终加载哪个。之前一个项目，团队电脑都装了第三方库的另一个版本，导致只有个别机器出问题。凡是出现“我这能跑你那不能跑”的情况，优先怀疑 PATH 里同名 dll 的版本错位。
4.3 在构建步骤里自动拷贝DLL：一劳永逸
要根治“每次都要手动复制”的问题，最好的办法是把拷贝动作写进构建流程。
qmake 项目可以在 .pro 文件末尾加一行：
QMAKE_POST_LINK += $$quote($(COPY_DIR) $$shell_path(库目录) $$shell_path($$OUT_PWD))实际写的时候，把“库目录”替换为 dll 所在路径即可。它的作用是每次链接完成后，自动执行一次文件复制命令。如果需要排除某些文件不复制，建议改用更精确的 copy 命令。
CMake 项目则在 CMakeLists.txt 里加自定义构建步骤：
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different "${外部库目录}/example.dll" $<TARGET_FILE_DIR:${PROJECT_NAME}>)copy_if_different 比 copy 好一点，它会先比较文件时间戳，只有内容变化才实际复制，构建速度更快。
对于 Qt 自身的依赖，不管用 qmake 还是 CMake，都可以在构建完成后调用一次 windeployqt：
windeployqt 构建目录下的exe路径它会自动把 Qt 的 dll、插件、以及必要的运行库复制过去。注意 windeployqt 不会处理第三方库的 dll，所以第三方库的拷贝还是得自己写。
5. 别急着甩锅给调试器，还有几个坑同样常见
5.1 运行能过、调试就崩的场景
有一种情况让不少人反复折腾过：点击“运行”按钮程序能启动，点击“调试”按钮却启动失败。这看着像调试器的问题，其实根因多半不是。
Qt Creator 里“运行”和“调试”走的启动逻辑不完全一样。运行模式直接创建进程；调试模式会先启动调试器，由调试器再创建被调试进程。区别在于：调试器创建进程后，进程会先停在加载器初始化阶段，调试器需要向目标进程注入调试信息、处理符号加载。如果某个 dll 在启动时有一丁点不兼容，运行模式可能一眨眼就过去了，调试模式则更容易暴露问题。
另一个常见原因是“调试时程序工作目录不同”。Qt Creator 默认会把工作目录设置为构建目录，但如果你在“运行环境”里改过工作目录，调试时可能沿用旧配置，导致相对路径下的 dll 加载失败。
遇到这类情况，第一件事永远是对照检查“运行模式的工作目录”和“调试模式的工作目录”，确认一致再看别的。
5.2 Debug和Release混用的连锁反应
Debug 和 Release 混用是 Windows 客户端开发里的经典翻车现场。比如 MSVC 下，Debug 版 Qt 库依赖 Debug 版 C 运行时，也就是需要 vcruntime140d.dll、ucrtbased.dll 这些调试版运行库。如果你在 Debug 配置下部署时使用了 Release 版 Qt dll，进程启动很可能直接报 0xc000007b。
更隐蔽的是：Debug 版 dll 不能加载你项目里 Release 版编译的静态库代码。之前一个项目，一方用 Debug 编译，另一方把库发成了 Release，结果程序一运行数据结构错位，野指针满天飞。
排查思路并不复杂：从“运行”模式试起，如果运行正常，问题就大概率不在 dll 缺失；如果运行也崩，再用依赖分析工具看加载了哪些模块；最后确认所有 dll 的来源配置保持一致。
5.3 报错码速查
把常见的几个启动报错码列成表，遇到直接用：
| 退出码/错误 | 含义 | 常见原因 |
|---|---|---|
| 0xc0000135 | STATUS_DLL_NOT_FOUND | 依赖的 dll 不存在，最常见 |
| 0xc000007b | STATUS_INVALID_IMAGE_FORMAT | 位数不匹配或 dll 损坏 |
| 0xc0000142 | DLL 初始化失败 | dll 本身无法完成初始化 |
| 0xc0000409 | 缓冲区校验失败 | 复杂问题，优先排查安全软件和系统更新兼容性 |
| 0xc0000005 | 访问冲突 | 指针灾难，常见于 Debug/Release 混用 |
前三个和本文主题直接相关，后两个属于发射后的二次故障，遇到时建议回到依赖链重新梳理一遍。
6. 常见问题速查与实操心得
6.1 高频问题清单
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 新项目调试正常，老项目一调就报 0xc0000135 | 老项目链接了第三方导入库，缺对应 dll | 在构建目录放入 dll，或配置构建后自动复制 |
| 报错信息提示缺 Qt5xxx.dll | 构建输出未部署 Qt 依赖 | 用 windeployqt 部署 |
| 报错提示缺 msvcp140.dll | MSVC 运行库缺失 | 安装相应 VC++ 运行库，或部署时带上 |
| 报错提示缺 libstdc++-6.dll | MinGW 运行库缺失 | 将 MinGW 安装目录 bin 下的 dll 一并复制 |
| Windows 弹框提示缺 dll，但文件明明在同目录 | dll 版本位数不匹配或依赖链断裂 | 用依赖分析工具查完整依赖链 |
| 弹“could not find or load the Qt platform plugin” | 缺少平台插件或路径错误 | 确认 platforms 目录在下级目录，部署时保留目录结构 |
6.2 从实际项目里摸出来的几条经验
第一，构建后自动拷贝的脚本里，路径不要写死绝对路径。项目换机器、库目录变化，维护成本很高。建议在 .pro 里用变量指路，比如把第三方库目录定义成一个变量，拷贝命令引用变量。
第二，dll 不要一次性全复制到系统目录。有人图省事，直接把 dll 丢进 C:\Windows\System32，系统一更新或者别的软件改了同名文件，问题立刻变玄幻。正确的做法是保持 dll 与 exe 的相对位置，这是 Windows 应用部署的最稳方案。
第三，排查时先清干净构建目录再复现。比如把 build 目录整个删掉，重新构建一次，能排除“旧文件残留导致加载了过时 dll”的干扰。这一步看着简单，实际能省几小时。
第四，第三方库有几个不同版本的 dll 时，保证全项目统一版本。曾经一个界面项目用了两个库，一个依赖 A 版某个 dll，另一个依赖 B 版，复制时总有一个库不满意，程序一运行就崩。最终方案是统一到高版本，并把这个版本锁进构建脚本。
第五，调试器报错时，先点开“应用程序输出”，再点“调试器输出”，最后翻 Windows 日志。很多人只盯着调试器输出窗口，结果被 GDB 的一堆符号加载警告带偏了方向。
这些经验说白了都是“用时间换来的”，踩过一次坑，以后至少能少折腾半天。遇到 Qt Creator 调试启动崩溃时，把思路理顺：新项目正常说明工具链没问题；老项目多了 lib 依赖，运行时缺 dll 是头号嫌疑；确认后通过复制 dll 或自动部署解决。这个流程走一遍，大部分问题都能在五分钟内定位到根因。
