升级 VMware Workstation 的九九八十一难：幽灵虚拟机、1603 报错和手工装 Tools
升级 VMware Workstation 的九九八十一难：幽灵虚拟机、1603 报错和手工装 Tools
一切的开始非常简单：VMware Workstation 曝出了两个虚拟机逃逸与穿透漏洞 CVE-2026-59346 与 CVE-2026-59347。因为使用中涉及在虚拟机里对陌生软件做测试的情况，虚拟机逃逸与穿透这种级别的安全漏洞是注定无法接受的，只得老老实实从 VMware® Workstation 17 Pro 升级到最新的 VMware® Workstation Pro 26H1u1。
然而，在通往新版本的路上，全是坑啊。
PS：如果你是被 VMware Tools 安装失败回滚卡住的，可以直接跳到第七难的VMware Tools 手动安装流程。
第一难：博通 VMware 下载的迷宫漫游
众所周知，VMware 被博通收购了，所以整个支持与下载体系全部搬迁进了博通的统一门户，下个安装包必须要登录博通统一账户。
我打开登录页面，密码管理器自动填充了账号密码，点击登录——“用户名或密码错误”。
扯淡吧，密码管理器还能把密码记错的？那就尝试找回密码，博通告诉我：“你压根就没注册过”，切，离谱他妈给离谱开门——离谱到家了，我TM没注册过，那我上次怎么登录下载的安装包，你给我删了就删了呗，瞎说什么。淡定淡定，重新注册一下。
好不容易重新注册进去了，不得不说，博通的网站妥妥一个现代反人类 UI 的集大成者。你必须在支持门户、软件分发、产品授权树状图里一层层翻找，经过数个形似企业级采购合同的确认页面，最终在某个隐蔽的二级子目录里才找到 Workstation Pro 26H1u1 的下载按钮。这破玩意有多隐蔽呢，隐蔽到我写文时想去截个图，我居然就找不到地方了。
第二难：Session 0 里的“幽灵虚拟机”
再次众所周知，升级安装前必须关闭所有运行中的虚拟机。打开 Workstation 界面，所有机器都显示为“已关闭”，列表里一片祥和。但当我安装时，不出意外地提示仍有虚拟机正在运行。
调出终端，敲下查询命令：
cd "C:\Program Files (x86)\VMware\VMware Workstation"
.\vmrun.exe -T ws list
注意这里是因为我这时候用的是16 pro，新版后路径应该用cd "C:\Program Files\VMware\VMware Workstation"了
控制台返回：Total running VMs: 0。
就瞎扯吧，那台本地用来跑 agent 的 Ubuntu 服务器绝对还活着呢，直接强杀进程容易导致磁盘损坏或残留死锁文件。不过这个倒是好解决，直接通过 SSH 关机就好了：
sudo poweroff
这是 Windows 的服务隔离机制导致的：Workstation 的虚拟机开机自启是通过系统服务
VMware Autostart Service实现的，它是以SYSTEM身份驻留在 Session 0（后台系统会话）层级，而桌面客户端是运行在Session 1（用户会话）层级。导致当前登录用户下的vmrun根本“看”不到启动的虚拟机。这个机制槽点实在是太多，虽然我明白这样设计的原因，这样设计下，重启宿主机后，不需要登录宿主机，虚拟机也会实现自启，但这样设计，也意味着用户如果让他的虚拟机开机自启了，那就无法使用客户端控制他的虚拟机了，必须要手动关机才行。你问要是用户无法手动关机时咋办？那就只能直接杀进程强关了。
第三难：VMware Workstation 中文界面消失，汉化补丁还挑 Build 版本
安装倒是没啥新状况，顺利安装完成了，但 VMware Workstation 的中文界面没了，一启动就是全英文。倒不是说英文界面看不懂、没法用，只是母语界面更符合直觉，日常扫一眼配置参数时中文界面用起来更舒服一点。
本以为和以前一样改改配置即可，于是开始常规操作：
- 在快捷方式目标末尾追加
--locale zh_CN； - 在
%APPDATA%\VMware\preferences.ini和全局config.ini中硬编码pref.locale = "zh_CN"。
重启软件，哎，毫无反应，依旧是纯英文。
简单搜了一下找到了一个 26.0.0.1810 版本的 messages\zh_CN 语言文件夹，看起来版本差距不大，直接复制进新版的安装目录试试，再次尝试启动——依旧无效啊。
去检索了一番：合着博通从 17.6 起彻底剥离了外部文本字典加载的多语言机制，官方表示以后“English only”。新版本的多语言不再读取外部 .vmsg 语言文件，而是直接二进制主程序写死。这意味着针对上一个 26.0.0.1810 的汉化资源，面对版本号为 26.0.1.25688693 的新版本，虽然版本号就只差了0.0.1也会完全无效。
既然官方不做人，那只能转向大家的智慧了。去 52pojie（吾爱破解）论坛翻找了一下，果然有大佬针对制作了新版的内存劫持补丁与资源文件。按照说明做了文件替换之后，熟悉的中文界面终于回归了。
第四难：VMware Tools 安装失败回滚，旧版本怎么也卸不掉
宿主机里的安装升级搞定，接下来就要把虚拟机里的 VMware Tools 也升到对应版本，结果撞上了经典的 VMware Tools 安装失败回滚。
挂载虚拟光盘，在 Windows 虚拟机里双击 setup.exe，进度条欢快地读到一半，突然开始“正在回滚操作”，随后弹出一个冷冰冰的错误窗口，逼逼叨叨说了一堆，大概意思就是：
VMware Tools 安装向导提前结束。由于出现了错误，所以未能完成安装。
没有错误代码，没有原因，也没给任何指引，就通知你一句：「没安装上，现在自动结束安装了。」
界面上不写原因，那就只能去日志里自己找。按 Win + R 输入 %TEMP% 回车，找到 vmmsi.log_20260908_111111_Failed.log，直接往上翻，找日志里最后出现的安装失败标识 Return value 3（Return value 3 只是标记这个没装上，真正导致出错的原因得看它上面几行的记录）。
还好日志里倒是写的挺清楚：
Action ended 10:57:15: RemoveExistingProducts. Return value 3.
Property(S): WIX_UPGRADE_DETECTED = {55F0F698-8B00-40BF-8583-A16452EC3FF9}
新版装不上，是因为旧版本的 VMware Tools 卸载不掉。
新安装程序识别到了旧版本，在执行升级前的卸载动作时，旧版的卸载进程跑一半就崩了，因为旧版卸载失败，所以整个新版安装自动回滚。
- 我先尝试通过 Win11 的设置-应用-安装的应用卸载：卸载程序的进度条跑了不到四分之一就直接自己消失了。
- 然后尝试在管理员权限的 CMD 下用
msiexec /x {55F0F698-8B00-40BF-8583-A16452EC3FF9} /qb强行卸载：没区别，还是卸载一半就炸了。
第五难：旧版 MSI 卸不掉，去打捞微软已下架的强制卸载工具
额，行吧，这种底层 MSI 无法卸载也不是第一次见了，这时候最管用的是微软官方的强制卸载工具：Microsoft Program Install and Uninstall Troubleshooter。
打开微软支持页面准备下载，结果发现：微软大刀部又发力了，微软已经移除了该工具的下载链接，官方建议用户去 Windows 设置里使用新版 windows 疑难解答，但新版疑难解答根本没有强制卸载工具啊！！！
好在我隐约记得家里那台做 NAS 的小主机里有这个工具。立刻开远程桌面连过去，但是问题是，我忘了这个工具我给放什么地方了，而且我记得他实际的名字应该不叫 Microsoft Program Install and Uninstall Troubleshooter.exe，于是只能用 everything 在茫茫多的文件里用关键字 Uninstall 慢慢翻，好再终于找到了，原来叫 MicrosoftProgram_Install_and_Uninstall.meta.diagcab。
然后我犯了一个错误：我刚才用的是宿主机的远程桌面，因为 VMware Tools 还没有被正确安装，所以现在我无法快捷地将宿主机内的卸载工具复制到虚拟机里，于是只能重新用虚拟机里的远程桌面去家里电脑再复制一次。
运行工具，选择“卸载”，手动指定产品识别码 {55F0F698-8B00-40BF-8583-A16452EC3FF9}。工具发挥正常，在磨磨唧唧半个小时后，彻底扬了整个旧版 VMware Tools，重启虚拟机，「设置」->「应用」->「已安装的应用」，列表中不再显示旧版 VMware Tools 看来彻底卸载掉了。以防万一再顺手清理掉 ToolsInstallerCache 安装缓存。
rmdir /s /q "C:\Program Files\Common Files\VMware\ToolsInstallerCache"
第六难：VMware Tools 1603 错误，被 Win11 24H2 二次拦截
清干净旧版，我满心欢喜地再次双击新版安装包，然而在进度条接近末端时——熟悉的“正在回滚操作”再次回归，惊不惊喜，意不意外。
我……（以下省略对博通的几千字友好问候）难道刚才没卸载干净？
再次查看 %TEMP%\vmmsi.log，这次倒是没有了 RemoveExistingProducts，取而代之的是一个新的问题：
CustomAction VM_CopySupportFiles returned actual error code 1603
Action ended 11:40:15: InstallFinalize. Return value 3.
Property(S): SupportFilesDir = C:\Users\admin\AppData\Local\Temp\...
Property(S): VERSIONNTBUILD = 26200
这就是大家常说的 VMware Tools 1603 错误，最最没用的一句报错，因为相当于摊手告诉用户“装失败了，为什么失败我不知道”。
不过结合上边的日志，还是搞懂发生了什么，当前的虚拟机系统是 Windows 11 24H2。我们可爱的微软收紧了安全隔离策略：
- MSI 在完成阶段由
SYSTEM权限服务在后台调用文件操作； - 试图向当前普通用户的临时目录（
AppData\Local\Temp）释放并执行临时的 DLL 文件； - 这种“高危”行为触发了 Windows 的跨会话隔离与“智能”防护策略，于是就被拦截并拒绝执行了。
我先尝试在系统安全中心中关闭实时保护和篡改防护，可是拦截依然存在；
再尝试在管理员 CMD 中通过 set TEMP=C:\Temp 重定向一个临时路径，避免放在用户的临时目录下，虽然系统这次允许了释放临时的 DLL 文件，但是执行还是被拦截了。
第七难：VMware Tools 手动安装——纯手工装驱动、注册服务
得得得，你系统搞一堆“安全”拦截，那我就索性彻底抛弃 MSI 的自动化安装流程，直接回到最纯粹的系统底层操作：提取驱动和程序本体，用系统命令手动安装驱动和部署程序文件。
挂载虚拟光盘（我这里的盘符是 D:），先尝试解包：
D:\setup.exe /a /p C:\VMToolsExtract
屏幕弹出一个窗口告诉我：setup.exe 支持 /a（管理模式解包），但不认 /p 这个路径参数，这倒是触及我的知识盲区了，于是跑去问了一下机智的 ChatGPT，它教我修改参数传递方式，利用 /v 将传递路径参数：
D:\setup.exe /a /v"TARGETDIR=C:\VMToolsExtract /qn"
注意：这条命令是静默执行的。需要自己去 C:\VMToolsExtract 盯着，文件不再增加就说明解包完了。终于，所有的驱动原文件（.inf / .sys）和 vmtoolsd.exe 整整齐齐地摆在我的眼前了。
接下来就是纯手工的 VMware Tools 手动安装环节：
1. 用 pnputil 强制安装所有驱动
遍历并强制安装所有解包出来的 .inf 驱动文件：
pnputil /add-driver "C:\VMToolsExtract\*.inf" /subdirs /install
意思是让系统把目录里所有 .inf 驱动全部找出来并强制装进系统驱动库——手动替代 MSI 安装程序做驱动安装。
回车后，控制台开始快速滚动，安装所有的驱动。不过这个东西没很明确的结束提示，只能多等一会儿确保全部安装上了。
PS：安装时十几秒后屏幕会瞬间黑屏并闪烁刷新了一次，不要慌，这是安装 SVGA 3D 显卡驱动时的正常情况。
2. 部署程序文件并注册 VMTools 后台服务
把程序文件手动复制到默认的安装目录，并通过服务控制器手动建一个服务来每次自动启动：
:: 把程序文件复制到默认目录
mkdir "C:\Program Files\VMware\VMware Tools"
robocopy "C:\VMToolsExtract\VMware\VMware Tools" "C:\Program Files\VMware\VMware Tools" /E /IS
:: 注册系统级后台服务并启动
sc create "VMTools" binPath= "\"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe\"" start= auto DisplayName= "VMware Tools"
sc description "VMTools" "VMware Tools 核心后台管理服务"
sc start "VMTools"
sc create 这条相当于手动帮系统把 VMware Tools 的后台服务登记进服务列表，binPath 指向主程序，start= auto 表示开机自启，把 MSI 安装程序原本该做的事自己手做一遍。
最后控制台返回了明确的 [SC] StartService SUCCESS 就说明成功了。
3. 自启动 vmusr 会话进程（分辨率自适应与剪贴板）
分辨率自适应缩放与宿主机之间的剪贴板双向同步，依赖的是运行在用户桌面会话中的 vmusr 实例。需要将其写入注册表启动项：
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "VMware User Process" /t REG_SZ /d "\"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe\" -n vmusr" /f
:: 立即启动
start "" "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
回车执行，瞬间虚拟机屏幕自适应拉伸铺满了整个宿主机显示区域。尝试一下在主机和虚机之间拖动文件、复制文本，映射虚拟磁盘，这会儿都可操作了，完美。
现在的状态：机器能正常用，分辨率自适应、剪贴板双向同步、文件拖拽、虚拟磁盘映射全部正常，唯一的小问题是每次虚拟机开机都会弹一次“VMware Tools 不是最新版本”。这个可以点「不再提醒我」解决问题。
总结与吐槽
整个升级过程，槽点多到不知从何吐起：
- 商业收购带来的抛弃：博通接手后的产品完全偏向企业级大型客户，号称免费对个人，但实际个人用户用起来难度极大。不仅下载页面如同天书迷宫，连沿用多年的原生多语言支持也被一刀切掉，徒增社区汉化精力与用户的使用难度。
- 被安全机制与陈旧架构夹击的 MSI：现在的 Windows 11 在虚拟化安全、核心进程隔离和进程权限控制上越来越严(S)格(B)；而这些上古软件的 MSI 安装包却依然固守着十几年前的做法——喜欢在安装过程中跨线程调用用户 Temp 目录里的动态链接库，那一定要出事啊。
- 最可靠的永远是底层工具：只有看日志、翻注册表，最基础的
pnputil和sc不会让人失望，以及老工具就是好用（可惜大都被砍了）。 - 问题彻底解决了吗？并不：估计是手动安装时漏了什么配置文件没改，每次虚拟机开机后就会提示 VMware Tools 不是最新版本，需要更新。但执行更新就会装一半后触发自动回滚，日志里显示已经安装了同版本，不过这个倒是好办，直接点「不再提醒我」就可以解决。
