★ FEATURED ARTICLE 前一阵给一台旧笔记本折腾多系统图省事用 VHD虚拟硬盘方式装了个 Windows。日常用着没什么事但一到系统更新或者应用商店下载安装包时就卡壳——进度条走到一半不动了要么直接报错回滚。一开始我以为是网络不好DNS、代理、防火墙折腾一圈最后才发现问题出在 VHD 系统的本地缓存上。这个坑在 VHD 场景里特别典型很多人把 VHD 当成普通分区一样用忽略了它的文件形态带来的行为和物理盘完全不同。这篇文章就是梳理一下当 Windows 跑在 VHD 里出现下载类问题时怎么一步步确认是不是本地缓存的问题以及怎么对症处理。不管你是拿 VHD 做多系统共存、企业统一镜像部署还是用差异磁盘做测试环境这套诊断思路都通用。我会尽量把每个命令、每个日志、每个判断节点的理由都讲清楚这样你遇到类似问题时不靠瞎猜按流程走就能把根因挖出来。1. 从现象到本质VHD 环境为什么容易栽在“本地缓存”上很多人第一次接触 VHD 系统时会有一个误解既然系统能从 VHD 正常启动进入系统后 C 盘看起来也完整那就应该和物理磁盘上的 Windows 没区别。这个想法对日常使用基本成立但一旦涉及大量读写尤其是下载这类需要频繁写入缓存的操作VHD 的特殊性就暴露出来了。1.1 VHD 到底是什么为什么下载问题会找上它VHDVirtual Hard Disk本质是一个文件整个虚拟磁盘的内容都装在这个文件里。Windows 引导时通过 bootmgr 加载 VHD然后把它当作一块真实磁盘来访问。也就是说你在这个系统里做的所有写操作——装软件、写临时文件、更新缓存——最终都会落到那个 .vhd 文件所在宿主的物理分区上。这中间多了一层“文件映射”的开销也引入了一类普通系统没有的问题动态扩展型 VHD 容量“只增不减”你删了文件VHD 文件本身不一定缩小。差异磁盘差分 VHD会把所有新数据写进子盘父盘数据永远不变。宿主分区剩余空间不足时VHD内的系统看到的分区大小还是满的但实际写入会失败。下载场景恰好是缓存放写最密集的操作之一。Windows 更新、应用商店、传递优化组件会先把数据写入本地缓存校验后再安装。如果缓存写入这层出了问题表现出来就是下载失败、卡进度、明明磁盘空间充足却报“磁盘空间不足”。所以遇到这类问题第一步要建立的认知是不要把 VHD 内的系统空间当成唯一判断依据必须结合 VHD 文件本身的状态、宿主分区的剩余空间、以及差异磁盘的结构来综合诊断。1.2 下载问题背后的三个“VHD 专属陷阱”我实际排查过的几台 VHD 系统下载问题基本逃不开下面这三个原因每个都踩过坑陷阱一动态扩展 VHD 占用只增不减。系统运行时间长更新补丁反复装、卸载VHD 文件会逐渐膨胀到接近最大大小。即使你在系统内把更新缓存清空了VHD 文件也不会自动回收这些空间。结果是宿主分区越来越挤最终导致后续更新下载时没有临时空间可用。陷阱二差异磁盘导致缓存反复重建。如果你用子 VHD 挂父 VHD 的方式做测试环境那么每次以子盘启动系统看到的 C 盘是“父盘内容子盘改动”的叠加视图。下载的缓存如果写在父盘指向的路径清理子盘时缓存会“复活”如果写在子盘子盘会无限膨胀。很多人在这个环节反复清理缓存无效就是没搞清父盘和子盘的写入方向。陷阱三VHD 系统的 I/O 性能瓶颈被误判成网络问题。下载时数据要经过网络栈写入本地缓存VHD 文件本身又可能存在碎片化、宿主磁盘老化等问题。当磁盘 I/O 跟不上时下载引擎会表现为超时、重试、进度倒退。这时候你看网络是通的以为是更新服务器的问题其实是本地写入卡住了。1.3 判断方向先分清是“VHD 的锅”还是“Windows 的锅”在实际动手前建议按这个顺序快速分流看 VHD 所在宿主分区剩余空间小于 5GB 优先处理宿主空间问题。看 VHD 文件类型固定/动态/差异用 diskpart 确认。看 Windows 事件日志中更新组件的报错代码判断是网络层还是本地层。检查 SoftwareDistribution 目录大小和文件数量是否异常膨胀。这个顺序能让你避免一上来就重装系统或换网络。大部分情况下问题都出在缓存目录异常、宿主空间不足这两个点上。2. 核心细节本地缓存放哪、怎么查、怎么拆提到“本地缓存”不同下载场景对应不同目录很多教程只说一个 SoftwareDistribution但实际操作里至少要看三处。把它们的位置、作用、异常特征搞清楚后面排查会快很多。2.1 三类缓存的主战场我把经常出问题的缓存路径整理成了一张表方便你对号入座缓存类型默认路径主要作用异常特征Windows 更新缓存C:\Windows\SoftwareDistribution\Download存放更新包下载的中间文件目录体积异常大、文件时间戳集中在失败时刻传递优化缓存C:\Windows\SoftwareDistribution\DeliveryOptimization点对点分发更新和商店应用目录残留大量未合并文件、占用超过 5GB应用商店与浏览器缓存C:\Users用户名\AppData\Local\Packages商店应用安装包、浏览器缓存单一子目录膨胀、商店装应用反复失败临时更新暂存C:\Windows\Temp安装阶段解压临时文件大量 .tmp 文件、安装程序无法释放注意 DeliveryOptimization 这个目录很容易被忽略。它是 Windows 10/11 的“传递优化”功能用来缓存从其他电脑获取的更新片段的。如果网络环境经常断开这个目录会积累一堆半截子缓存且不会自动清理干净。2.2 诊断工具链哪些命令和日志值得依赖诊断时我不建议装第三方工具Windows 自带的这几个就够用了diskpart查看 VHD 文件类型、大小、挂载状态以及执行 compact 操作。PowerShell快速统计缓存目录大小、查看系统分区剩余空间。事件查看器重点看 Microsoft-Windows-WindowsUpdateClient/Operational 和 Microsoft-Windows-DeliveryOptimization/Operational。DISM离线挂载 VHD 或清理组件存储。具体用法后面实操部分会展开。这里先说一句习惯性先看事件日志再动手删文件。很多人一看到 SoftwareDistribution 大就删但没确认是不是服务还在写删到一半可能引发文件锁冲突越搞越乱。2.3 看懂关键日志和报错代码事件查看器里 Windows Update 客户端日志有几个事件 ID 值得记住事件 ID含义常见伴随报错20安装失败0x80070070 磁盘空间不足25下载失败0x80240034 WU_E_INVALID_UPDATE31下载已开始无33下载完成无41更新安装完成无如果事件日志里频繁出现 25 且伴随网络类错误码优先怀疑网络和下载服务如果伴随 0x80070070 这类空间错误码直接转向检查宿主分区和 VHD 文件大小。还有两个常见错误码0x8024402C通常是 HTTP 请求被拒绝可能是网络代理或防火墙和 VHD 无关但会让下载失败容易和本地问题混淆。0x80070005访问被拒绝常见于缓存目录权限异常这种情况清空缓存前先检查 SoftwareDistribution 目录的安全属性。学会了看日志你就能把“网络问题”和“缓存问题”区分开这一步是整个诊断的关键分水岭。3. 实操过程从挂载 VHD 到清理缓存的完整诊断流程下面进入正题。我把整个处理过程拆成四个步骤按顺序执行即可。这里的示例环境是一台物理机上存放了一个动态扩展 VHD系统通过引导项启动进入 VHD 内 Windows下载更新时出现失败。3.1 第一步确认 VHD 形态与宿主盘剩余空间不管 VHD 能不能正常启动先确认 VHD 文件本身的状态。以管理员身份打开命令提示符或 PowerShell进入 diskpartdiskpart list disk select disk 0 list partition这里的 disk 0 是物理磁盘不是 VHD。要查看 VHD 文件信息用以下命令select vdisk fileE:\VHD\Win11.vhd detail vdisk输出里会显示 VHD 的类型是 Fixed固定还是 Dynamic动态以及当前文件大小和最大大小。如果显示“文件大小”接近“最大大小”说明 VHD 已经膨胀得很厉害这是下载失败的高危因素。接着检查宿主分区剩余空间。假设 VHD 在 E 盘就在 PowerShell 里执行Get-PSDrive -Name E重点看 Free 列。如果剩余空间小于 VHD 文件当前大小的 20%建议先给宿主分区腾空间否则一切清理动作都意义不大。这里有个很实际的判断逻辑VHD 内 Windows 的 C 盘剩余空间是基于 VHD 最大大小计算的和宿主实际空间无关。所以宿主空间不足时VHD 里看到的空间永远是假象。3.2 第二步定位缓存占用异常确认宿主空间没问题后进入 VHD 系统内部排查缓存目录。用 PowerShell 统计关键目录大小$paths ( C:\Windows\SoftwareDistribution\Download, C:\Windows\SoftwareDistribution\DeliveryOptimization, C:\Windows\Temp ) foreach ($p in $paths) { if (Test-Path $p) { $size (Get-ChildItem $p -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum {0} : {1:N2} MB -f $p, ($size / 1MB) } }正常情况下Download 目录应该只有几十 MB 到几百 MBDeliveryOptimization 通常不会超过 2GB。如果你发现 Download 目录达到了几个 GB或者 DeliveryOptimization 里堆了几万个文件基本就能锁定问题源了。这时候先不要急着删。看一看目录里最新文件的写入时间如果和报错时间吻合说明缓存写入失败时残留了大量半截文件。3.3 第三步针对 VHD 特性的修复方案确认缓存异常后按照下面的顺序处理。先停服务再清理。打开管理员 PowerShellStop-Service wuauserv -Force Stop-Service bits -Force Stop-Service DoSvc -Force这里停的是 Windows Update、后台智能传输、传递优化三个服务。不停服务就删文件大概率会碰到文件被占用删一半卡住甚至导致服务崩溃。然后清空缓存目录内容Remove-Item C:\Windows\SoftwareDistribution\Download\* -Recurse -Force -ErrorAction SilentlyContinue Remove-Item C:\Windows\SoftwareDistribution\DeliveryOptimization\* -Recurse -Force -ErrorAction SilentlyContinue如果清理某个子目录时提示“找不到路径”或“访问被拒绝”可以先给目录加 Everyone 的完全控制权限再继续但处理完记得恢复原权限。接着处理 VHD 膨胀问题。这里有个关键区别动态扩展 VHD 和 VHDX 的处理方式不同。如果文件扩展名是 .vhd旧格式diskpart 里执行 compact 是无效的需要用其他方式收缩。最省事的办法是先用工具清零空闲空间再转换或者重建 VHD。如果文件扩展名是 .vhdx新格式直接在 diskpart 里执行select vdisk fileE:\VHD\Win11.vhdx compact vdisk这个命令会把 VHDX 文件里已删除但未回收的块释放掉效果立竿见影。再有就是组件存储清理。VHD 系统里 WinSxS 目录很容易膨胀运行Dism.exe /Online /Cleanup-Image /StartComponentCleanup这个命令会安全清理被取代的更新组件为系统分区腾出一部分空间。VHD 场景下我建议至少每季度跑一次否则 WinSxS 天长日久能把 VHD 撑到上限。3.4 第四步重建缓存并验证清理完成后重启服务并触发一次强制更新检查Start-Service wuauserv Start-Service bits Start-Service DoSvc然后进入设置 - Windows 更新 - 检查更新或者用命令行触发wuauclt /detectnow /updatenow观察 5 到 10 分钟如果下载能正常推进说明缓存问题解决了。此时打开宿主分区看一下 VHD 文件大小如果 compact 生效文件体积应该比之前小了一圈。还有一个验证技巧下载过程中用任务管理器性能页签观察磁盘活动如果磁盘利用率长期接近 100%说明 VHD 所在物理盘的 I/O 是瓶颈后续考虑把 VHD 挪到更快的盘上。4. 常见问题与排查技巧实录做 VHD 系统诊断做多了遇到的问题也就那几个类型。我整理了一些典型的报错场景和对应处理思路供你按图索骥。4.1 常见报错与对应处理报错/现象根因倾向处理思路报 0x80070070但系统内 C 盘空间充足宿主分区空间不足或 VHD 已膨胀到上限先压缩 VHD腾出宿主空间下载卡在 0% 或 2% 不动传递优化缓存残留或 BITS 服务卡死停服务清理 DeliveryOptimization重启 BITS报 0x80240034更新元数据与缓存不匹配清空 Download 目录后重新检查更新更新下载完成后安装失败回滚缓存文件损坏或组件存储异常跑 DISM /StartComponentCleanup 后重试清理后下次下载又失败使用了差异磁盘子盘不断膨胀建议重建差异磁盘或转为完整 VHD4.2 几个独家避坑点这些是常规教程里不会写的东西但实际排查中经常遇到第一别在 VHD 运行时直接删宿主分区里的 VHD 文件。有人觉得系统从 VHD 启动只要不启动就不会占用但操作系统对 VHD 文件的锁定在引导阶段就建立了你直接在另一个系统里删文件会提示占用强删可能导致这个 VHD 报废。正确做法是在另一个 Windows 里用磁盘管理分离 VHD或者进入系统后通过 bootbcd 删除引导项再处理文件。第二清理 SoftwareDistribution 之前一定先停服务。我见过最惨的情况是有人直接在资源管理器里删除 Download 目录结果删到一半更新服务重新写入文件目录结构损坏最后整个 SoftwareDistribution 都罢工了。即便你只是手动清理也要遵守“先停服务、再删除、后启动”这个顺序。第三不要迷信“存储感知”。VHD 里如果开启了存储感知自动清理系统会定期执行整理和清理任务这在 VHD 场景下反而容易引发频繁的磁盘扩展收缩操作增加宿主文件碎片的可能性。建议在 VHD 系统里关闭存储感知手动控制清理节奏。第四注意差异磁盘的提交问题。如果你在用父-子 VHD 做测试建议在一个稳定节点上把子盘合并回父盘避免子盘无限增长。具体做法是用 diskpart 选择子盘后执行 Merge但这个操作要求父盘处于只读离线状态操作前一定要备份。第五日志才是最靠谱的“现场证人”。排查时我一般会先导出 Windows Update 客户端日志再动手清缓存。因为清完缓存再报错的话系统也不一定生成新的日志你只能靠猜测。养成“先取证、后清理”的习惯能省很多弯路。4.3 什么时候该考虑重建 VHD 而不是继续修虽然上面那些步骤能解决大部分问题但有些情况确实不适合继续修VHD 文件碎片化严重compact 之后宿主分区依然缓慢。差异磁盘层级过深父盘和子盘混乱到无法确认写入方向。系统组件损坏严重DISM 无法修复更新反复失败。VHD 身边没有可靠的备份而你折腾几天仍未解决。这种时候最省时间的方案是备份用户数据重新创建一个干净的 VHD把原来系统只读挂载作为数据盘提取资料然后重新部署环境。听起来粗暴但 VHD 本身就是文件形态重建的代价比物理机重装小得多也安全得多。最后分享一个我自己的习惯做 VHD 系统时把 VHD 文件放在一个单独分区不要和系统引导分区混在一起。这样诊断时无论怎么挂载分离都不会影响宿主系统的引导完整性。遇到缓存问题时我也会优先检查 VHD 所在盘的剩余空间和历史写入规律——很多看起来诡异的下载报错最终不过是宿主磁盘空间告急罢了。希望这个诊断思路能让你下次遇到类似问题的时候少走几步弯路。
阅读完成 · 觉得有帮助？
