我注意到 Windows 10 似乎在实际开始安装更新之前花费了大量时间“准备安装更新”。我还注意到，在大部分时间里，进度条根本没有前进。就像刚才一样，它长时间停留在 10%（我没有记录，但如果我说它有几分钟，我认为我并不夸张）分钟)，随后跃升至 68%，与一次更新有关。
因为单凭文字显然不够清楚，所以这里是我所询问的特定 Windows 更新步骤的屏幕截图（点击链接查看完整屏幕截图，以下内容已被裁剪）。请注意，屏幕截图是在与我在第一段中讨论的更新会话不同的更新会话中拍摄的，因此完成百分比不同。
Windows 实际上做这么长时间了？什么样的“准备”需要花费如此长的时间？
请注意，我问的不是实际安装更新。
虽然促使我提出这个问题的特定时间是在虚拟机中，但我看到在实际硬件上运行的 Windows 10 也有类似的行为，所以我认为这不仅与它在虚拟机中运行的事实有关（尽管这可能是一个因素）。
答案1
我已经使用 ETW 提供程序捕获了 Windows 更新活动Microsoft-Windows-WindowsUpdateClient。
我在这里看到不活动准备：
我只看到Start和Stop和Download。Install
我现在使用 WPRUI跟踪磁盘 IO和CPU使用率在“准备安装更新”步骤中。
这里我可以看到 TrustedInstaller 正在忙于检查wcp.dll!CCSDirectTransaction::VerifyFileHashes更新数据的哈希值（）：
我看到磁盘 IO，其中 TRustedInstaller.exe 将数据复制到C:\Windows\WinSxS\Temp\InFlight\和C:\Windows\SoftwareDistribution\Download\。
因此基本上这个“准备安装”实际上是更新的安装，所以这是一个令人困惑的输出。
在 1809 中，微软修复了错误的状态并直接显示正确的“安装文本”：
答案2
据我了解，Windows 在此步骤中会创建一个卷影副本，尽管我无法找到任何来源来证实这一点。不过，我将提供以下观察结果：
- 为了使系统还原正常工作，必须在更新过程中的某个时刻创建卷影副本。
- 即便系统配置理想，影子副本创建也总是需要花费相当长的时间。此外，根据安装的 VSS 感知应用程序的数量，由于多个 VSS 写入程序会使其负责的数据处于静止状态，因此创建影子副本所需的时间可能比其他类似硬件配置更长。
- 由于这是一个磁盘密集型过程，计算机的存储子系统性能可能会进一步延长完成卷影复制的时间。
我怀疑这是仅有的在“准备更新”阶段执行的操作，但它将占用所需时间的很大一部分。
答案3
我认为最有可能的答案是 Windows 正在解压一些档案（甚至是下载它们），并且它肯定是在为下次启动准备系统，因此它不是正常启动而是继续更新。