作者：catcatyu（xxx@example.com）

问题现象

一开始我是从 Windows 的“设置 -> 系统 -> 可选功能 -> 查看功能”里添加 OpenSSH 服务器，界面一直停在“正在添加”，进度很慢：

后面不再等可选功能页面，改成用命令行安装和排查 OpenSSH Server：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

命令执行很慢，长时间没有进度。即使给当前 PowerShell 加了代理，例如：

1
2

$env:http_proxy="http://127.0.0.1:10809"
$env:https_proxy="http://127.0.0.1:10809"

也不一定有用。

原因是 Add-WindowsCapability 背后不是简单的 PowerShell 下载，而是通过 Windows Update、BITS、CBS/TrustedInstaller 这些系统组件去获取 FoD（Features on Demand）内容。当前用户的环境变量代理不等于系统服务账户代理。

排查过程

先看 WinHTTP 代理：

1

netsh winhttp show proxy

再看代理端口是否真的在监听：

1

Get-NetTCPConnection -LocalAddress 127.0.0.1 -LocalPort 10809 -State Listen

如果使用 v2rayN/xray，通常 HTTP 代理端口是 127.0.0.1:10809；如果使用 Clash，常见端口是 127.0.0.1:7890。

然后看 CBS/DISM 日志：

1
2

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "FCAcquirerWUClient|DownloadProgress|0x"
Select-String -Path C:\Windows\Logs\DISM\dism.log -Pattern "OpenSSH|Add-Capability|0x"

我这里看到的关键日志是：

1

FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]

也就是卡在 Windows Update 下载阶段，并不是 OpenSSH 本身安装慢。

还要检查 CBS 是否有待重启事务：

1
2

Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

如果返回 True，建议先重启。CBS 有 pending reboot 时，Add-WindowsCapability 很容易卡住、失败或重复下载。

正确的代理配置

以 127.0.0.1:10809 为例，管理员 PowerShell 执行：

1

netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;<local>"

再给 BITS 的三个服务账户设置代理：

1
2
3

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

重启相关服务：

1

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

如果之前已经卡了很久，建议直接重启系统。我的情况就是代理配置正确后仍然卡在 0%，重启清掉 CBS pending 状态后才成功。

重新安装 OpenSSH Server

重启后确认代理程序已经启动，端口能连通：

1

Test-NetConnection 127.0.0.1 -Port 10809

然后执行：

1

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

也可以继续使用 PowerShell：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

注意 capability 名称最后是 0.0.1.0，不要写成 0.0.1.。

安装后启用 sshd

安装成功后检查文件和服务：

1
2

Test-Path C:\Windows\System32\OpenSSH\sshd.exe
Get-Service sshd

启用并启动服务：

1
2

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

开放防火墙 22 端口：

1
2
3
4
5
6
7
8

New-NetFirewallRule `
  -Name "OpenSSH-Server-In-TCP" `
  -DisplayName "OpenSSH SSH Server (sshd)" `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -Action Allow `
  -LocalPort 22

如果规则已经存在，可以改成所有网络配置文件都生效：

1

Set-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -Enabled True -Profile Any

验证

查看服务：

1

Get-Service sshd

正常应该是：

1
2

Status   : Running
StartType: Automatic

查看监听：

1

netstat -ano -p tcp | Select-String ":22 "

正常会看到：

1

TCP    0.0.0.0:22    0.0.0.0:0    LISTENING

局域网其他机器连接：

1

ssh 用户名@Windows主机IP

例如：

1

ssh fjh1996@192.168.1.10

总结

这个问题的关键点是：

1. http_proxy / https_proxy 只影响当前进程，不足以让 Windows Update 服务走代理。
2. Add-WindowsCapability 背后依赖 Windows Update、BITS 和 CBS。
3. 需要同时配置 WinHTTP 代理和 BITS 服务账户代理。
4. 如果 CBS 已经有 RebootPending，先重启，否则可能一直卡在 DownloadProgress: [0 / 100]。
5. 安装成功后还要启动 sshd 服务并检查防火墙规则。

最终有效流程就是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;<local>"

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

本文2026-04-28首发于猫猫鱼的小窝，最后修改于2026-04-28

作者：catcatyu（xxx@example.com）

问题背景

宿主机 Windows（VMware Workstation 17.6.0），虚拟机 Windows 7 SP1 32位。遇到两个问题：

1. 宿主机无法连接虚拟机（ping 不通）
2. 修复网络后，VMware Tools 的复制粘贴功能不工作

以下是完整的排查过程。

问题一：宿主机无法连接虚拟机

现象

虚拟机 IP 为 192.168.191.129（NAT 模式），从宿主机 ping 100% 丢包：

ping 192.168.191.129
请求超时。
请求超时。
数据包: 已发送 = 2，已接收 = 0，丢失 = 2 (100% 丢失)

排查过程

检查宿主机网卡状态：

1

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, MacAddress -AutoSize

Name                          InterfaceDescription                       Status      MacAddress
----                          --------------------                       ------      ----------
以太网                        Intel(R) Ethernet Connection (22) I219-LM  Up          F4-F1-9E-42-D8-DD
VMware Network Adapter VMnet1 VMware Virtual Ethernet Adapter for VMnet1 Not Present 00-50-56-C0-00-01
VMware Network Adapter VMnet8 VMware Virtual Ethernet Adapter for VMnet8 Not Present 00-50-56-C0-00-08

关键发现：VMnet1（Host-Only）和 VMnet8（NAT）状态都是 Not Present，AdminStatus: Down。

再看 IPv4 地址分配：

1

Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength -AutoSize

InterfaceAlias              IPAddress   PrefixLength
--------------              ---------   ------------
以太网                      10.30.17.50           24
Loopback Pseudo-Interface 1 127.0.0.1              8

