1. 先弄明白为什么 .NET Framework 3.5 在 Win10/Win11 上总是装不上我见过太多人在这件事上兜圈子从网上下一个dotnetfx35.exe双击进度条卡到一半弹出安装未成功发生了未知错误然后开始怀疑是不是系统坏了。其实绝大多数情况下系统一点毛病没有是我们对 .NET Framework 3.5 的安装模型理解错了。它和 4.8 完全不是一类东西用装 4.8 的思路去装 3.5必然撞墙。先把最关键的一层认知摆出来.NET Framework 3.5 是 Windows 的一个按需功能Feature on Demand不是一个传统意义上的独立安装包。在 Windows 8 之后的所有系统里微软把这个功能做成了功能开关——镜像里带着它的组件文件但默认是关的。你要做的不是安装而是启用。这两个动作在系统底层走的是完全不同的代码路径前者是运行一个 MSI/EXE 安装器后者是让组件服务CBS从本机组件存储或者指定的源路径里把包展开注册。很多人第一次失败就失败在启动了错误的入口。他们下载的是一个 2008 年左右的dotnetfx35.exeSP1 完整包约 231MB x86 / 全文上 GB 的那种 combined 包这个包在 Windows 10 上跑起来会先做一次版本检测检测到系统里已经存在 .NET 4.x于是它认为我该干的事已经有人干了直接报错退出或者装到一半发现要先装 2.0/3.0 的组件而中断。这不是包坏了是这个包本来就不为 Win10 设计。1.1 CLR 是并行共存的4.8 装好了不代表 3.5 在位这是最容易被误解的一点说得通俗一些.NET Framework 2.0/3.0/3.5 共用同一套运行时内核叫CLR 2.0而 .NET Framework 4.x 用的是CLR 4.0。两套运行时是可以并存在同一台机器上的互不覆盖、互不替代。系统不会因为你有 4.8 就自动帮你把 2.0 那套也装上。那么一个程序到底走哪套运行时由程序自己的配置文件决定。老程序编译出来带的是supportedRuntime versionv2.0.50727/系统一看要 CLR 2.0就会去找 2.0 那一套找不到就弹那个经典的提示框让你去装 .NET Framework 3.5。所以哪怕你 4.8.1 装得再全一个 2010 年写的上位机软件照样会拦住你。我在工厂现场碰到过一模一样的事一台新配的工控机4.8 装齐了客户拿来的设备调试软件死活起不来报错信息里明明白白写着 v2.0.50727。折腾了一下午最后就是启用 NetFx3 解决的。所以第一件事先确认你到底需不需要它——看你那个报错程序提示的框架版本号别听网上说3.5 老掉牙了不用装。目标框架运行时内核与 4.x 能否共存典型报错特征.NET Framework 2.0CLR 2.0可以提示 v2.0.50727.NET Framework 3.5CLR 2.0可以提示需要安装 .NET Framework 3.5.NET Framework 4.8CLR 4.0可以提示 v4.0.303191.2 三个必须先确认的前置条件动手之前花两分钟把这三件事确认了能省掉后面一半的无效折腾。第一确认系统版本和体系结构。Win10 和 Win11 都是通过Windows 功能对话框或者 DISM 来启用 NetFx3命令完全一致。x64 系统上装的 3.5 同时提供 32 位和 64 位组件不需要你分别装。第二确认你有没有可用的组件源。这是最核心的变量。如果你的机器能连到微软的更新服务DISM 可以自己去下载如果连不上内网、隔离环境、更新被策略关掉就必须提前准备好镜像里的sources\sxs目录。没有源文件任何命令都只会告诉你找不到源文件。第三确认当前没有未完成的挂起事务。如果之前失败过一次系统里可能留了个重启后继续的标记。带着这个标记去重试十有八九还是失败。判断方法后面第五章会细说。1.3 一个反直觉的结论能联网反而不一定顺利新手会以为联网就万事大吉实际上企业环境和精简系统上恰恰相反。很多公司的机器被域策略管着更新指向内网 WSUS而 WSUS 上根本没同步 NetFx3 的语言包组件DISM 去要WSUS 说我没有就返回 0x800F0954。还有一些民间精简版镜像制作者为了压缩体积把sxs目录整个删了同时把组件存储里的冗余包清理掉了这种情况下你联网也救不回来必须换镜像或者用外挂 CAB 的方式硬灌。所以我在下面会把在线和离线两条路分开讲你先按自己的环境对号入座。2. 错误码就是路标先定位卡在哪一环再决定动手方向我特别不建议看到报错就一顿乱操作——关服务、删注册表、跑各种一键修复这些东西在没有定位之前执行只会把现场搞乱让后面真正的排查更难做。DISM 和组件服务返回的错误码其实是相当诚实的每个码基本对应一个明确的失败环节。先读码再动手。2.1 高频错误码对照表下面这张表是我自己踩坑加收集同事案例整理出来的覆盖了 90% 以上的现场情况。看到码先在这张表里定位再去对应的章节找解法。错误码真实含义最常见的触发场景优先处理方向0x800F0906无法下载所需的源文件更新服务被禁用、网络不通改用离线源或修复更新通道0x800F081F找不到源文件镜像 sxs 缺失、路径写错换正确的源路径0x800F0954无法从更新服务获取被策略限制域环境、WSUS 指向内网临时改注册表或走离线源0x800F0907组策略明确禁止按需功能联网获取企业安全基线用离线源绕过联网获取0x800F0922组件存储不可用或空间不足系统盘快满、组件存储损坏清理空间 修复组件存储0x8024000B更新组件操作被取消更新服务状态异常、锁文件重启相关服务后重试0x80073712组件存储本身已损坏长期未打补丁、非正常关机先修复映像再启用功能看表的顺序一定是从上往下对别看到 0x800F 就打头归成更新问题。0x800F0906 和 0x800F081F 虽然都是找不到源但一个是网络侧没拿到一个是本地路径不对解法完全不同。2.2 从日志里读出真实原因错误码只是摘要真正的细节在两份日志里C:\Windows\Logs\CBS\CBS.log—— 组件服务的主日志功能的展开、注册、失败都记在这里C:\Windows\Logs\DISM\dism.log—— DISM 这个前台工具的动作日志。我一般的做法是在失败的同一分钟内去对应日志里搜关键字。CBS.log 里搜NetFx3或者error能看到它在哪一步断的。比如出现过Failed to find payload就是源文件路径下没有对应的 CAB出现Could not open key就是权限或注册表被锁。这里有个经验别去翻整个日志太长了。用 PowerShell 过滤几秒钟出结果Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern NetFx3|0x800F | Select-Object -Last 40最后 40 行基本就够看了因为失败通常发生在命令执行的末尾。如果 CBS.log 里只有一句操作完成没有细节那说明问题在前面就断了这时候回看 dism.log 更有效。2.3 一次完整排查链路的还原讲个我上个月遇到的实例把思路走一遍比干讲理论有用。一台新装 Win11 的笔记本同事要跑一个老的报表工具报需要 3.5。第一次尝试直接在控制面板勾选 NetFx3等了两分钟报0x800F0906。这个码指向无法下载源文件那我去看更新通道结果发现这台机器之前为了省流量装了个第三方的更新管理工具把 Windows Update 服务设成了手动而且处于停止状态。恢复服务重试还是 0x800F0906。这时候就要换思路了。既然是下载不到那就别走下载。我直接本地挂了个同版本 Win11 的 ISO把sources\sxs提出来用离线命令启用一次成功。整个链路走下来大概十分钟其中八分钟花在了确认为什么下载失败上。这个时间不是浪费——如果一开始就盲猜着去挂 ISO万一那次失败其实是空间不足0x800F0922挂 ISO 也是白挂你会以为离线法也没用然后开始怀疑人生。3. 在线路径最省事但也最容易踩到策略和网络的坑在线方式理解起来最简单DISM 告诉组件服务我要启用 NetFx3组件服务发现本地存储里没有这个包就转头去配置好的更新源拉取。问题在于配置好的更新源这四个字背后有一串策略在起作用任何一环被改过这条路就断了。3.1 图形界面和命令行到底差在哪很多人只知道控制面板那条路WinR 打开optionalfeatures勾上 .NET Framework 3.5包括 .NET 2.0 和 3.0确定。这条路底层调的其实也是 DISM只是把输出信息藏起来了失败了只给你一句Windows 无法完成请求的更改加一个码。相比之下我强烈建议改用命令行原因是你能看到进度和详细报错# 以管理员身份打开 PowerShell 或 CMD DISM /Online /Enable-Feature /FeatureName:NetFx3 /All参数拆一下/Online指当前正在运行的系统/Enable-Feature是启用功能/FeatureName:NetFx3是那个功能的内部名字注意不是 3.5就叫 NetFx3/All表示把这个功能的所有父级依赖一起启用。这条命令不写/Source就是纯在线模式让它自己去找源。想先看看当前状态可以用DISM /Online /Get-FeatureInfo /FeatureName:NetFx3输出里会显示 State 是 Enabled 还是 Disabled以及状态已启用/已禁用。这个命令还有个隐藏用法——如果它显示的是启用挂起说明之前那次操作没走完需要重启别急着再执行启用命令。3.2 0x800F0954策略把更新通道劫持了这是企业环境里出现频率最高的码。原理很直白组策略把机器的更新源指向了内网的 WSUS 服务器DISM 想装 NetFx3 就去问 WSUS而 WSUS 上没有同步这个按需功能包于是返回 0x800F0954。处理方式有两个方向各有利弊我把判断依据一起给你。方向一临时让机器绕过内网更新源。打开注册表编辑器定位到HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU把UseWUServer的值从 1 改成 0然后重启 Windows Update 服务net stop wuauserv net start wuauserv再执行启用命令。方向二干脆完全不依赖更新源走离线源。加一个/LimitAccess参数告诉系统别联网也别找更新就用我给你的本地路径DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs注意如果这台机器在域里改完UseWUServer记得在装完后改回 1否则这台机器会绕过公司的补丁管理策略可能给自己和别人都带来麻烦。做完就还原是基本的职业习惯。我的实际偏好是方向二。因为方向一要动策略相关的键值在受管的机器上属于越界操作而且改完不还原迟早出事。方向二只读不写干净得多代价只是你得手里有一份对应版本的镜像。3.3 网络环境和新式精简系统的额外问题除了策略还有几种情况会导致在线路径走不通机器用了公司统一的出口网关做流量管控微软的更新域名被拦在外面表现就是一直卡在正在下载然后超时DNS 配错了或者启用了一些第三方 DNS 过滤规则把更新相关的域名解析到黑洞地址系统是第三方精简镜像制作时用工具移除了按需功能相关的组件清单这种情况下 DISM 甚至会告诉你功能名称未知连报错都跟别人不一样。第二种和第三种情况基本没有在线解法直接跳第四章走离线。判断方法很简单执行DISM /Online /Get-Features | findstr NetFx如果列表里根本没有 NetFx3 这一项那就是被精简掉了别再浪费时间。4. 离线路径拿系统镜像自带的源文件硬灌进去离线方式是我最推荐、也最可靠的方案尤其是你要给别人的机器装、或者要在多台机器上重复操作的时候。核心逻辑就一句话NetFx3 的组件包本来就在 Windows 安装镜像里躺着你只需要把它指给系统看。4.1 从 ISO 里把 sxs 目录提出来准备一份和当前系统版本一致的 Windows 安装镜像。注意版本一致这个要求Win11 的机器就用 Win11 的镜像Win10 就用 Win10 的大版本号比如 22H2 对 23H2通常可以混用但为了少出意外能对上就对上。体系结构也要一致x64 系统就用 x64 镜像。把 ISO 挂载起来Mount-DiskImage -ImagePath D:\ISO\Win11_23H2.iso # 挂载后查看盘符 Get-Volume | Where-Object DriveType -eq CD-ROM假设挂到了E:盘源文件就在E:\sources\sxs。这个目录里有几十个 CAB 文件名字形如microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab你不需要挑整个目录一起用就行。更稳妥的做法是把 sxs 拷到本地硬盘再操作避免 ISO 中途掉线robocopy E:\sources\sxs C:\sxs /E拷完可以卸掉镜像Dismount-DiskImage -ImagePath D:\ISO\Win11_23H2.iso。用本地路径做源有个好处命令执行几秒就结束不会因为光驱读取慢而半路卡住。4.2 离线启用命令的参数逐项拆解完整命令长这样DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\sxs每个参数都不是可选的少一个结果可能就不同/Online—— 作用于当前系统而不是某个离线镜像/Enable-Feature /FeatureName:NetFx3—— 指定要启用的功能/All—— 连带启用父功能主要涉及 WCF 相关的那些子组件不加的话可能出现启用了但程序还是要 3.5的怪事/LimitAccess——这是离线模式的关键它明确告诉组件服务不要去碰更新源。不加这个参数DISM 会先尝试联网联网失败后才回落本地白白多等几分钟某些环境里还会直接以 0x800F0906 中断/Source:C:\sxs—— 指向源目录注意是目录不是单个 CAB 文件。也可以用 PowerShell 原生命令效果等价Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source C:\sxs -LimitAccess我个人更常用 DISM因为输出信息更完整进度百分比也更直观。4.3 一次完整的离线启用实操记录把我在一台全新 Win11 机器上的实际过程写下来你可以照着对。第一步确认当前状态DISM /Online /Get-FeatureInfo /FeatureName:NetFx3 | findstr /i State回显State : Disabled说明确实没启用。第二步处理权限。必须以管理员身份运行终端否则第一步就会报需要提升权限。判断方式很简单看窗口标题有没有管理员字样或者直接执行net session能通就是管理员。第三步执行离线启用。命令敲下去大概十几秒部署映像服务和管理工具 版本: 10.0.22621.1 映像版本: 10.0.22621.2506 正在启用一个或多个功能 [100.0%] 操作成功完成。看到操作成功完成就是成了。如果这里出现操作成功完成以外的任何一句话别急着关窗口把完整输出复制下来对照第 2 章的错误码表去定位。第四步立刻验证别等到要用的时候才发现没装好。验证方法放第七章。第五步清理。把C:\sxs删掉释放空间或者保留着——如果这台机器以后可能重装或者给别人做参考留着也就几百兆我个人倾向于保留下载下来放在维护 U 盘里比每次重新挂 ISO 快得多。提示sxs 目录在不同版本的镜像里内容不同。如果手头有多代系统的维护 U 盘建议按版本分开目录存放比如U盘\sources\win10_22h2\sxs、U盘\sources\win11_23h2\sxs用的时候直接指路不用再想我这个是哪个版本的。5. 装到一半失败的残局残留清理与状态复位失败过一两次之后再重试很多人会发现怎么装都装不上了然后开始怀疑系统被自己搞坏了。实际上大部分情况不是坏了而是上一次失败留下了挂起状态系统怕数据不一致拒绝执行新的组件操作。这一章就是处理这种残局的。5.1 挂起标记在哪里怎么判断组件服务在动手改组件存储之前会在C:\Windows\WinSxS\目录下留一个pending.xml里面记录着重启后要继续做的事。只要这个文件存在很多组件操作会被系统拒绝或者被排队到重启后。查看是否存在Test-Path C:\Windows\WinSxS\pending.xml返回 True 就是存在。另外DISM /Online /Get-FeatureInfo /FeatureName:NetFx3里如果出现启用挂起或者State : Enable Pending也说明有未完成的事务。处理顺序是先老老实实重启一次很多挂起事务重启后就自己走完了。重启完再查一次如果pending.xml还在那才需要进一步处理。直接删这个文件是有风险的除非你确定那次操作已经彻底失败且系统能正常启动否则不要动它。5.2 组件存储坏了修复顺序不能乱如果日志里出现的是0x80073712、0x800F0922这类码或者DISM /Online /Cleanup-Image /ScanHealth报出组件存储可修复那说明问题比缺源文件更深一层。修复要按固定顺序来顺序错了效果会打折。第一阶段扫描先搞清楚损坏程度DISM /Online /Cleanup-Image /ScanHealth DISM /Online /Cleanup-Image /CheckHealthScanHealth是完整扫描慢但准CheckHealth只是快速看看有没有被标记为损坏快但可能漏。日常我先跑 CheckHealth有异常再上 ScanHealth。第二阶段修复。标准命令是DISM /Online /Cleanup-Image /RestoreHealth这个命令默认还是从更新源拿修复用的文件。如果你的机器是那种压根连不上的环境要加源DISM /Online /Cleanup-Image /RestoreHealth /Source:C:\sxs或者用挂载的镜像做源DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1 /LimitAccess第三阶段系统文件层面的补刀sfc /scannowsfc和DISM的分工经常被搞混。简单说DISM修的是组件存储这一层的东西sfc修的是系统盘上实际的那些系统文件。正确的顺序是先 DISM 后 sfc因为 sfc 修复时用的源就是组件存储组件存储本身是坏的sfc 就是拿坏料修坏件。这个顺序搞反了你可能会遇到 sfc 报找到损坏文件但无法修复的情况。5.3 反复失败后我用的兜底流程前面几招都试过还是不行我会走这么一套流程成功率非常高记录当前错误码和 CBS.log 最后 50 行别丢万一要走别的路这个信息有用清空临时状态停掉 Windows Update 相关服务清掉C:\Windows\SoftwareDistribution\Download下的内容重启一次让挂起事务有机会走完重启后再次执行离线启用源换成从同版本镜像新拷出来的 sxs避免复用可能被改坏的老副本如果仍然失败做一次 Repair Install就地升级重装把同版本的安装镜像挂载后运行setup.exe选择保留个人文件和应用。这个操作会把系统组件层整个刷新一遍代价是耗时但比彻底重装友好得多。第 5 步听起来重但在精简系统、Ghost 系统上其实是最省心的选择。我遇到过一次一台同事自己装的精简版 Win10NetFx3 相关功能项压根不在功能列表里前面所有招式全部无效。最后就是找了原版镜像做就地升级四十分钟搞定比继续在那里折腾组件存储快得多。这种时候要果断认输别钻牛角尖。6. 批量场景和特殊系统域控、无人值守、精简镜像单机装一次的东西用上面的方法就够了。但如果你面对的是几十台机器或者要做一个装好就能用的模板那就得换思路——手动敲命令的方式没法批量化还会因为手抖写错路径产生一堆莫名其妙的问题。6.1 域环境和脚本批量下发在受管环境里最干净的做法是通过域策略或者管理平台下发一条 PowerShell 脚本。脚本本身很短重点在于源路径最好是网络共享而且所有目标机器都能访问到param( [string]$SourcePath \\fileserver\share\sources\sxs ) $feature Get-WindowsOptionalFeature -Online -FeatureName NetFx3 if ($feature.State -eq Enabled) { Write-Output NetFx3 已启用跳过 exit 0 } try { Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source $SourcePath -LimitAccess -ErrorAction Stop Write-Output 启用成功 exit 0 } catch { Write-Output (启用失败 $_.Exception.Message) exit 1 }两个设计考量值得说明。第一脚本先查状态再动手避免对已经装好的机器重复操作——重复执行同一功能启用命令会浪费好几分钟机器多了这个时间很可观。第二用try/catch把错误信息打出来方便你在管理平台上一次性看到哪些机器失败、失败原因是什么而不是靠一台台去翻日志。如果走的是域控策略注意前面提到过的UseWUServer问题——策略本身可能正是导致失败的原因。这种情况下脚本里不能去改这个键值会被策略刷回来只能坚持走/LimitAccess的离线路线。6.2 自制镜像和无人值守里的处理如果你要做一个标准化的装机镜像最省事的办法是在镜像制作阶段就把 NetFx3 启用好装完系统直接可用终端用户永远碰不到这个问题。做法是在离线挂载的镜像上执行注入dism /Mount-Image /ImageFile:D:\images\install.wim /Index:1 /MountDir:C:\mount dism /Image:C:\mount /Enable-Feature /FeatureName:NetFx3 /All /Source:C:\sxs /LimitAccess dism /Unmount-Image /MountDir:C:\mount /Commit顺序不能颠倒/Unmount-Image不加/Commit的话改动全部丢弃。这一步做完用这个 WIM 装出来的系统天生就带 3.5。另一条路是在无人值守应答文件里预置。unattend.xml中可以声明需要安装的功能组件系统在首次启动的 specialize 阶段会自动处理。不过我不太推荐新手走这条路应答文件的语法容易写错而且一旦写错装出来的系统可能卡在 OOBE 阶段排查起来比装个 3.5 麻烦多了。镜像注入的方式更直观出错也能立刻发现。6.3 虚拟化和云端机器的差异虚拟机上装 NetFx3 有个坑值得单独提如果你用的是模板克隆出来的虚拟机那台模板机可能已经成功装过 3.5但你克隆的时候是在启用中的状态下克隆的克隆出来的机器组件状态就可能是半吊子。这种情况下的表现是功能列表里显示已启用但程序跑起来还是报错。解决办法是先在模板机上确认状态是干净的 Enabled再去做克隆。另外某些公有云上的 Windows 实例是没有本地安装镜像的你拿不到 sxs 源文件。这种机器要装 3.5得先自行上传一份对应版本的镜像到云盘再按离线流程操作。注意云实例的系统盘空间可能比较紧挂载 ISO 加解压 sxs 需要预留两个 G 左右别做到一半空间不足报 0x800F0922。7. 装完之后怎么确认真装好了以及后续的验证思路我见过好几次以为装好了结果客户现场一开机又报错的窘境。启用成功和程序能跑之间还有一段需要确认的路。收尾这部分看着不起眼但能避免很多返工。7.1 三种验证手段从快到细第一种查功能状态。最快一条命令DISM /Online /Get-FeatureInfo /FeatureName:NetFx3关注两点State是不是Enabled以及输出里有没有挂起字样。必须是干净的 Enabled 才算数。第二种查注册表里的运行时安装信息。.NET Framework 2.0/3.0/3.5 会在注册表里留记录位置是HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5看Install这个 DWORD 值是不是 1Version是不是 3.5.xxxxx。这个检查的好处是它反映的是运行时层面的注册情况比功能状态更贴近程序能不能用。第三种也是最靠谱的用目标程序实测一遍。把那个报错的软件装上去跑起来看它还报不报框架缺失。这一步没法省略——前两项都过了但程序还是不行的情况我在实际中遇到过两次原因都是程序自身的配置文件写死了特定版本跟 3.5 装没装没关系。7.2 装好了程序还报错往哪儿查如果三项验证前两项都过了程序还是不认问题通常出在这几个地方程序是 32 位的但拿到的判断依据有误。x64 系统上 NetFx3 启用后同时包含 32 位和 64 位组件一般不会出这个问题除非镜像源用的是错的架构比如在 x64 系统上灌了只含 arm64 组件的源。这种情况 DISM 会报失败不会给你成功的假象。程序自身带的配置文件指向了不存在的版本。打开程序目录下的程序名.exe.config看supportedRuntime那一行的版本号。如果写的是v3.0而不是v2.0.50727那它找的是 3.0 的运行时行为可能不一样。环境变量里的加载路径被改过。极少数情况下机器上装过一些旧的开发工具改过运行时的解析顺序这种情况要到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework下面去看有没有异常的键值。程序还有别的依赖没满足比如某个 VC 运行库或者特定版本的 MDAC。这时候报错信息里虽然提到框架但根因在别处。判断方法是换一台确定正常的机器跑同一个程序对比差异。7.3 把这次的参数存进你的维护手册最后分享一个我坚持了很多年的习惯每成功处理一次环境相关的问题就在自己的笔记里记一行——系统版本、错误码、最终的解决命令、耗时。看着麻烦但等你处理第十台同类机器的时候直接翻笔记复制粘贴五分钟就完事。我自己的笔记里关于 NetFx3 的条目大概是这个结构[环境] Win11 23H2 x64 / 域内受管机 / WSUS 内网 [现象] 控制面板勾选失败0x800F0954 [方案] 挂 23H2 ISO → robocopy sxs 到 C:\sxs → DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\sxs [耗时] 约 6 分钟含拷文件 [备注] 无需改注册表别动 UseWUServer这种记录积累到几十条之后你会发现大部分疑难杂症其实都是见过的模式真正新的问题很少。技术活干久了值钱的不是知道多少命令而是知道在什么现象下该用哪条命令以及哪些看着诱人的操作是绝对不能碰的。另外提一句用离线源这条路走得通前提是你的机器组件存储本身是健康的。如果先在别的机器上反复折腾坏了组件存储再拿离线源来救很可能还是失败——这就是为什么我在第五章强调修复顺序。装上 3.5 这件事本身不难难的是先排除掉那些看起来无关、实际上会挡路的干扰项。