企业官网建设流程全解析

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.exe（SP1 完整包，约 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 version="v2.0.50727"/>，系统一看，要 CLR 2.0，就会去找 2.0 那一套；找不到，就弹那个经典的提示框，让你去装 .NET Framework 3.5。所以哪怕你 4.8.1 装得再全，一个 2010 年写的上位机软件照样会拦住你。

我在工厂现场碰到过一模一样的事：一台新配的工控机，4.8 装齐了，客户拿来的设备调试软件死活起不来，报错信息里明明白白写着 v2.0.50727。折腾了一下午，最后就是启用 NetFx3 解决的。所以第一件事，先确认你到底需不需要它——看你那个报错程序提示的框架版本号，别听网上说"3.5 老掉牙了不用装"。

1.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% 以上的现场情况。看到码，先在这张表里定位，再去对应的章节找解法。

看表的顺序一定是从上往下对，别看到 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 图形界面和命令行到底差在哪

很多人只知道控制面板那条路：Win+R 打开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 /CheckHealth

ScanHealth是完整扫描，慢，但准；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 /scannow

sfc和DISM的分工经常被搞混。简单说，DISM修的是"组件存储"这一层的东西，sfc修的是系统盘上实际的那些系统文件。正确的顺序是先 DISM 后 sfc，因为 sfc 修复时用的源就是组件存储，组件存储本身是坏的，sfc 就是拿坏料修坏件。这个顺序搞反了，你可能会遇到 sfc 报"找到损坏文件但无法修复"的情况。

5.3 反复失败后我用的兜底流程

前面几招都试过还是不行，我会走这么一套流程，成功率非常高：

1. 记录当前错误码和 CBS.log 最后 50 行，别丢，万一要走别的路这个信息有用；
2. 清空临时状态：停掉 Windows Update 相关服务，清掉C:\Windows\SoftwareDistribution\Download下的内容；
3. 重启一次，让挂起事务有机会走完；
4. 重启后再次执行离线启用，源换成从同版本镜像新拷出来的 sxs，避免复用可能被改坏的老副本；
5. 如果仍然失败，做一次 Repair Install（就地升级重装），把同版本的安装镜像挂载后运行setup.exe，选择"保留个人文件和应用"。这个操作会把系统组件层整个刷新一遍，代价是耗时，但比彻底重装友好得多。

第 5 步听起来重，但在精简系统、Ghost 系统上其实是最省心的选择。我遇到过一次，一台同事自己装的精简版 Win10，NetFx3 相关功能项压根不在功能列表里，前面所有招式全部无效。最后就是找了原版镜像做就地升级，四十分钟搞定，比继续在那里折腾组件存储快得多。这种时候要果断认输，别钻牛角尖。

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 值是不是 1，Version是不是 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 这件事本身不难，难的是先排除掉那些看起来无关、实际上会挡路的干扰项。