VS2022 C++项目独立exe打包：DLL依赖与运行库发布实战

装机量最大的桌面环境仍然是 Windows而大量 C 项目最后一步都卡在同一件事上Visual Studio 里按 F5 一切正常把 exe 拷到别人电脑上双击就是缺少 xxx.dll或者 0xc000007b。我把这几年经手的项目从能编译打磨到能发布的过程整理成这篇围绕 Visual Studio 2022 下的 C 项目如何打包成可独立运行的 exe讲清楚依赖怎么清点、运行库怎么选、目录怎么摆、安装包怎么做。适合已经能写出跑得起来的程序、但一发版就被打回来的朋友也适合接手别人遗留工程、需要一个下午摸清它到底依赖什么的人。文中不给万能脚本给的是一套可复现的判断流程——你照着走一遍就知道自己项目的坑在哪。1. 从我这能跑到他那打不开三个高频翻车现场先把最常见的失败形态摊开来看。发布这件事的难点从来不是怎么把 exe 拷出去而是为什么我这台机器能跑、他那台不行。这三个现场几乎覆盖了我遇到过的大半问题对号入座能省掉很多瞎试的时间。1.1 0xc000007b 与找不到 MSVCP140.dll 的真实含义先说明白这个0xc000007b是 STATUS_INVALID_IMAGE_FORMAT名字看着像文件损坏实际在九成场合下是位数不匹配。你编的是 64 位程序依赖链里混进了一个 32 位 DLL或者反过来。系统的加载器按顺序找同名 DLL找到第一个就加载加载了发现结构不对直接抛这个错误。它不会告诉你哪个文件错了这就是它烦人的地方。另一类报错更直白弹窗提示找不到MSVCP140.dll、VCRUNTIME140.dll、VCRUNTIME140_1.dll。这几个是 MSVC 的可再发行运行库你的开发机装了 Visual Studio它们被顺手装进了 System32所以你本地永远正常。目标机器没装过任何开发环境自然找不到。很多人第一反应是那我让人装一下这个运行库合集能解决但作为发布方把这件事甩给用户是不体面的后面第 4 节会讲两种自己兜住的办法。还有一种更隐蔽的api-ms-win-crt-runtime-l1-1-0.dll缺失。这属于 UCRT通用 C 运行库Windows 10 及以后是系统自带的但更早的系统需要额外的系统更新才具备。这条依赖链最有迷惑性因为它不是你的编译器直接产出的而是由 CRT 内部的 API Set 转发出去的用老工具查的时候经常看不全。判断顺序建议先看报错是加载失败弹窗还是启动后立刻退出0xc000007b。前者基本是缺文件后者优先怀疑位数。别一上来就重装运行库那是治标。1.2 隐式依赖你只拷了 exe它还要一堆东西第三方库分两类依赖方式。显式依赖是你代码里LoadLibrary或者链接了导入库这类通常好发现隐式依赖是你链接的那个库本身还链着别的东西是踩坑重灾区。举个我踩过的例子项目引了一个图像处理库我把它的主 DLL 拷过去了程序启动直接崩连报错窗口都不给。用依赖查看工具一拉链发现这个主 DLL 又静态链进去了另外三个运行库 DLL少一个就加载失败。这种链式依赖在你自己的工程里是完全看不见的因为编译和链接阶段库的作者已经处理完了只有运行时才暴露。还有一类是延迟加载和插件式加载。程序启动正常点某个功能才崩那多半是某个功能模块通过LoadLibrary动态加载了一条你没带走的路径。这类问题在测试时容易被忽略因为开发机上那条路径是存在的。我的做法是把依赖清点当成一个独立步骤而不是编译完顺手拷一下。具体工具和流程在第 3 节详细说。1.3 工作目录与相对路径调试器悄悄替你兜了底这一条最坑也最容易被忽略。Visual Studio 调试时默认工作目录是项目目录不是你 exe 所在的输出目录。所以你的代码里写fopen(config/settings.json, r)或者imread(assets/logo.png)在调试器里跑得好好的——因为项目目录下确实有这些文件。一旦你双击 exe工作目录变成了 exe 所在的文件夹所有相对路径全部失效。这类问题的表现很有特点不是崩溃而是功能静默失效。配置文件读不到就走默认值模型文件加载失败就降级日志目录建不出来就直接不写日志。用户看到的是这软件怎么不太对你看代码看不出任何毛病。正确姿势是不要相信工作目录。启动时就把基准目录定死为 exe 自己所在的目录#include filesystem #include windows.h std::filesystem::path GetAppDir() { wchar_t buf[MAX_PATH]{}; ::GetModuleFileNameW(nullptr, buf, MAX_PATH); return std::filesystem::path(buf).parent_path(); } // 之后所有资源路径都基于 GetAppDir() 拼 auto cfg GetAppDir() / Lconfig / Lsettings.json;另外提醒一个反向的坑不要图省事去SetCurrentDirectory把工作目录改成 exe 目录。如果你后续要拉起用户选择的文件、或者调用带相对路径参数的第三方命令行工具改工作目录会带来一连串副作用。只在自己拼路径时用绝对路径就够了工作目录保持系统给的原样。2. Release 配置里那几个开关决定了后面要还多少债很多人打包失败根子不在打包环节而在编译配置。项目属性面板里那几个选项随手一改就是几种完全不同的发布形态。这一段把关键开关逐个拆开说讲清楚每个选项改了什么、代价是什么。2.1 运行库选项 /MD 与 /MT不是静态就一定好位置在项目属性 → C/C → 代码生成 → 运行库。默认 Debug 配置是多线程调试 DLL (/MDd)Release 是多线程 DLL (/MD)。/MD动态链接 MSVC 运行库exe 体积小但目标机需要运行库 DLL 或系统里装了可再发行包。/MT静态链接运行库运行库代码被塞进 exe单个文件自给自足体积大几百 KB 到 1MB 不等。/MDd、/MTd是调试版绝对不能出现在发布产物里。调试版运行库依赖ucrtbased.dll这类只在开发机上存在的文件还带大量断言开销。选哪个我的一般判断是如果项目只有一个 exe第三方库也不多/MT最省事拷一个文件就能发。但只要出现下面任一情况我会退回/MD场景推荐原因单 exe依赖第三方 DLL 少/MT少一份运行库依赖分发最简单多个模块/DLL 互相传递 STL 对象/MD各模块共享同一份堆和 CRT 状态依赖的第三方库已经是/MD编译的/MD混用会导致 CRT 状态分裂项目里有大量异常、locale、iostream 跨模块使用/MD静态链接时每个模块各有一份状态最后一行是关键。/MT最大的坑不是体积而是每个模块各自持有一份 CRT 堆。A.dll 里new出来的指针传到主程序里delete两边的堆管理器不是同一个轻则内存泄漏重则直接堆损坏崩溃而且崩的位置往往和真正出错的位置隔了很远极难定位。我见过一个项目因为这个原因崩了两个月都没查出来最后发现是某个同事把运行库从/MD改成了/MT。混合链接是最糟的组合主程序/MT、依赖库/MD或者反过来。链接器会给你一堆LNK4098: 默认库LIBCMT与其他库的使用冲突警告这个警告不能忽略必须清干净。2.2 平台工具集、目标平台和 Windows SDK 版本的三重对齐平台工具集选v143VS 2022 自带的这个一般不用动。真正需要关注的是目标平台和SDK 版本。解决方案平台要明确是x86还是x64。Any CPU是 .NET 的概念C 项目里没有真正的任意最终一定落到某个具体架构。我接手过的工程里有人为了兼容性把所有依赖都按 x86 编结果程序能吃到的内存被卡在 2GB 上下处理大文件时直接崩。现在除非要对接特定的老系统或老硬件我一律 x64 起步。Windows SDK 版本决定了你能调用哪些 API也影响_WIN32_WINNT宏的默认值。如果你的代码里用了较新的 API在旧系统上会因为找不到入口点而加载失败——注意这个失败发生在加载阶段比运行时报错更早、提示更含糊。稳妥的做法是在代码里显式定义目标系统版本并且对可能缺失的 API 用GetProcAddress动态取地址而不是直接调用。还有一处经常被忽略Debug 和 Release 的位数可能不一样。项目属性是按配置保存的有人只把 Release 改成 x64Debug 还留在 Win32结果测试用的是 32 位、发布的是 64 位行为差异全出来了。切换配置后建议把属性面板两个配置都过一眼。2.3 字符集、C 标准与二进制兼容性字符集在项目属性 → 高级 → 字符集。默认是 Unicode也就是宏UNICODE和_UNICODE生效。如果你的代码混用了char和wchar_t的 API 版本或者依赖某个只支持 ANSI 的老库容易在 Release 下暴露出来——因为不同配置的宏定义可能不一致。C 语言标准同理。VS 2022 默认std::c14如果你改了/std:c17或/std:c20要确认所有依赖库是用同等级别的标准编的。STL 在不同标准下的 ABI 有细微差别跨模块传递std::string、std::vector时出问题的概率随之上升。一个实用建议把发布配置的语言标准、字符集、运行库这三项写进项目 README 或者团队约定里。这三个参数只要有一个和依赖库不一致排查成本就是按天算的而且症状分散很难和别人描述清楚。发布前还有一个动作必须做清理并重新生成。不要用增量编译的产物打包。我遇到过资源文件改了没生效、老的 obj 混进链接的情况表现在 exe 里图标还是旧的。菜单里生成 → 清理解决方案再重新生成解决方案这两步花不了两分钟。3. 依赖清点把 exe 真正需要的文件一个一个列出来这一步是整个流程里最需要耐心、也最能体现经验的地方。目标很明确拿到一份完整的清单写清楚 exe 旁边必须放哪些文件一个不多一个不少。3.1 用 dumpbin 拉出第一层依赖VS 自带dumpbin不需要额外装东西。从开始菜单打开x64 Native Tools Command Prompt for VS 202232 位项目就用 x86 的那个切到输出目录dumpbin /dependents MyApp.exe输出是一张表列出所有导入的 DLL。看到的东西大概长这样KERNEL32.dll USER32.dll MSVCP140.dll VCRUNTIME140.dll VCRUNTIME140_1.dll opencv_world490.dll这里要做一个重要区分上面四行系统 DLL 不用管它们在任何 Windows 上都存在MSVCP140那几行是运行库需要处理opencv_world490.dll是第三方库必须随包带走。判断标准很简单——文件名是KERNEL32、USER32、GDI32、ADVAPI32、SHELL32、ole32这一类 Windows 核心组件的一律不用管。名字里带api-ms-win-前缀的也是系统转发层不用管。然后对每个第三方 DLL 重复这个操作一层一层往下拉dumpbin /dependents opencv_world490.dll一直拉到所有叶子节点的依赖都是系统 DLL 为止。这个过程手工做有点烦但一般项目两三层就到底了。如果依赖特别多可以写个脚本递归跑注意加个已访问集合防止循环引用。dumpbin有一个短板它对 API Set 的解析在老版本上不完整有时候会漏报。所以我不把它当唯一依据。3.2 用图形化工具做交叉验证我习惯用两个工具互补。第一是Dependencies一个开源的可视化依赖分析工具它支持 API Set 解析能看到完整的加载链还能直接看每个模块的导入导出表。用它打开 exe左侧树状展开红色标记的就是找不到的模块。这个找不到非常有价值因为它用的搜索路径和你机器上的实际环境一致能直接告诉你缺什么。第二是 VS 自带的**查看 → 其他窗口 → 模块**调试窗口。在调试运行时打开它能看到进程实际加载了哪些 DLL、从哪个路径加载的。这一招对排查加载了错误版本的同名 DLL特别有效——文件名一样但路径不对是 DLL 地狱的经典形态。两个工具的结果交叉一下基本不会有遗漏。这里有个经验以实际运行时的模块列表为准。因为有些库是延迟加载的静态依赖表里看着没有运行到某一步才加载。所以要跑一遍完整的功能流程把模块列表导出再和静态清单比对。3.3 修剪第三方目录只留 Release、只留对应位数拿到清单之后别急着全部拷贝。第三方库的安装目录里通常混着 Debug 版、Release 版、x86 版、x64 版、还有一堆.lib、.pdb、头文件。直接整个目录拖过去包体积能翻好几倍。我的规则是三条第一只拷运行时需要的不拷开发用的。.dll要.lib、.exp、.pdb、头文件、cmake配置一律不要。第二只拷对应位数的。bin/x64下的不要bin/x86。混着放最危险因为 Windows 的 DLL 搜索顺序里exe 所在目录优先级很高一个错位数的同名文件就能把程序搞死报的还只是 0xc000007b。第三Debug 版 DLL 一律剔除。命名规律通常是带d后缀opencv_world490d.dll、Qt6Cored.dll。这类文件依赖调试版运行库发布出去必然加载失败。顺便说一个体积优化的点如果你的库提供world合并版和拆分版合并版通常是单个大 DLL拆分版是多个小 DLL。发布场景下合并版更省心不容易漏但如果你只需要其中一两个模块拆分版能显著减小体积。这个取舍看具体项目我一般是先能用合并版跑通再考虑要不要裁。3.4 资源、配置、模型与数据文件和 exe 的相对关系依赖清点不只是 DLL。很多项目还带一堆非代码文件配置文件、图标、字体、翻译文件、模型权重、模板文档。这些文件的组织原则只有一条以 exe 所在目录为根保持固定的相对结构。不要依赖安装到某个绝对路径也不要依赖用户从哪个目录启动。第 1.3 节那个GetAppDir()在这里派上用场。我用得最多的目录骨架是这样MyApp/ ├── MyApp.exe ├── *.dll # 运行库 第三方库 ├── config/ │ └── settings.json ├── resources/ │ ├── icons/ │ └── fonts/ ├── models/ # 大的数据文件 └── logs/ # 空目录运行时写入logs这个目录要特别说一句。如果程序最终装到Program Files下普通用户对那个目录没有写权限。你的程序在开发机上写日志写得好好的装到用户机器上就静默失败因为CreateDirectory返回了拒绝访问而你可能压根没检查返回值。正确做法是日志、缓存、用户数据一律写到%LOCALAPPDATA%\你的程序名\下面用SHGetKnownFolderPath(FOLDERID_LocalAppData, ...)拿路径。这既是权限问题也是多用户场景下的正确做法。4. 让 exe 摆脱装运行库的两条路线前面反复提到运行库依赖。这一节把两条主流路线掰开讲各自的适用边界、操作细节和副作用。4.1 静态链接运行库一条命令换来的独立性改法很简单项目属性 → C/C → 代码生成 → 运行库 → 多线程 (/MT)Release 配置改Debug 配置改成/MTd如果 Debug 也要独立跑的话。改完清理重编再用dumpbin /dependents看一眼MSVCP140.dll、VCRUNTIME140.dll这几行应该全部消失。有效是有代价的我把代价列清楚体积增长。静态链接进来的运行库代码大概几百 KB最终 exe 增大 300KB 到 1MB 不等看用到的 CRT 功能多少。跨模块传递对象有风险。前面 2.1 讲过每个模块一份堆。如果你的项目是一个 exe 若干自己写的 DLL而 DLL 接口里出现了std::string、std::vector、std::shared_ptr这类 STL 类型/MT下就要非常小心。解决办法是接口只暴露 C 风格的类型或者用带自定义删除器的智能指针把释放动作约束在创建它的那个模块里。第三方库必须也是/MT。这一条最容易翻车。你改了主程序依赖的预编译库还是/MD链接器会报LNK4098运行起来可能出现诡异的内存问题。如果第三方库只提供/MD版本很多商业库是这样那这条路就走不通老老实实用第 4.2 节。判断标准可以简化成一句话项目是单模块、或者 DLL 接口不碰 STL就走/MT否则走/MD 随包带运行库。我现在的项目大多是后者因为只要规模上去模块化是必然的。4.2 AppLocal把运行库 DLL 放在 exe 旁边AppLocal 部署的意思是不要求用户在系统层面安装运行库而是把运行库 DLL 直接放到 exe 同目录。Windows 的 DLL 搜索顺序里exe 所在目录的优先级高于 System32所以程序加载时会优先用到你带的那份不用管系统里装没装。需要拷哪些文件用dumpbin /dependents看你的 exe 直接依赖了哪些通常是这几个msvcp140.dll vcruntime140.dll vcruntime140_1.dll concrt140.dll # 用到并发运行时才需要从%VCToolsRedistDir%下面拷贝路径类似C:\Program Files\Microsoft Visual Studio\2022\...\VC\Redist\MSVC\版本号\x64\Microsoft.VC143.CRT\。注意是Redist目录不是System32里那份——System32里的可能是被系统更新覆盖过的版本不一定匹配你的工具集。这里面有个坑要说清楚UCRT 部分。ucrtbase.dll在 Windows 10 及以后是系统组件不用带但如果你的程序需要跑在更早的系统上就需要额外处理方式是用随 Visual Studio 提供的 UCRT 可再发行组件。我一般的判断是——如果明确不需要支持老系统就不带包更干净如果需要就在文档里写清楚前置条件而不是悄悄带一堆文件让体积膨胀。还有一件事必须做在干净环境验证。找一台没装过 Visual Studio 的机器或者一个全新的虚拟机快照把整个文件夹拷过去跑。这一步不能省因为你的机器上永远有你看不见的运行时环境。我吃过这个亏本地全绿发出去当天就被反馈启动不了最后发现某个依赖是从系统目录加载的而那个目录里的版本是某个开发工具顺手装的。建议在虚拟机里建立三个检查项不装任何开发工具、不要管理员权限运行、把网络断掉。断网这一条是为了排除某功能依赖在线资源的假象。4.3 DLL 地狱与清单冲突同名不同版的排查方法有一种失败特别难查程序能启动但某些功能的行为和预期不一致或者用到某功能时才崩。原因往往是加载了一个同名但版本不对的 DLL。排查手段有两个。一是用调试器的模块窗口看实际加载路径逐个核对是不是你预期的那个。二是用 Process Monitor 这类工具过滤Load Image事件能看到完整的加载尝试记录包括失败的尝试。Windows 的搜索顺序大致是exe 目录 → 系统目录 → 当前目录 → PATH 里的目录。知道了顺序就知道为什么我明明拷了正确版本它不用——大概率是系统目录里有优先级更高的同名文件或者位数不匹配被跳过。还有一个和清单文件相关的问题。Visual Studio 的 C 项目可以配置链接器 → 清单文件 → 生成清单。如果你的程序引用了某个带 side-by-side 清单的组件而清单里的版本号和目标机器上实际安装的组件对不上会报应用程序无法启动因为应用程序的并行配置不正确。这类报错的排查思路是用mt.exe把 exe 内嵌的清单提取出来看对照依赖组件的实际版本。多数情况下最简单的解法是放弃外部 side-by-side 依赖改成 AppLocal 直接带文件。5. 发布产物的目录骨架与那些看不见的配置把文件凑齐只是第一步。一个能让用户双击就用的发布包还需要图标、版本信息、权限声明这些看起来可有可无、但直接影响体验的东西。5.1 一套可复用的目录结构与输出配置我习惯在项目里把输出目录和中间目录分开避免 Debug 和 Release 的 obj 文件互相污染。设置位置在项目属性 → 常规 → 输出目录 / 中间目录输出目录: $(SolutionDir)bin\$(Platform)\$(Configuration)\ 中间目录: $(SolutionDir)obj\$(Platform)\$(Configuration)\这样编完之后bin\x64\Release\下面就是干净的产物目录。再把资源文件通过生成事件 → 后期生成事件按需拷贝过去一条xcopy就够了xcopy /Y /E /I $(ProjectDir)resources $(OutDir)resources比起手工拷写成后期事件的好处是不会再忘。但要注意xcopy的返回码如果在没有文件可拷时返回非零MSBuild 会把生成判为失败。稳妥做法是在末尾加if errorlevel 1 exit /b 0之类的容错或者用robocopy并接受它的特殊返回码。整个目录打包成 zip 之前我会做一次减法删掉*.pdb除非要给用户做崩溃分析、删掉*.lib、删掉任何名字里带d.dll的文件、删掉遗留的测试数据。这一步花三分钟能省掉后续无数次用户说包太大和为什么会有调试符号的沟通。5.2 应用程序清单UAC 权限、DPI 感知与兼容性清单文件manifest是个 XML可以内嵌进 exe也可以单独放在旁边。它决定了三件很实际的事第一UAC 权限级别。默认是asInvoker即继承启动者的权限普通用户启动就是普通权限。如果你的程序需要写系统目录、装驱动、改注册表全局项就要改成requireAdministrator。改的办法是在项目属性 → 链接器 → 清单文件 → UAC 执行级别里选。这里我的建议是能不提升就不提升代价是每次启动都弹权限确认框用户会烦。真正需要的写操作改成写用户目录更合适。第二DPI 感知。不声明 DPI 感知的程序在高分屏上会被系统做位图拉伸界面糊得没法看。现代做法是在清单里声明 Per-Monitor V2application xmlnsurn:schemas-microsoft-com:asm.v3 windowsSettings dpiAwareness xmlnshttp://schemas.microsoft.com/SMI/2016/WindowsSettingsPerMonitorV2/dpiAwareness dpiAware xmlnshttp://schemas.microsoft.com/SMI/2005/WindowsSettingstrue/dpiAware /windowsSettings /application加了 Per-Monitor V2 之后你的窗口需要在WM_DPICHANGED消息里响应缩放变化否则多屏拖动时会错乱。这是笔额外的工作量但对比整个界面模糊的体验损失值得。第三兼容性声明。清单里可以声明程序适配的系统版本影响某些 API 的行为。比如没声明的话GetVersionEx会返回假的版本号。这块平时不太会碰到但如果你发现程序在目标机上某个系统 API 的表现和开发机不一样可以先看看清单。5.3 图标、版本信息与文件属性图标不复杂但要注意两点。一是资源文件里IDI_ICON1的编号要设对通常是 ID 最小的那个图标被资源管理器用作显示图标。二是一定要提供多种尺寸16、32、48、256只给一个 256x256 的 PNG 压缩图标在大图标视图下好看在任务栏小图标上会糊成一团。版本信息更值得认真填。在资源视图里能直接编辑VERSIONINFO填公司名这里填你自己的或者留空、文件说明、文件版本、产品版本。这些信息会在文件属性里显示也是安装包和自动更新做版本比较的依据。版本号建议用主版本.次版本.修订号.构建号四段式并且和构建流程绑定——每次正式构建自动递增构建号避免两个不同的包版本号一样这种麻烦。资源文件里如果填中文注意.rc文件的编码问题。老版本的资源编译器对 UTF-8 支持不好容易出现乱码。稳妥做法是.rc存成带 BOM 的 UTF-8或者在文件头加#pragma code_page(65001)。6. 交付形态的选择与分发前的最后一次自检到这一步产物齐了最后要决定的是给用户一个压缩包还是做一个安装程序。这个选择取决于你的用户群和使用场景没有标准答案但有明确的判断依据。6.1 绿色压缩包与安装包各自适合什么压缩包适合内部工具、技术人员使用、程序本身没有注册表和系统目录依赖、不需要开始菜单项。好处是零安装成本、可以多版本共存、卸载就是删文件夹。我自己的内部工具基本都是 zip 一个说明文件。安装包适合面向普通用户、需要写注册表关联文件类型、需要开机自启、需要装到Program Files、需要正规的卸载入口。用户对下载一个 exe双击下一步下一步这套流程是有预期的给个压缩包反而会让人不知所措。如果决定做安装包工具上我常用两类轻量脚本型的配置写起来直观几分钟能跑通一个基础安装和功能更全的能处理复杂的组件选择、升级逻辑。无论用哪个几个要点是一致的安装目录默认给Program Files下的子目录但允许用户改。卸载时要清理干净程序目录、开始菜单项、注册表项。特别注意不要误删用户数据目录。不要在安装时静默安装运行库。如果你用了 4.2 的 AppLocal 方案运行库已经在你自己的目录里完全不需要系统级安装也就不会和其他软件产生版本冲突。加一个安装完成后直接运行的勾选项用户第一次体验会顺畅很多。如果程序需要和某个系统集成比如注册文件类型关联记得在安装脚本里写注册表并且在卸载时删掉。只写不删是最常见的低级问题用户卸载后文件图标还在观感很差。6.2 pdb 符号与崩溃日志发布之后才见真章.pdb文件不要放进发布包但绝对不能删掉。它是把崩溃地址还原成函数名和行号的唯一凭据。我习惯把每次发布版本的 pdb 和 exe 一起归档到内部的一个目录里按版本号命名保留至少最近十个版本。程序在用户那边崩了怎么定位两条路。一是让程序自己在崩溃时写出 dump 文件这需要在代码里装一个未处理异常过滤器#include windows.h #include dbghelp.h #pragma comment(lib, dbghelp.lib) LONG WINAPI CrashHandler(EXCEPTION_POINTERS* ep) { auto dumpPath GetAppDir() / Lcrash.dmp; HANDLE h ::CreateFileW(dumpPath.c_str(), GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (h ! INVALID_HANDLE_VALUE) { MINIDUMP_EXCEPTION_INFORMATION info{}; info.ThreadId ::GetCurrentThreadId(); info.ExceptionPointers ep; info.ClientPointers FALSE; ::MiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(), h, MiniDumpNormal, info, nullptr, nullptr); ::CloseHandle(h); } return EXCEPTION_EXECUTE_HANDLER; } // 在 main 开头注册 ::SetUnhandledExceptionFilter(CrashHandler);注意MiniDumpNormal只包含线程栈和少量信息够用来定位崩溃位置。如果需要看局部变量得用MiniDumpWithFullMemory但文件会大到几百 MB不适合让用户回传。另一条路是靠系统的错误报告注册表里配一个LocalDumps项让系统在崩溃时自动落 dump。这种方式不需要改代码适合已经发出去的老版本。拿到 dump 之后用调试器加载把符号路径指到你归档的 pdb 目录就能看到调用栈。这一步的前提是 pdb 和 exe 严格对应——所以版本管理要做好别把 pdb 搞混了。6.3 发布前的自检清单最后给一份我自己的检查表每次正式发版前照着过一遍能拦掉八九成的问题检查项怎么查不合格的表现是否用了 Release 配置看输出目录、看 exe 属性体积异常大、带_ITERATOR_DEBUG_LEVEL相关崩溃位数是否一致任务管理器看进程、dumpbin /headers0xc000007b运行库是否自带干净机器上跑弹窗缺MSVCP140.dll调试 DLL 是否混入搜*d.dll加载失败、找不到ucrtbased.dll相对路径是否健壮从别的目录启动 exe配置读不到、功能静默降级写权限是否合理用非管理员账户跑日志不写、设置保存失败中文路径是否正常放到中文名文件夹里跑打不开文件、崩溃版本信息是否填了右键属性看详细信息一片空白用户无法确认版本pdb 是否归档检查归档目录出问题后完全无法定位杀毒软件是否误报用新装的系统跑一次文件被直接删掉或隔离最后一条要单独说。自己写的、没有数字签名的 exe被安全软件拦下来的概率不低尤其是程序里有网络通信、进程操作、或者打包工具生成的安装程序。如果用户群比较大值得考虑买个代码签名证书能显著降低误报和这软件是不是病毒的质疑。如果暂时不签至少在下载页面上说明文件的大小和校验值让用户能自行核对。另外把整个流程沉淀成一个脚本会省很多事。我现在的做法是一个build.ps1负责清理、编译、拷贝资源、裁剪、打 zip一个package.iss或者对应的安装脚本引用那个 zip 的内容。这样每次发版就是改个版本号、跑一条命令人工干预越少出错的概率越低。刚开始写脚本会觉得比手动麻烦第三次发版之后就不会这么想了。