用Visual Studio写完的程序，本机跑得好好的，拷到另一台机器上双击就弹窗：无法启动此程序，因为计算机中丢失MSVCP140.dll。尝试重新安装该程序以解决此问题。还有一种更含糊的，不给任何说明文字，只弹一个标题写「应用程序无法正常启动(0xc000007b)」的框。这两种报错的根子不一样，处理方式也不同，动手之前先把是哪种看清楚。
丢的那个文件名有含义
报错里出现哪个名字，就说明缺的是哪一层：
vcruntime140.dll C运行时，printf、memcpy、异常处理底子在这一层 vcruntime140_1.dll Visual Studio 2019起才有，装的是__CxxFrameHandler4 msvcp140.dll C++标准库，std::string、std::vector、iostream这些 concrt140.dll 并发运行时，用到ConCRT命名空间的才会依赖它 mfc140.dll MFC，用了MFC的工程才有
名字里的140不是版本号，是2015年引入的那套C++工具集的代号。从那往后，2017、2019、2022到Visual Studio 2026生成的程序，只要是用VC++编译的，依赖的dll文件名全是这一串带140的，一直没改过。所以看见140别去翻「VS2015运行库」这种老说法，那是历史包袱。
该装哪个版本的VC_redist
微软文档给的对应关系是：Visual Studio 2015配的工具集代号140，库文件版本落在14.0这一档；2017是141，走14.1x；2019是142，走14.2x；2022是143，走14.3x与14.4x。这几个版本的二进制兼容性微软从2015年起就做通了，VC Redist 14.16.27052、14.29.30157、14.40.33816、14.42.34433、14.44.35211，装最新的那一份就够，不用按年份挨个往下补。Visual Studio 2026那一档是14.50.35710，下载链接模板也跟着变了，17这一档形如https://aka.ms/vs/17/release/14.32.31332/VC_redist.arm64.exe，14.50以上要把中间那级目录换成18。
版本档位记不住也没关系，安装包自己会判断。真正容易翻车的是架构：x86、x64、arm64三个包互不通用。机器上要跑64位程序就装x64那份，还要跑32位程序就得把x86那份也装上，两边都得有。见过只装x64就把32位程序拖上去双击的，报错还是那一句话，查半天查不到点上。
先确认现场到底装了什么
别急着下载。装没装、装的哪一档，注册表里最直接：
reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64" /v Version reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86" /v Version
看Installed这一项，REG_DWORD 0x1才算真装上了。Version那一栏给的是十进制数字，换算成点分版本还得掰手指头，不如直接在资源管理器里对着C:\Windows\System32\msvcp140.dll右键看详细信息里的文件版本，一眼就有结论。另外多提一句，64位系统的System32放的是64位dll，32位dll要去SysWOW64里找，两个目录别看串了。
0xc000007b是位数混了
这个错误码展开是STATUS_INVALID_IMAGE_FORMAT，映像格式不对。开发机上很少撞见，因为环境被IDE配齐了；拷到别人机器才冒出来，多数时候是主程序64位、被加载进来的某个dll是32位。查的办法用VS自带的工具就够：
dumpbin /dependents yourapp.exe dumpbin /headers somedll.dll | findstr /i machine
第二条输出的machine那行，带(x64)字样的才是64位，写(x86)的就是32位。dumpbin不在PATH里的话，去VC\Tools\MSVC目录下找对应版本的bin\Hostx64\x64，或者干脆开Developer Command Prompt。懒得敲命令的，可以下lucasg那个Dependencies图形工具，打开exe直接给依赖树，哪个节点加载失败标得清清楚楚。这类报错折腾的从来不是运行库缺失，而是位数没对上。
还有一个来源：PATH环境变量里排着某个老软件的安装目录，那里面有同名的dll，于是被提前捞走。用Process Monitor过滤Result为NAME NOT FOUND的记录，加载路径一览无余。
装完运行库还是弹「丢失MSVCP140.dll」
如果装一半卡住，多半是安装本身没成功，退出码0x80070666表示机器上已有更高版本却在往低装，0x80070643那类多半是被别的安装占用了msiexec。完整日志在%TEMP%下形如dd_vcredist_amd64*.log的文件里，搜return value能看出是哪个包没成。
剩下几种情况更常见：一是发布包里混进了带D后缀的调试版dll，MSVCP140D.dll、VCRUNTIME140D.dll这几个只随Visual Studio安装，目标机上必然没有，发布前把配置切成Release重新编一遍；二是程序目录下自带了旧版本的同名dll，Windows的dll搜索顺序里应用程序所在目录排在System32之前，放错一个旧文件，装再多运行库也不管用；三是目标系统是Windows 7、Server 2008 R2这类老版本，缺Universal CRT，得先打KB2999226这套补丁再装运行库，Windows 10之后的系统自带UCRT，不需要这一步。
发布前就把它做掉，比事后补运行库稳
程序只在一两台机器上跑，装运行库就够了。要发给客户或者塞进镜像批量部署，更省事的做法是干脆静态链接，把运行时打进exe：项目属性 → C/C++ → 代码生成 → 运行库，把/MD（多线程DLL）改成/MT（多线程）。这一项只管当前项目和参与链接的静态库，第三方动态库还得照带。
用CMake管的工程，3.15之后在配置时把CMAKE_MSVC_RUNTIME_LIBRARY设成MultiThreaded，效果等价于/MT，不用逐个target去改。vcpkg装的包默认按动态链接编，要用静态版记得选x64-windows-static这个triplet，否则改了/MT照样链接不上。
排下来顺序基本固定：看丢的文件名定哪一层，查注册表确认机器上有没有对应版本，用dumpbin或Dependencies看依赖树里有没有位数不一致的，翻一遍发布包有没有带D后缀的调试版。四步走完，前面那两类报错基本当场就死。多数情况装最新一份VC Redist就能收尾，剩下的都是位数和加载顺序在作祟。数据截至2026年10月。