宿主机只有物理网卡有 IP，VMware 虚拟网卡完全没有加载，自然没有到 192.168.191.x 网段的路由。

同时 VMware NAT Service 虽然在运行，但网卡驱动本身没有加载：

1

Get-Service -Name 'VMware*' | Format-Table Name, DisplayName, Status -AutoSize

Name                   DisplayName          Status
----                   -----------          ------
VMware NAT Service     VMware NAT Service  Running
VmwareAutostartService VMware 自动启动服务  Stopped

根因

VMware 虚拟网卡驱动未正确加载，网卡处于 Not Present 状态。NAT Service 虽然在跑，但没有对应的虚拟网卡承载流量。

解决方法

打开 VMware Workstation → Edit → Virtual Network Editor → 点击 “Restore Defaults”（需要管理员权限）。这会重新创建 VMnet1/VMnet8 并重装虚拟网卡驱动。

如果不行，还可以：

• 在设备管理器中检查是否有被禁用或带感叹号的 VMware 网卡，右键启用或更新驱动
• 修复安装 VMware Workstation（运行安装程序选 Repair）

恢复后虚拟机 IP 变为 192.168.78.128，网络连通。

问题二：VMware Tools 服务启动失败

现象

网络恢复后，SSH 进入虚拟机发现 VMware Tools 没有正常工作。

排查过程

通过 SSH（paramiko）远程执行命令检查（注意：这台 VM 是 Windows 7，不是 Linux）：

1

sc query VMTools

SERVICE_NAME: VMTools
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 183 (0xB7)

VMTools 服务状态为 STOPPED，退出码 183（ERROR_ALREADY_EXISTS）。

同时检查进程：

1

tasklist | findstr /i vmtoolsd

发现 vmtoolsd.exe（PID 1868）在用户会话（Console Session 1）里运行着——这是用户态的托盘进程，但系统服务层面的 VMTools 没有启动。

根因

之前异常退出后残留了用户态 vmtoolsd.exe 进程，占用了资源，导致系统服务启动时报错 183（ERROR_ALREADY_EXISTS，资源冲突）。

解决方法

1
2
3
4
5

:: 先杀掉残留的 vmtoolsd 进程
taskkill /f /im vmtoolsd.exe

:: 然后重新启动服务
net start VMTools

执行后服务恢复正常：

SERVICE_NAME: VMTools
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0

问题三：复制粘贴仍然不工作

现象

VMTools 服务正常运行后，宿主机和虚拟机之间的复制粘贴仍然不可用。

排查过程

第一步：检查用户态进程

复制粘贴功能依赖两个 vmtoolsd.exe 进程：

• 系统服务进程（Session 0）：负责基础的 Guest-Host 通信
• 用户态进程 vmtoolsd.exe -n vmusr（桌面会话）：负责加载 dndcp.dll 插件处理剪贴板同步和拖拽

检查发现只有系统服务进程在运行，用户态进程缺失。

确认插件文件存在：

1

dir "C:\Program Files\VMware\VMware Tools\plugins\vmusr"

dndcp.dll（拖拽和复制粘贴插件）文件完好。

注册表中 VMware User Process 启动项也存在，但重启后用户态进程就是没有自动拉起。

第二步：尝试手动启动用户态进程

由于 SSH 会话处于 Session 0（服务会话），直接 start 无法在 Session 1 的桌面上创建进程。通过创建批处理文件 + 计划任务的方式在用户桌面会话中启动：

1
2
3

echo start "" "C:/PROGRA~1/VMware/VMware Tools/vmtoolsd.exe" -n vmusr > C:/vmusr.bat
schtasks /create /tn "StartVMusr" /tr "C:/vmusr.bat" /sc once /st 00:00 /f /rl highest
schtasks /run /tn "StartVMusr"

启动后确认两个进程都在运行：

• PID 1384 — Services 会话（系统服务）
• PID 2772 — Console Session 1，ADMIN 用户（用户态）

但复制粘贴仍然不工作，而且重启虚拟机后用户态进程又消失了。说明手动拉起只是临时方案，根本原因在别处。

第三步：检查 VMX 配置

检查虚拟机的 .vmx 配置文件（D:\Windows 7\Windows 7.vmx），发现只有：

isolation.tools.hgfs.disable = "FALSE"

缺少 copy/paste 相关的配置项。在 VMware Workstation 17 上，如果没有显式启用，默认可能是禁用的。

通过 rpctool 在 Guest 内确认 isolation 状态均为 UNSET，说明 VMX 层面没有显式配置。

根因

两个原因叠加：

1. VMX 配置文件中缺少 isolation.tools.copy.disable = "FALSE" 和 isolation.tools.paste.disable = "FALSE" 的显式配置，在 Workstation 17 上默认行为可能是禁用
2. 由于 isolation 配置缺失，用户态 vmtoolsd -n vmusr 进程无法正常自动启动（负责剪贴板同步的进程缺失）

也就是说，用户态进程不自动启动的根本原因就是 VMX 里缺少 isolation 配置。加上配置后，重启虚拟机用户态进程就能正常自动拉起了。

解决方法

关闭虚拟机，在 .vmx 文件中添加以下三行：

isolation.tools.copy.disable = "FALSE"
isolation.tools.paste.disable = "FALSE"
isolation.tools.dnd.disable = "FALSE"

然后重新启动虚拟机。启动后验证：

• VMTools 服务正常运行（RUNNING）
• 用户态 vmtoolsd -n vmusr（Console Session 1）自动启动——之前一直无法自启的问题也一并解决
• 复制粘贴功能恢复正常

总结

本文2026-04-16首发于猫猫鱼的小窝，最后修改于2026-04-16