上周同事把他的笔记本抱过来，屏幕上就停在一个弹窗上：「安装程序无法继续。Microsoft Runtime DLL安装程序未能完成安装。」他装的是 VMware 12，系统是刚换的 Windows 11。他的判断很直接——运行库坏了，修运行库就行。我看了两分钟，跟他说了个反直觉的结论：这个弹窗里提到的 Microsoft Runtime DLL 大概率是背锅的，真正的矛盾是 VMware 12 这个安装包和 Windows 11 之间隔了整整一个世代，它连自己该装哪个版本的运行库都算不明白。后来他换成 VMware 16，双击、下一步、完成，一次过。这篇就把这个过程中我踩过的、查过的、验证过的东西完整写一遍，包括那个弹窗到底在说什么、日志该去哪里翻、为什么手动补运行库救不回来、以及换到 16 之后还有哪些坑在后面等着。
1. 那个"DLL安装程序未能完成"的弹窗，其实是个背锅提示
1.1 报错文本里藏着两层安装器
VMware Workstation 的安装包不是一个单纯的 MSI，它是一个自解压的引导程序（bootstrap），里面套着好几层东西：外层的引导器负责解压和调度，中间层是 VMware 自己的 MSI 主安装包，最里面还挂着几个微软的Visual C++ 可再发行组件包（VC++ Redistributable）。安装的时候，引导器会先检查系统里有没有满足条件的运行库，没有就顺手把自带的那个装一遍，装完再继续装 VMware 主体。
「Microsoft Runtime DLL安装程序未能完成安装」这句话，是最内层那个 VC++ 运行库安装器吐出来的失败信息。它的意思是：我尝试装运行库，但我没装成功。它并不代表系统里的运行库一定是坏的，只代表这次安装动作失败了。失败的原因可能有一堆：已经装了更高版本被拒、安装权限不足、Windows Installer 服务状态异常、被安全软件拦了、或者干脆是安装包里那个老版本运行库本身就不兼容当前的 Windows。
1.2 为什么它只说 DLL 却不肯报出文件名
很多人看到这句提示会本能地去搜msvcp140.dll、vcruntime140.dll这些名字，因为网上搜"找不到msvcp140.dll"的内容特别多。但注意，"找不到某 DLL"和"运行库安装器未完成"是两类完全不同的故障：
- 找不到 DLL：程序启动时动态加载失败，通常发生在软件已经装完、点了图标跑起来的那一刻。报错里会明确写文件名。
- 运行库安装器未完成：安装阶段就中断了，软件根本没装上，报错里不会有具体文件名，因为失败的是安装程序本身，不是被安装的程序。
所以照着"补 msvcp140.dll"的教程去操作，基本是白费功夫——你补上了运行库，VMware 12 的主安装包该失败还是失败。这是我在这个问题上花掉的第一个冤枉小时。
1.3 我遇到这个弹窗时的第一反应及其错误
我的第一反应是"那就装个最新的 VC++ 合集包呗"，从微软官方下了 Visual C++ 2015-2022 Redistributable，x86 和 x64 都装上，重启，再装 VMware 12。结果弹窗一模一样，一个字没变。
第二次尝试是卸载系统里所有的 VC++ 条目再重装，这一步更危险，后面会细说。这两次尝试的错误在于：我把"安装器失败"当成了"环境缺失"，而实际上它是"环境不匹配"。装再多运行库，也改变不了 VMware 12 的引导器本身对 Windows 11 缺乏认知这个事实。
2. VMware 12 落在 Windows 11 上，卡住的从来不止一处
2.1 版本时间线对不上，是根本矛盾
VMware Workstation 12 是 2015 年前后的产品，它的最后一个维护分支停在 12.5.x。而 Windows 11 是 2021 年发布的，两者中间隔着 Windows 10 的整个生命周期。这中间发生了不少事：驱动签名策略收紧、内核隔离（内存完整性）默认开启、Windows Installer 的行为调整、VC++ 运行库从 2013 一路演进到 2015-2022。
一个 2015 年的安装包，它内部的预检逻辑是照着当年的系统写的。它不认识 Windows 11 的版本号，于是可能走进一条"未知系统"的分支，或者更糟——走进一条本来给 Windows 7 准备的分支，去装一个只为 Windows 7 准备的运行库版本。
2.2 VC++ 运行库的"已存在更高版本"死结
这是最常见的根因。VMware 12 自带的运行库版本比较老，比如某个 2015 的初始版本。而你现在这台 Windows 11 上，很可能已经有某个软件（Office、显卡驱动、开发工具、游戏平台）装上了更新的 VC++ 2015-2022 版本。这两者在注册表里属于同一个产品系列的版本序列，新版装上去之后，老版安装器再想装就会返回"已有更高版本"这类状态码，而 VMware 的引导器把这个状态当成失败，直接中断整个安装流程。
关键在于：这个失败在逻辑上是误判。更高版本的运行库完全向下兼容，VMware 12 需要的那几个 DLL 早就有了。但引导器不会这么想，它只认自己那套返回值。
2.3 驱动签名与内存完整性检查
VMware Workstation 需要在宿主机上安装虚拟网络驱动和几个内核态组件。Windows 11 对驱动签名的要求比 Windows 7/8 时代严格得多，同时"内核隔离 - 内存完整性"这个默认开启的安全功能，会拒绝加载签名链不完整或者版本过旧的内核驱动。
VMware 12 时代的驱动签名方式，在 Windows 11 上大概率过不了这道关。表现可能是安装中途静默回滚，也可能是在安装日志里留下一行驱动注册失败的记录——但界面上你只看到那个 DLL 运行库的弹窗，因为失败的顺序是先跑运行库、再装驱动，运行库这关就没过去，后面的根本没执行。
2.4 老安装包的预检逻辑直接把自己判死
我拆开看过 VMware 12 安装包的内部结构，它的引导器里有一段系统版本判断。当它读到的系统版本高于它认识的最高值时，有两种可能的走向：一是保守起见直接报错退出，二是降级到某个兼容分支去处理。无论哪种，结果都不会好看。这解释了为什么有的人在 Windows 10 上装 VMware 12 一点问题没有——Windows 10 的版本号还在它的认知范围内。
3. 一次完整的定位过程：从 %TEMP% 里的日志翻到真实返回码
3.1 先把安装日志捞出来
安装失败后不要急着点关闭再去重试，先打开资源管理器，地址栏直接输入%TEMP%回车。VMware 的安装器在这里会留下几个日志文件，名字通常含有vminst、vmware、vmmsi这类字样；VC++ 运行库那一层会留下dd_vcredist_开头的日志，比如dd_vcredist_amd64_2015.log、dd_vcredist_x86_2015.log。
提示：如果 %TEMP% 里文件太多，按修改时间排序，取最近的几个。安装器每次运行都会重新生成一份，不用担心找不到。
这一步的价值在于：弹窗只告诉你"失败了"，日志会告诉你"在哪一步、因为什么返回码失败"。没有日志，后面所有操作都是猜。
3.2 日志里该盯哪几个关键字
打开dd_vcredist_*那几个日志，搜索这些字符串：
| 关键字 | 含义 | 常见诱因 |
|---|---|---|
0x80070666 | 已安装该产品的其他版本 | 系统里已有更新的 VC++ 版本 |
0x80070643 | 安装过程中发生致命错误 | 权限、服务状态、文件占用 |
3010 | 需要重启才能完成 | 运行库已装好，但需重启 |
1603 | 安装时发生致命错误 | 综合类，需往前翻上下文 |
Return value 3 | MSI 执行到出错点 | 具体失败动作在附近几行 |
我那次的情况是0x80070666，也就是典型的"版本冲突误判"。看到这个码，基本可以确定系统里的运行库没问题，问题在安装器的判断逻辑上。
3.3 手动补运行库之后，为什么还是不行
按日志给出的线索，我去确认了系统里确实已经装了更新的 VC++ 2015-2022，说明环境是好的。然后我手动把 VMware 12 需要的那几个组件单独装了一遍，全部成功。心想这下总行了吧，再跑 VMware 12 安装包——还是同一个弹窗。
原因在于，VMware 12 的引导器不会去检查"最终结果是否满足"，它只检查"我派出去的这个子安装任务有没有返回成功"。子任务因为版本冲突返回了非成功码，引导器就直接判定整体失败，哪怕实际环境完全够用。这是个设计上的缺陷，你在外面怎么修都没用。
3.4 用 /extract 拆包直装 MSI 的尝试与结果
绕开引导器的思路是：把内部 MSI 抠出来直接装。部分版本的 VMware Workstation 安装包支持/extract参数，命令行执行后会把内容解压到指定目录，里面能找到主安装的 MSI 文件，然后用msiexec直接安装。
这条路我试过，能往前走一段——主安装包确实开始跑了，但因为跳过了引导器的环境准备环节，后面在驱动注册和虚拟网络配置上又出了新问题，装了半截回滚了。而且这种方式装出来的环境，后续打补丁和卸载都会留下麻烦，我不建议在这条路上耗时间。
这里其实有个更根本的判断标准：如果你修一个问题需要绕开官方安装器，那说明这个版本的软件已经不该装在这台机器上了。换版本的成本，远低于跟一个 2015 年的安装包斗智斗勇。
4. 换成 VMware 16 之后，问题为什么自己就没了
4.1 支持矩阵：16 和 12 之间差的是一整个 Windows 世代
VMware Workstation 16 发布于 2020 年，后续的 16.2.x 分支明确把 Windows 11 纳入了宿主机支持范围。这意味着它的引导器认识 Windows 11 的版本号，会走正确的分支，带上正确的运行库判断逻辑和正确的驱动。
这件事的本质是：安装失败不是你的机器有问题，是软件的支持矩阵里压根没有这台机器的操作系统。查支持矩阵应该成为装任何虚拟化软件前的第一步——官网的产品文档里都有一张"Host Operating System Support"表格，看一眼比装三遍都省时间。
4.2 新安装包对运行库的处理方式变了
VMware 16 的引导器在处理运行库时更"聪明"：它会先检测系统里已装的版本，满足最低要求就跳过子安装，不再硬塞一个旧版本进去。这一改动直接消灭了0x80070666这个类别的失败。
即使真的需要安装，它带的运行库版本也是 2015-2022 系列，和 Windows 11 上的常见环境是同一序列，不会互相打架。
4.3 和 Hyper-V / VBS 共存这件事
这是另一个 16 相对 12 的巨大优势。Windows 11 默认开启了基于虚拟化的安全性（VBS）和相关虚拟化功能，这会在底层占用硬件虚拟化能力。VMware 12 时代的版本在这方面几乎没有适配，两个虚拟化层互相抢资源，结果往往是 VMware 报"无法启动虚拟机"或者性能异常。
从 15.5.5 之后的版本开始，VMware 才逐步具备了与 Windows 宿主机上的 Hyper-V 共存的能力，16 把这个能力完善了。代价是需要在 Windows 功能里启用"虚拟机平台"和"Windows 虚拟机监控程序平台"，性能上有一点损耗，但换来了能正常用。这个取舍在 12 上是根本没有选项的。
5. Windows 11 上装 VMware 16 的完整流程
5.1 动手之前先清场
换版本安装前，必须把旧版本清干净，否则会有残留的服务和注册表项干扰新版本。
- 用官方卸载程序卸载：控制面板里所有含 VMware 字样的条目，逐个卸载。
- 跑一遍 VMware Cleanup Tool：这是官方提供的清理工具，专门处理卸载不干净的情况。它会清理残留的服务、驱动和注册表项。这个工具在折腾过多次安装的机器上几乎是必需的。
- 手动检查残留服务：打开服务管理器，搜索
VMware，正常情况下应该一条都不剩。如果还有VMware Authorization Service这类条目，说明清理没干净。 - 确认 VC++ 运行库状态：设置里搜索"已安装的应用"，找 Microsoft Visual C++ Redistributable，确认有 2015-2022 的 x64 和 x86 两个版本。缺了就补上，不缺就别动。
- 重启：这一步别省。驱动和服务的卸载很多要重启才生效。
5.2 安装向导里真正需要留意的几个勾选项
VMware 16 的安装向导大部分一路下一步就行，但有几个地方值得停一下：
- 安装位置：默认在系统盘。如果 C 盘紧张，可以改到其他盘，但路径里不要出现中文和空格，这是虚拟化软件的老规矩。
- 增强型键盘驱动程序：建议勾上。它会改善虚拟机里的键盘输入体验，尤其是用到一些组合键和功能键的时候。卸载时这个驱动会跟着一起走，不用额外处理。
- 启动时检查产品更新：看个人习惯。如果你不喜欢它开机就联网检查，可以取消，需要时手动检查。
- 用户体验改进计划：随意，不影响功能。
安装过程中，Windows 可能弹出驱动安装的确认提示或者 UAC 授权窗口，都点允许。这个阶段如果被安全软件拦截，安装会静默失败，症状和之前的 DLL 弹窗很像——所以装的时候最好临时退出一下杀毒软件。
5.3 第一次打开软件要做的基础配置
第一次启动 VMware 16，它会要求输入许可证。这里只提一句：商业用途请通过官方渠道购买授权，个人学习可以先用试用模式把环境跑通再决定。
进入主界面后，建议先做这几件事：
- 编辑 - 首选项 - 内存：把预留内存调成"允许交换大部分虚拟机内存"，避免宿主机内存紧张时虚拟机直接崩。
- 编辑 - 首选项 - 更新：关掉自动更新检查，或改成手动，免得在工作时突然弹升级提示。
- 编辑 - 首选项 - 热键：确认 Ctrl+Alt 这个释放鼠标的默认组合键不会和你其他软件冲突。
6. 装好之后更容易翻车的几个地方
6.1 VMware Tools 装到一半提示脚本未能运行
「VMware Tools 继续运行脚本未能在虚拟机中成功运行」这个提示，几乎每个用虚拟机的人都见过。它的常见原因是宿主机和虚拟机之间的共享通道没建立好，或者虚拟机的 Linux 发行版里缺少编译 VMware Tools 所需的头文件和编译工具链。
处理思路分两层：如果是 Windows 虚拟机，直接卸载重装 VMware Tools，并且以管理员身份运行安装程序；如果是 Linux 虚拟机，先装好build-essential、对应的linux-headers（版本要跟内核匹配，用uname -r查内核版本），再重新安装 VMware Tools。头文件版本对不上是最隐蔽的坑——内核升级过但头文件没跟着升，编译就一定失败。
6.2 共享文件夹和拖拽突然失灵
拖拽失效和共享文件夹不可见，通常不是功能坏了，而是隔离设置把它关了。检查虚拟机设置 - 选项 - 客户机隔离，确认"启用拖放""启用复制粘贴"都勾上了。这个设置有时候会在虚机异常关机后被重置。
如果设置没问题但依然无效，重启一次 VMware Tools 服务通常能解决。在虚拟机里运行services.msc，找 VMware Tools 相关服务，重启即可。
6.3 网络连不通：NAT 还是桥接
网络模式选错是最常见的"虚拟机没网"原因。三者的差别值得记清楚：
| 模式 | 虚拟机拿到的地址 | 宿主机能否访问虚机 | 适用场景 |
|---|---|---|---|
| NAT | 由 VMware 的虚拟 DHCP 分配私有地址 | 可以，虚机访问外网走宿主机 | 只想让虚机上网，不对外提供服务 |
| 桥接 | 由物理网络的 DHCP 分配，和宿主机同网段 | 可以，同网段其他设备也能访问 | 需要虚机被局域网内其他机器访问 |
| 仅主机 | 私有地址，不连外网 | 可以 | 隔离测试，不需要外网 |
装开发环境或者做本地服务测试时，很多人默认用 NAT，结果局域网里的手机连不上，折腾半天才发现要改桥接。反过来，公司网络如果做了端口安全限制，桥接模式可能直接拿不到地址，这时候退回 NAT 就好。
6.4 虚拟化引擎那一栏到底怎么选
虚拟机设置 - 处理器里有个"虚拟化引擎"区域，三个勾选项：虚拟化 Intel VT-x/EPT 或 AMD-V/RVI、虚拟化 IOMMU、虚拟化 CPU 性能计数器。
- 第一项：只有在虚拟机里还要跑虚拟机（嵌套虚拟化）时才需要勾。勾了之后宿主机这边的虚拟化能力要透传进去，前提是 Windows 的"虚拟机平台"功能已启用。日常用虚拟机装个 Linux 做开发，不需要勾。
- IOMMU：配合直通设备用，普通场景不勾。
- 性能计数器：做性能分析时才用，日常不勾。
一个很常见的现象是：勾了第一项，虚拟机反而启动失败或者卡在开机画面。原因就是宿主机的 Windows 虚拟机监控程序平台没开启。两边的开关必须配对，缺一边就会出问题。
7. 关于版本和长期维护，我自己的几条习惯
我现在装任何虚拟化软件之前，会先做一件事：去官网翻一眼宿主操作系统的支持列表，确认当前系统在不在里面。这一次的教训就来自跳过这一步——看到"VMware 12 在 Windows 10 上一直好好的"，就想当然地认为 Windows 11 上也能用。实际上 12 和 11 中间隔的不是一个小版本，是整个操作系统世代。
第二条习惯是：遇到安装器报错，先翻日志再动手。日志在%TEMP%里，不需要任何额外工具，看到返回码之后再决定是修环境还是换版本，能省下大量试错时间。我这次的两次盲目尝试（补运行库、卸载所有 VC++）加起来花了快两个小时，而看一眼日志只需要三十秒。
第三条是关于清理工具。这类软件装过一次又卸过一次之后，机器上的残留比你想象的多。VMware Cleanup Tool 这种官方工具存在的意义就是处理这种情况，它不是"最后手段"，而是"换了版本重新装之前的标准动作"。
还有一条关于版本选择的经验：虚拟化软件和操作系统之间存在一个"甜蜜点"。太老的版本会在新系统上撞各种兼容性问题，太新的版本有时候又带着未修的 bug 和更严格的硬件要求。对 Windows 11 宿主机来说，VMware Workstation 16.2.x 之后的版本，或者 17 系列，是当前比较稳的选择。至于更老的 12、14、15 前期版本，如果不是有特别的历史包袱必须复现，没必要在上面耗时间。
最后补一个容易被忽略的细节：如果你打算在虚拟机里跑 Windows 11 作为客户机，宿主机的内存至少给到 16GB 才够用。Windows 11 客户机本身建议分配 4GB 以上，加上宿主机的开销，8GB 的机器会很吃力，表现就是频繁读盘、界面卡顿，你会以为是虚拟化软件的问题，其实是内存不够。
