上周给一台刚重置完的 Windows 11 工作站部署一套老款设备管理软件安装程序弹出的第一句话就是需要 .NET Framework 3.5包括 .NET 2.0 和 3.0。点了下载并安装此功能进度条爬到 30% 左右停住几分钟后甩出一个 0x800F0906——这台机器在内网里根本没有走 Windows 更新的出口。这就是 Windows 10/11 离线安装 .NET Framework 3.5 的典型现场功能本身不大难点全在源和策略上。这篇内容就是把这个过程完整拆开讲。我会说明 .NET 3.5 在 Windows 10/11 里为什么变成了一个需要单独喂源的按需功能、安装介质里的sources\sxs目录该怎么用、版本和架构怎么对齐、DISM 和 PowerShell 两条命令路线各自的参数含义、常见报错码对应的排查方向以及给离线 WIM 批量注入 NetFx3 的做法。适合三类人看企业里做终端运维的、经常给工控机或内网机器装老软件的、以及自己装机时被这个弹窗卡住的普通用户。基础命令我会逐个参数解释命令行不太熟的朋友照着抄也能跑通。1. 为什么在 Windows 10/11 上离线装 .NET 3.5 变成了技术活1.1 还在依赖 .NET Framework 3.5 的三类软件先讲清楚为什么非装不可。.NET Framework 4.x 虽然向下兼容源码级别的 API但不兼容二进制一个针对 2.0/3.5 编译出来的 exe运行时绑定的是 2.0 版的 CLR如果你机器上只有 4.8它照样起不来除非厂商重新编译发布新版本。我实际遇到最多的三类行业软件的配套工具。老版 PLC 编程软件、老款示波器/频谱仪的上位机、几年前停更的数控系统通讯程序这类软件厂商早就不维护了安装包里硬编码依赖 3.5。企业内部的遗留系统。用 VB.NET 2008 或者 C# 2.0 时代写的小工具、报表程序、财务接口跑在一台台机器上十几年没人动过。安装程序本身。有些用 InstallShield 老版本打包的产品连安装引导界面都是 .NET 2.0 写的3.5 不装连下一步都点不到。判断方法很简单程序报错时提示需要 .NET Framework 3.5、或者直接抛System.IO.FileNotFoundException且缺的是 mscorlib 2.0.0.0 相关程序集基本就是这个原因。1.2 按需功能这个设计带来的连锁反应Windows 8 之后.NET 3.5 从默认安装改成了按需功能Feature on Demand。含义是系统里保留了这项功能的清单和注册信息但负载文件payload没有随系统落盘需要的时候再取。这个设计在联网环境下很省事——Windows 更新里挂着一个专门用来安装 NetFx3 的包点一下就好。但它带来三个副作用全都在离线环境里爆发第一负载从哪来是源的问题不是功能的问题。系统只认两个来源Windows 更新或者你用/Source指定的本地目录。没有源功能列表里勾了也没用。第二源必须和当前系统的版本、架构、语言对齐。这不是随便找个 NetFx3 的 cab 丢进去就能过DISM 会做版本比对。跨大版本混用必挂。第三企业环境的更新策略会直接掐死兜底路径。很多内网机器的更新源指向内部服务器NetFx3 的负载根本不在那台服务器上于是 DISM 在下载这一步超时失败报出来的错和源找不到长得很像容易误判。1.3 四种典型的离线现场把场景分清楚后面选方案会快很多现场类型特征推荐路径完全隔离的内网机无外网装了内部更新服务器安装介质提sources\sxs/LimitAccess单机新装系统有网但懒得等或更新被工具优化过挂载同版本 ISO直接指 sxs批量装机/自定义镜像要一次做完装完就出货给 offline WIM 注入 NetFx3测试通道的预览版本系统 build 比较新介质不好找优先修好在线路径其次找同 build 介质第四种情况我要单独说一句预览版本的系统Windows 更新上的按需包有时候确实取不到或者内部更新服务器上没有对应通道的内容。这种情况下如果机器本身能连外网把在线路径修通比折腾离线源省事得多因为在线路径会自己挑正确版本的包。2. 找准安装源sources\sxs 的来路、版本与架构对齐2.1 安装介质里的 sources\sxs 才是正牌货源正牌源是 Windows 安装介质ISO 或 U 盘根目录下sources\sxs这个文件夹。Windows 10/11 的介质里它是存在的体积我这边实测大多在300 MB 到 450 MB之间里面是一堆 cab 文件其中和 .NET 3.5 相关的那一个文件名长这样microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab中间那串31bf3856ad364e35是微软的公钥标记后面的amd64是架构标识。你只需要这一个目录不需要整个 ISO更不需要处理 install.wim 超过 4GB 怎么拷进 FAT32 U 盘的问题——这一点很多人绕远了。挂载 ISO 之后把sources\sxs整个复制到本地磁盘就行。除了安装介质还有两个合法来源可以拿到同样的负载Windows 功能按需Features on DemandISO。这个是独立提供的介质里面按语言和架构分了目录NetFx3 的负载在里面能找到适合手里只有某一版系统镜像、但又需要跨版本补包的场景。同版本同架构的另一台机器。在已经成功启用过 NetFx3 的机器上负载会落到C:\Windows\WinSxS里理论上可以拿来做源。但我实测这条路成功率不稳定组件存储里的命名和版本状态会被更新影响只在实在没有介质时才考虑。需要注意的是/Source指向的目录不必非要叫 sxs。你把内容拷到D:\netfx3src然后/source:D:\netfx3src一样能过。我习惯保留sxs这个目录名纯粹是为了半年后自己还能想起来这是什么。2.2 版本对齐winver 和 CurrentBuildNumber 要先看这是整个流程里最容易被忽略、也最容易导致失败的一步。先确认当前系统的准确版本再决定用哪份介质。打开 CMD 或者 PowerShell两条命令winver reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v CurrentBuild reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v UBRwinver图形窗口会告诉你版本和内部版本号比如 22H2、22621。CurrentBuild是主 buildUBR是累积更新的修订号。对齐原则按我的实测经验同 build 同架构基本一次过这是唯一能保证的路径。同一年份体系内的小版本差异比如 19044 的介质给 19045 用有时候能过取决于两次更新有没有动到 NetFx3 的负载版本。跨大版本比如拿 19045 的介质给 22631 用或者拿 Win10 的介质给 Win11 用不要浪费时间去试几乎必然报 0x800F081F。顺便说个反向验证的窍门如果/Source指定的目录里连对应架构的 netfx3 cab 都找不到DISM 不会去联网兜底加了/LimitAccess的情况下会很快就失败。所以报错来得特别快十几秒内大概率是路径或文件名的问题如果卡了几分钟才报错更像是它去尝试联网超时了。2.3 架构对齐amd64、x86、arm64 不能混用架构这条线也很硬操作系统是什么架构就必须喂什么架构的包。操作系统架构sxs 里的目标包标识常见来源64 位 x64~amd64~~绝大多数 x64 ISO32 位 x86~x86~~32 位 ISO如 1909 x86 版本ARM64~arm64~~ARM 版设备对应介质我在 32 位老机器上踩过一次手边只有 x64 的 ISO想着3.5 的包应该一样吧结果在sources\sxs里翻半天只看到 amd64 的 cab。32 位系统的介质里只带 x86 的负载反之亦然这是介质裁剪时按架构打的。另外提醒一句在 64 位系统上把整个sxs目录给它就行不要自作聪明只挑一个 cab 出来。目录里同时存在多个版本的同类 cab 是正常现象DISM 自己会挑合适的那个。2.4 手里没有对应介质时的三条路现实里最尴尬的情况就是系统是别人装的ISO 没有内部又没有文件服务器。这时候我有三条按优先级排的路线第一条用官方渠道重新下对应版本的 ISO。这是最干净的做法下完之后只取sources\sxs那一块几十上百 MB 的复制量几秒钟的事。企业里最好把每个在用的 Windows 版本的sxs存一份到文件服务器上一次投入长期受益。第二条把系统就地升级一遍。如果组件存储被清理过后面第 7 节会讲或者怎么都找不到介质可以用同版本 ISO 挂载后运行setup.exe选择保留个人文件和应用的升级方式。这个过程会把组件存储补齐升完之后 NetFx3 通常能装上。代价是时间长半小时到一小时而且必须提醒用户备份。第三条让机器的更新路径恢复可用。如果这台机器其实能出网只是更新策略把它拦住了那么修正策略比找介质快得多。判断方法就是看%windir%\Logs\CBS\CBS.log里报的是下载失败还是源文件缺失——这两个词的差别决定了你该往哪个方向使劲。3. 源放哪儿目录规划比命令更影响成功率3.1 本地磁盘优先副本命名带上版本号我的习惯是把 sxs 副本放在系统盘之外的本地磁盘路径尽量短命名带上版本信息例如D:\FOD\sxs_22621_amd64\ D:\FOD\sxs_19045_amd64\三个理由。第一路径短可以规避一些路径长度相关的边界问题DISM 处理长路径时的行为不太一致短路径最省心。第二多版本并存半年后系统升级了你一眼就知道该用哪份不用再翻 ISO。第三放系统盘之外重装系统时源还在。需要多少空间整个sxs目录就是 300 MB 到 450 MB另外 DISM 安装过程中会占用一部分临时空间用于展开和事务处理。我的经验是系统盘至少留 2 GB 空闲太紧的时候遇到过安装到一半失败的情况。安装完成后临时文件会自动清理实际占用的长期空间很小——只有 NetFx3 自身那部分负载会进WinSxS。另外如果你的介质只挂载不复制也可以直接从盘符引用/source:E:\sources\sxs。短时间装一台机器完全够用但缺点是一旦 ISO 被卸载、或者下次机器重启后盘符变了之前配的策略就指空了。所以我倾向于复制一份到本地。3.2 UNC 共享做备用源的讲究企业环境里更常见的是把 sxs 放在文件服务器上用 UNC 路径做源\\fileserver\software\FOD\sxs\22621\amd64这条路能用但有几个细节必须处理否则会出各种路径存在却读不到的怪问题权限要给到机器账户或全体用户可读。DISM 在启用功能时以 SYSTEM 身份执行一部分操作如果共享只给了某个用户组读权限机器账户访问不到就会失败。生产环境我一般给所有人读权限或者给域计算机组读权限。共享路径不要用映射盘符。映射盘符是登录会话级别的SYSTEM 身份访问不到。用\\server\share\...这种完整 UNC 格式。路径里别带中文和空格虽然多数情况能处理但徒增变量。共享的读取性能要考虑。从千兆网络读四五百 MB 再展开装一次两三分钟很正常如果网络慢或者共享存储本身繁忙DISM 的进度条长时间不动别急着判定失败先看磁盘队列。我自己在几百台机器的批量部署里最终选的是文件服务器放母本 部署脚本先复制到本地临时目录再安装。多花十几秒复制换来确定性值。3.3 一个校验小动作确认 sxs 没被截断复制大目录最怕中途断线。装之前花十秒钟确认一下目标目录里确实有 netfx3 的 cabGet-ChildItem -Path D:\FOD\sxs_22621_amd64 -Filter *netfx3* | Select-Object Name, {nSizeMB;e{[math]::Round($_.Length/1MB,1)}}正常应该能看到至少一个以microsoft-windows-netfx3-ondemand-package开头的 cab。如果这个命令什么都没返回要么目录拷错了层比如拷成了sources而里面没有sxs要么复制中断了。这一步能省掉后面一大堆猜测。4. DISM 与 PowerShell 两条实操路线4.1 DISM 命令的每个参数在干什么核心命令就一行这是我在所有 Windows 10/11 机器上用的版本dism /online /enable-feature /featurename:NetFx3 /all /limitaccess /source:D:\FOD\sxs_22621_amd64从左到右逐个说/online目标是在正在运行的系统上操作而不是离线镜像。用错了会报找不到指定的路径。/enable-feature启用功能对应/disable-feature是卸载。/featurename:NetFx3功能名必须精确写NetFx3大小写不敏感但不要写成.NET Framework 3.5。/all同时启用所有父功能和依赖项。NetFx3 在功能树里有父节点不加这个参数有可能出现启用了但状态不对的情况我建议一律加上。/limitaccess明确告诉 DISM 不要去向 Windows 更新索取负载。这是内网和隔离环境里最关键的一个参数不加它DISM 在本地源找不到的时候会去联网兜底白白多等好几分钟然后报 0x800F0906掩盖真正的问题。/source:负载所在的展开目录。几个我踩过的用法坑不要把它指到 install.wim 或者 ISO 根目录。/source:E:\sources\install.wim这种写法不成立源必须是展开的目录结构。指到E:\我也只在某些情况下见过成功不稳定老老实实指到 sxs 目录。执行前确认是管理员权限的命令行。普通权限运行会直接被拒报错信息很直白不会让你多猜。耐心看进度。DISM 的输出在 20% 到 40% 之间会停一会儿这是在做组件清单比对和事务准备。本地磁盘源一般一分钟内出结果网络源两三分钟也正常。想先看当前状态用这条dism /online /get-featureinfo /featurename:NetFx3输出里State : Enabled就是已经装好了State : Disabled才是需要装的。如果是Disabled with Payload Removed之类的措辞说明负载确实不在本地——这正是需要你喂源的原因。4.2 PowerShell 的等价写法不喜欢 DISM 命令行的PowerShell 有对应封装Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source D:\FOD\sxs_22621_amd64 -LimitAccess -NoRestart参数和 DISM 是一一对应的-All对应/all-Source对应/source-LimitAccess对应/limitaccess-NoRestart对应/norestart。用 PowerShell 有两个实际好处。第一个是容易做判断和批处理比如先探测介质盘符再决定要不要装$feat Get-WindowsOptionalFeature -Online -FeatureName NetFx3 if ($feat.State -ne Enabled) { $src D:\FOD\sxs_22621_amd64 if (Test-Path (Join-Path $src microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab)) { Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source $src -LimitAccess -NoRestart } else { Write-Warning 源不完整先检查 sxs 目录$src } }第二个好处是错误信息比 DISM 更容易被脚本捕获。try/catch能拿到异常对象里面带着错误码适合放进自动化部署流程里做分支处理。有一点要提醒PowerShell 的Enable-WindowsOptionalFeature在部分较老的 build 上对-LimitAccess的支持不太一致如果发现参数无效直接退回去用dism.exe调外部命令反而更可靠。4.3 图形界面里点启用为什么也失败控制面板 → 程序和功能 → 启用或关闭 Windows 功能 → 勾选 .NET Framework 3.5这条路径在离线环境里基本是必挂的。原因是它默认先走 Windows 更新本地没有负载也没有配置备用源时它只能下载下载不通就报错而且报的错信息量比 DISM 小得多。但它不是没用。只要你在系统里配置了备用源文件路径策略下一节讲图形界面会直接去找本地源不再弹需要从 Windows 更新下载文件的框。对不太熟悉命令行的同事来说把策略配好之后让他们自己点勾选是最省事的落地方式。4.4 给离线 WIM 注入 NetFx3批量装机的正确姿势如果你在做自定义镜像或者批量装机比装完系统再装 3.5更高效的做法是直接把 NetFx3 注入到 install.wim 里装机时开箱即用。流程是挂载、注入、提交三步dism /get-wiminfo /wimfile:D:\ISO\sources\install.wim mkdir C:\mount dism /mount-image /imagefile:D:\ISO\sources\install.wim /index:1 /mountdir:C:\mount dism /image:C:\mount /enable-feature /featurename:NetFx3 /all /limitaccess /source:E:\sources\sxs dism /image:C:\mount /get-featureinfo /featurename:NetFx3 dism /unmount-image /mountdir:C:\mount /commit几个必须注意的点/index要选对。一个 install.wim 里通常有家庭版、专业版、企业版多个索引用/get-wiminfo看清楚哪个是你实际要部署的版本。选错了等于白干。挂载需要相当的空间。WIM 展开后是十几个 GB 的规模挂载点所在分区要留足我一般直接给 30 GB 以上。/image:而不是/online:。挂载状态下用/online会去动你正在运行的系统那就出大事了。注入前先用/get-featureinfo /image:C:\mount确认当前状态注入后再查一次看到Enabled再提交。提交时用/commit不加就是丢弃改动。不要在挂载状态下直接改目录文件改动要通过 DISM 操作手动动文件会破坏组件存储的一致性。镜像改好之后后续所有从这份镜像装出来的机器NetFx3 都是已启用状态装机流程里就再也不用管这件事了。这是我在需要部署几十台以上同型号机器的场景里最推荐的方案。4.5 用策略把源钉住让图形界面和后续修复都能自动找到包前面说的都是我手动指定源。更省心的做法是在系统里配置一个长期有效的备用源路径这样任何按需功能的安装和组件修复都会自动去那里找负载。图形路径在计算机配置 → 管理模板 → 系统 → 指定可选组件安装和组件修复的设置。三个要点启用策略。把备用源文件路径填成你的 sxs 目录比如D:\FOD\sxs_22621_amd64或者 UNC 共享路径。把从不尝试从 Windows 更新下载负载设上避免它在本地源找不到时偷偷去联网等超时。对应的注册表位置在HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing LocalSourcePath (REG_EXPAND_SZ) D:\FOD\sxs_22621_amd64 RepairContentServerSource (DWORD, 2) 直接从 Windows 更新取修复内容如果你的环境里有内部更新服务器还要额外把直接从 Windows 更新下载修复内容而不是从内部更新服务器这一项设上否则某些修复请求会被路由到内部服务器而那里没有 NetFx3 的负载结果就是继续报 0x800F0950。手工改注册表的话注意LocalSourcePath的类型要选可扩充字符串值REG_EXPAND_SZ选成普通字符串在某些路径含变量的情况下会失效。策略配好之后最大的收益不是这一次装上了而是以后每次系统更新需要重新对齐组件、或者某个功能损坏需要修复时系统都能自己找到源。这在没有外网的环境里能省掉大量重复劳动。5. 报错对照与排查链路从日志顺藤摸瓜5.1 常见报错码的含义和触发条件报错码提示大意我这边最常见的触发条件先做什么0x800F081F找不到源文件路径写错、sxs 里没有对应架构的 cab、介质与系统 build 差太远核对路径和 cab 文件名换同版本介质0x800F0906无法下载所需文件没加/LimitAccessDISM 想联网兜底但出不去补上参数再确认更新源策略0x800F0950无法完成请求的更改和上面同源Windows 11 上措辞不同常伴更新策略拦截看 CBS 日志判断是下载还是源问题0x800F0907操作未完成源目录里有 cab但架构或语言不匹配或者文件本身损坏换介质重新复制源目录0x800F0922系统分区空间不足类提示少见于此功能主要出现在累积更新上检查系统保留分区和系统盘空间我反复强调的是这批错误码本身的信息量很有限真正有价值的判断都在日志里。同一个 0x800F081F可能是路径问题也可能是组件存储被精简过处置方式完全不同。5.2 第一步永远是看日志而不是反复重试两个日志文件位置固定%windir%\Logs\DISM\dism.log %windir%\Logs\CBS\CBS.logCBS.log 被系统占用直接搜有时候会失败我的做法是先复制一份出来再搜copy %windir%\Logs\CBS\CBS.log %temp%\cbs_copy.log findstr /i netfx3 %temp%\cbs_copy.log findstr /i 0x800f %temp%\cbs_copy.logdism.log 可以直接搜findstr /i netfx3 %windir%\Logs\DISM\dism.log判断方法简单粗暴但有效搜到的行里出现 download、WU、Windows Update 之类的字眼说明它走的是联网路径问题在策略和出口出现 source、payload、not found、SXS 之类的字眼说明问题在本地源去核对路径、版本、架构。这两个方向的处理方式完全不同先分清能省掉一半时间。还有一个很多人不知道的日志%windir%\Logs\CBS\Poqexec.log。它记录的是组件安装的事务处理过程当安装卡在某些奇怪的状态、或者提示需要重启但重启后依然没装上时这个日志里能找到线索。5.3 0x800F081F 的两条分支这个错最常见我把它拆成两种典型情形。情形一源本身不对。表现是报错来得很快十几秒内就有结果。原因是/source路径打错、目录层级多了一层或者少了一层、介质版本差太远。快速验证方法Test-Path D:\FOD\sxs_22621_amd64 Get-ChildItem D:\FOD\sxs_22621_amd64 | Measure-Object -Property Length -Sum | ForEach-Object { [math]::Round($_.Sum/1MB,1) }目录不存在就是路径问题存在但总大小只有几十 MB说明复制不完整总大小正常但里面没有 netfx3 的 cab说明这份介质里这个功能的负载被裁掉了。情形二组件存储被清理或损坏。表现是路径、版本、架构全部核对无误换了多份介质依然报同样的错。这时候通常是系统被人优化过——用了第三方精简工具或者执行过组件存储清理把版本状态搞乱了。判断方法是在C:\Windows\servicing\Packages里找 netfx3 相关的 muma 清单文件如果没有说明系统层面已经不认这个功能了。情形二的处置只有一条路用同版本 ISO 做就地升级修复把组件存储补齐然后再装 NetFx3。别指望换个源就能解决。5.4 0x800F0906 和 0x800F0950被策略和网络掐断这两个错误和 081F 的区别在于——本地源其实没问题是兜底路径走不通。典型表现是命令执行后卡着不动好几分钟然后才报错。三步处置第一加/LimitAccess。这是最重要的一步它让 DISM 放弃联网直接用本地源报错会立刻变得有意义。第二检查更新策略。内网环境里常见的是更新源被指向内部服务器而那台服务器上没有 NetFx3 的负载。这时候要么用策略把修复内容的来源改回 Windows 更新如果机器能出网要么按照 4.5 节把本地源路径配好让系统从本地取。第三检查系统盘空间。系统盘快满的时候DISM 也可能在事务阶段失败报出来的错和上面的很像。我遇到过系统盘只剩几百 MB 的机器清出空间后一次就过。5.5 预览版本 build 上的特殊情形测试通道的 build比如各种四位数五位数的内部版本号是最麻烦的。这类系统上在线路径上对应的按需包不一定及时存在而离线介质更是几乎拿不到。我的处置顺序是先修在线路径。检查系统能不能访问更新服务、内部服务器上有没有对应通道的内容、有没有被更新策略拦住。如果这台机器本来就该出网修通在线路径比去找一份不一定存在的介质现实得多。如果确实是完全隔离环境那就只能从能联网的同 build 机器上想办法或者评估是不是可以换个更常规的系统版本——为了跑一个老软件把整台机器的版本搞成必须同步维护的状态长期来看是负担。6. 装完怎么确认真的生效四层验证6.1 第一层DISM 状态和注册表dism /online /get-featureinfo /featurename:NetFx3看到State : Enabled是第一层通过。第二层看注册表reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5 /v Install reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 /v InstallInstall值为0x1表示已安装。注意 3.5 是包含 2.0 和 3.0 的累积版本所以正常情况下 v2.0.50727、v3.0、v3.5 三个键都会出现。如果只有 v3.5 而没有 v2.0.50727那说明装得不完整老程序照样跑不起来。6.2 第二层目录和 csc.exe 编译自测看目录dir %windir%\Microsoft.NET\Framework\v3.5 dir %windir%\Microsoft.NET\Framework64\v3.564 位系统上两个目录都应该有内容。Framework64下面空着或者不存在说明 64 位侧的组件没装上。最后一层是我最信得过的——直接编译一个最小程序跑一下class T { static void Main() { System.Console.WriteLine(netfx35 ready); } }保存成t.cs然后C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe /nologo t.cs t.exe能看到输出就说明运行时和编译器都在位。这个方法比看任何状态都实在因为它验证的是程序真能跑而不是系统说它能跑。测试完记得把生成的 exe 删掉别留在生产目录里。6.3 第三层应用侧的最终验证最后一定要拿真正要用的那个老程序跑一遍。我踩过的情况是NetFx3 装好了、编译测试也过了但目标程序是个 .NET 2.0 时期的 WinForms 程序还得依赖某些已经被后来的更新移除掉的兼容性设置或者需要额外的运行库配置。常见的一类问题是程序的配置文件里没有明确supportedRuntime在新的 CLR 加载策略下行为异常。解决办法是在应用程序目录下加一个同名.exe.config明确指定configuration startup supportedRuntime versionv2.0.50727/ /startup /configuration这类调整要看具体程序但思路是统一的NetFx3 是运行环境程序能不能跑还取决于它自己的配置别把应用层的问题误判成系统层的问题。7. 几个我踩过的坑和后续维护习惯7.1 精简镜像和组件存储清理的后果这是所有坑里最难处理的。第三方精简的 Windows 镜像或者生产环境里有人执行过组件存储清理操作会把这些按需功能的负载和版本状态破坏掉。表现就是你手里有完全正确的源路径、版本、架构无一错漏它照样报 0x800F081F。判断这类机器的特征C:\Windows\servicing\Packages目录里清理得异常干净、dism /online /get-features输出的功能列表比正常机器少一截、或者系统体积明显偏小。遇到这种机器我的建议是不要在这上面耗时间。要么用同版本 ISO 就地修复升级要么直接重装。我曾经在一台被精简过的机器上折腾了两个多小时换过四份介质最后用就地升级十五分钟解决——早该这么干。另一条相关经验不要在需要 NetFx3 的机器上随意跑第三方清理工具。有些清理工具会删掉WinSxS里的冗余备份装的时候不觉得有问题等到某个功能需要修复时才会发现组件存储已经没法用了。7.2 盘符、路径长度和权限这些琐碎但要命的事几个具体细节都是吃过亏的挂载 ISO 得到的盘符不固定。在有多块磁盘、多个分区的机器上ISO 可能是 E 也可能是 F。写脚本时不要硬编码盘符用卷标或者探测sources\sxs是否存在来判断$cands (Get-Volume | Where-Object { $_.DriveLetter }).DriveLetter | ForEach-Object { $($_):\sources\sxs } $src $cands | Where-Object { Test-Path $_ } | Select-Object -First 1路径长度。把 sxs 放在层级很深的目录里加上系统本身的长路径偶尔会出问题。我固定在D:\FOD\下放就是为了让路径尽量短。权限。用 UNC 共享时务必确认机器账户能读到。测试方法是以 SYSTEM 身份去访问——psexec -s cmd之后再dir \\fileserver\share能列出来才算真的通。这一步不做后面报错会绕很久。盘符在重装后变化。如果你把源路径写进了注册表策略而路径所在的分区盘符在维护后变了策略就指空了。所以我更倾向用 UNC 或者固定的挂载点。7.3 每月更新之后这份 sxs 还留不留答案是留而且按版本分目录留。原因是每次累积更新之后系统的组件版本会往前走某些老的源可能就不匹配了。但历史上成功的源在相当长时间内仍然可用尤其是同一大版本体系内的。我的做法是文件服务器上建一个FOD目录按版本号架构分子目录。每次下载新的系统 ISO 时顺手把sources\sxs复制进去几百 MB 的事。定期清理两代以前、已经不再维护的系统版本对应目录但保留至少一份。这个过程的价值在半年后集中爆发某台机器突然需要装 .NET 3.5你不用去翻当时的安装 U 盘直接从服务器上取五分钟解决。我自从建立这个习惯之后这类临时需求基本没再占用过超过十分钟的时间。最后一个个人习惯每台装过 NetFx3 的机器我都会顺手把那条生效的 DISM 命令和源路径记在运维记录里。不要小看这一步一年后你需要在一台备份恢复出来的机器上重做一遍时有这条记录和没这条记录差别可能是半小时和三分钟。
Windows 10/11离线安装.NET 3.5：DISM与sxs源实战
上周给一台刚重置完的 Windows 11 工作站部署一套老款设备管理软件安装程序弹出的第一句话就是需要 .NET Framework 3.5包括 .NET 2.0 和 3.0。点了下载并安装此功能进度条爬到 30% 左右停住几分钟后甩出一个 0x800F0906——这台机器在内网里根本没有走 Windows 更新的出口。这就是 Windows 10/11 离线安装 .NET Framework 3.5 的典型现场功能本身不大难点全在源和策略上。这篇内容就是把这个过程完整拆开讲。我会说明 .NET 3.5 在 Windows 10/11 里为什么变成了一个需要单独喂源的按需功能、安装介质里的sources\sxs目录该怎么用、版本和架构怎么对齐、DISM 和 PowerShell 两条命令路线各自的参数含义、常见报错码对应的排查方向以及给离线 WIM 批量注入 NetFx3 的做法。适合三类人看企业里做终端运维的、经常给工控机或内网机器装老软件的、以及自己装机时被这个弹窗卡住的普通用户。基础命令我会逐个参数解释命令行不太熟的朋友照着抄也能跑通。1. 为什么在 Windows 10/11 上离线装 .NET 3.5 变成了技术活1.1 还在依赖 .NET Framework 3.5 的三类软件先讲清楚为什么非装不可。.NET Framework 4.x 虽然向下兼容源码级别的 API但不兼容二进制一个针对 2.0/3.5 编译出来的 exe运行时绑定的是 2.0 版的 CLR如果你机器上只有 4.8它照样起不来除非厂商重新编译发布新版本。我实际遇到最多的三类行业软件的配套工具。老版 PLC 编程软件、老款示波器/频谱仪的上位机、几年前停更的数控系统通讯程序这类软件厂商早就不维护了安装包里硬编码依赖 3.5。企业内部的遗留系统。用 VB.NET 2008 或者 C# 2.0 时代写的小工具、报表程序、财务接口跑在一台台机器上十几年没人动过。安装程序本身。有些用 InstallShield 老版本打包的产品连安装引导界面都是 .NET 2.0 写的3.5 不装连下一步都点不到。判断方法很简单程序报错时提示需要 .NET Framework 3.5、或者直接抛System.IO.FileNotFoundException且缺的是 mscorlib 2.0.0.0 相关程序集基本就是这个原因。1.2 按需功能这个设计带来的连锁反应Windows 8 之后.NET 3.5 从默认安装改成了按需功能Feature on Demand。含义是系统里保留了这项功能的清单和注册信息但负载文件payload没有随系统落盘需要的时候再取。这个设计在联网环境下很省事——Windows 更新里挂着一个专门用来安装 NetFx3 的包点一下就好。但它带来三个副作用全都在离线环境里爆发第一负载从哪来是源的问题不是功能的问题。系统只认两个来源Windows 更新或者你用/Source指定的本地目录。没有源功能列表里勾了也没用。第二源必须和当前系统的版本、架构、语言对齐。这不是随便找个 NetFx3 的 cab 丢进去就能过DISM 会做版本比对。跨大版本混用必挂。第三企业环境的更新策略会直接掐死兜底路径。很多内网机器的更新源指向内部服务器NetFx3 的负载根本不在那台服务器上于是 DISM 在下载这一步超时失败报出来的错和源找不到长得很像容易误判。1.3 四种典型的离线现场把场景分清楚后面选方案会快很多现场类型特征推荐路径完全隔离的内网机无外网装了内部更新服务器安装介质提sources\sxs/LimitAccess单机新装系统有网但懒得等或更新被工具优化过挂载同版本 ISO直接指 sxs批量装机/自定义镜像要一次做完装完就出货给 offline WIM 注入 NetFx3测试通道的预览版本系统 build 比较新介质不好找优先修好在线路径其次找同 build 介质第四种情况我要单独说一句预览版本的系统Windows 更新上的按需包有时候确实取不到或者内部更新服务器上没有对应通道的内容。这种情况下如果机器本身能连外网把在线路径修通比折腾离线源省事得多因为在线路径会自己挑正确版本的包。2. 找准安装源sources\sxs 的来路、版本与架构对齐2.1 安装介质里的 sources\sxs 才是正牌货源正牌源是 Windows 安装介质ISO 或 U 盘根目录下sources\sxs这个文件夹。Windows 10/11 的介质里它是存在的体积我这边实测大多在300 MB 到 450 MB之间里面是一堆 cab 文件其中和 .NET 3.5 相关的那一个文件名长这样microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab中间那串31bf3856ad364e35是微软的公钥标记后面的amd64是架构标识。你只需要这一个目录不需要整个 ISO更不需要处理 install.wim 超过 4GB 怎么拷进 FAT32 U 盘的问题——这一点很多人绕远了。挂载 ISO 之后把sources\sxs整个复制到本地磁盘就行。除了安装介质还有两个合法来源可以拿到同样的负载Windows 功能按需Features on DemandISO。这个是独立提供的介质里面按语言和架构分了目录NetFx3 的负载在里面能找到适合手里只有某一版系统镜像、但又需要跨版本补包的场景。同版本同架构的另一台机器。在已经成功启用过 NetFx3 的机器上负载会落到C:\Windows\WinSxS里理论上可以拿来做源。但我实测这条路成功率不稳定组件存储里的命名和版本状态会被更新影响只在实在没有介质时才考虑。需要注意的是/Source指向的目录不必非要叫 sxs。你把内容拷到D:\netfx3src然后/source:D:\netfx3src一样能过。我习惯保留sxs这个目录名纯粹是为了半年后自己还能想起来这是什么。2.2 版本对齐winver 和 CurrentBuildNumber 要先看这是整个流程里最容易被忽略、也最容易导致失败的一步。先确认当前系统的准确版本再决定用哪份介质。打开 CMD 或者 PowerShell两条命令winver reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v CurrentBuild reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion /v UBRwinver图形窗口会告诉你版本和内部版本号比如 22H2、22621。CurrentBuild是主 buildUBR是累积更新的修订号。对齐原则按我的实测经验同 build 同架构基本一次过这是唯一能保证的路径。同一年份体系内的小版本差异比如 19044 的介质给 19045 用有时候能过取决于两次更新有没有动到 NetFx3 的负载版本。跨大版本比如拿 19045 的介质给 22631 用或者拿 Win10 的介质给 Win11 用不要浪费时间去试几乎必然报 0x800F081F。顺便说个反向验证的窍门如果/Source指定的目录里连对应架构的 netfx3 cab 都找不到DISM 不会去联网兜底加了/LimitAccess的情况下会很快就失败。所以报错来得特别快十几秒内大概率是路径或文件名的问题如果卡了几分钟才报错更像是它去尝试联网超时了。2.3 架构对齐amd64、x86、arm64 不能混用架构这条线也很硬操作系统是什么架构就必须喂什么架构的包。操作系统架构sxs 里的目标包标识常见来源64 位 x64~amd64~~绝大多数 x64 ISO32 位 x86~x86~~32 位 ISO如 1909 x86 版本ARM64~arm64~~ARM 版设备对应介质我在 32 位老机器上踩过一次手边只有 x64 的 ISO想着3.5 的包应该一样吧结果在sources\sxs里翻半天只看到 amd64 的 cab。32 位系统的介质里只带 x86 的负载反之亦然这是介质裁剪时按架构打的。另外提醒一句在 64 位系统上把整个sxs目录给它就行不要自作聪明只挑一个 cab 出来。目录里同时存在多个版本的同类 cab 是正常现象DISM 自己会挑合适的那个。2.4 手里没有对应介质时的三条路现实里最尴尬的情况就是系统是别人装的ISO 没有内部又没有文件服务器。这时候我有三条按优先级排的路线第一条用官方渠道重新下对应版本的 ISO。这是最干净的做法下完之后只取sources\sxs那一块几十上百 MB 的复制量几秒钟的事。企业里最好把每个在用的 Windows 版本的sxs存一份到文件服务器上一次投入长期受益。第二条把系统就地升级一遍。如果组件存储被清理过后面第 7 节会讲或者怎么都找不到介质可以用同版本 ISO 挂载后运行setup.exe选择保留个人文件和应用的升级方式。这个过程会把组件存储补齐升完之后 NetFx3 通常能装上。代价是时间长半小时到一小时而且必须提醒用户备份。第三条让机器的更新路径恢复可用。如果这台机器其实能出网只是更新策略把它拦住了那么修正策略比找介质快得多。判断方法就是看%windir%\Logs\CBS\CBS.log里报的是下载失败还是源文件缺失——这两个词的差别决定了你该往哪个方向使劲。3. 源放哪儿目录规划比命令更影响成功率3.1 本地磁盘优先副本命名带上版本号我的习惯是把 sxs 副本放在系统盘之外的本地磁盘路径尽量短命名带上版本信息例如D:\FOD\sxs_22621_amd64\ D:\FOD\sxs_19045_amd64\三个理由。第一路径短可以规避一些路径长度相关的边界问题DISM 处理长路径时的行为不太一致短路径最省心。第二多版本并存半年后系统升级了你一眼就知道该用哪份不用再翻 ISO。第三放系统盘之外重装系统时源还在。需要多少空间整个sxs目录就是 300 MB 到 450 MB另外 DISM 安装过程中会占用一部分临时空间用于展开和事务处理。我的经验是系统盘至少留 2 GB 空闲太紧的时候遇到过安装到一半失败的情况。安装完成后临时文件会自动清理实际占用的长期空间很小——只有 NetFx3 自身那部分负载会进WinSxS。另外如果你的介质只挂载不复制也可以直接从盘符引用/source:E:\sources\sxs。短时间装一台机器完全够用但缺点是一旦 ISO 被卸载、或者下次机器重启后盘符变了之前配的策略就指空了。所以我倾向于复制一份到本地。3.2 UNC 共享做备用源的讲究企业环境里更常见的是把 sxs 放在文件服务器上用 UNC 路径做源\\fileserver\software\FOD\sxs\22621\amd64这条路能用但有几个细节必须处理否则会出各种路径存在却读不到的怪问题权限要给到机器账户或全体用户可读。DISM 在启用功能时以 SYSTEM 身份执行一部分操作如果共享只给了某个用户组读权限机器账户访问不到就会失败。生产环境我一般给所有人读权限或者给域计算机组读权限。共享路径不要用映射盘符。映射盘符是登录会话级别的SYSTEM 身份访问不到。用\\server\share\...这种完整 UNC 格式。路径里别带中文和空格虽然多数情况能处理但徒增变量。共享的读取性能要考虑。从千兆网络读四五百 MB 再展开装一次两三分钟很正常如果网络慢或者共享存储本身繁忙DISM 的进度条长时间不动别急着判定失败先看磁盘队列。我自己在几百台机器的批量部署里最终选的是文件服务器放母本 部署脚本先复制到本地临时目录再安装。多花十几秒复制换来确定性值。3.3 一个校验小动作确认 sxs 没被截断复制大目录最怕中途断线。装之前花十秒钟确认一下目标目录里确实有 netfx3 的 cabGet-ChildItem -Path D:\FOD\sxs_22621_amd64 -Filter *netfx3* | Select-Object Name, {nSizeMB;e{[math]::Round($_.Length/1MB,1)}}正常应该能看到至少一个以microsoft-windows-netfx3-ondemand-package开头的 cab。如果这个命令什么都没返回要么目录拷错了层比如拷成了sources而里面没有sxs要么复制中断了。这一步能省掉后面一大堆猜测。4. DISM 与 PowerShell 两条实操路线4.1 DISM 命令的每个参数在干什么核心命令就一行这是我在所有 Windows 10/11 机器上用的版本dism /online /enable-feature /featurename:NetFx3 /all /limitaccess /source:D:\FOD\sxs_22621_amd64从左到右逐个说/online目标是在正在运行的系统上操作而不是离线镜像。用错了会报找不到指定的路径。/enable-feature启用功能对应/disable-feature是卸载。/featurename:NetFx3功能名必须精确写NetFx3大小写不敏感但不要写成.NET Framework 3.5。/all同时启用所有父功能和依赖项。NetFx3 在功能树里有父节点不加这个参数有可能出现启用了但状态不对的情况我建议一律加上。/limitaccess明确告诉 DISM 不要去向 Windows 更新索取负载。这是内网和隔离环境里最关键的一个参数不加它DISM 在本地源找不到的时候会去联网兜底白白多等好几分钟然后报 0x800F0906掩盖真正的问题。/source:负载所在的展开目录。几个我踩过的用法坑不要把它指到 install.wim 或者 ISO 根目录。/source:E:\sources\install.wim这种写法不成立源必须是展开的目录结构。指到E:\我也只在某些情况下见过成功不稳定老老实实指到 sxs 目录。执行前确认是管理员权限的命令行。普通权限运行会直接被拒报错信息很直白不会让你多猜。耐心看进度。DISM 的输出在 20% 到 40% 之间会停一会儿这是在做组件清单比对和事务准备。本地磁盘源一般一分钟内出结果网络源两三分钟也正常。想先看当前状态用这条dism /online /get-featureinfo /featurename:NetFx3输出里State : Enabled就是已经装好了State : Disabled才是需要装的。如果是Disabled with Payload Removed之类的措辞说明负载确实不在本地——这正是需要你喂源的原因。4.2 PowerShell 的等价写法不喜欢 DISM 命令行的PowerShell 有对应封装Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source D:\FOD\sxs_22621_amd64 -LimitAccess -NoRestart参数和 DISM 是一一对应的-All对应/all-Source对应/source-LimitAccess对应/limitaccess-NoRestart对应/norestart。用 PowerShell 有两个实际好处。第一个是容易做判断和批处理比如先探测介质盘符再决定要不要装$feat Get-WindowsOptionalFeature -Online -FeatureName NetFx3 if ($feat.State -ne Enabled) { $src D:\FOD\sxs_22621_amd64 if (Test-Path (Join-Path $src microsoft-windows-netfx3-ondemand-package~31bf3856ad364e35~amd64~~.cab)) { Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source $src -LimitAccess -NoRestart } else { Write-Warning 源不完整先检查 sxs 目录$src } }第二个好处是错误信息比 DISM 更容易被脚本捕获。try/catch能拿到异常对象里面带着错误码适合放进自动化部署流程里做分支处理。有一点要提醒PowerShell 的Enable-WindowsOptionalFeature在部分较老的 build 上对-LimitAccess的支持不太一致如果发现参数无效直接退回去用dism.exe调外部命令反而更可靠。4.3 图形界面里点启用为什么也失败控制面板 → 程序和功能 → 启用或关闭 Windows 功能 → 勾选 .NET Framework 3.5这条路径在离线环境里基本是必挂的。原因是它默认先走 Windows 更新本地没有负载也没有配置备用源时它只能下载下载不通就报错而且报的错信息量比 DISM 小得多。但它不是没用。只要你在系统里配置了备用源文件路径策略下一节讲图形界面会直接去找本地源不再弹需要从 Windows 更新下载文件的框。对不太熟悉命令行的同事来说把策略配好之后让他们自己点勾选是最省事的落地方式。4.4 给离线 WIM 注入 NetFx3批量装机的正确姿势如果你在做自定义镜像或者批量装机比装完系统再装 3.5更高效的做法是直接把 NetFx3 注入到 install.wim 里装机时开箱即用。流程是挂载、注入、提交三步dism /get-wiminfo /wimfile:D:\ISO\sources\install.wim mkdir C:\mount dism /mount-image /imagefile:D:\ISO\sources\install.wim /index:1 /mountdir:C:\mount dism /image:C:\mount /enable-feature /featurename:NetFx3 /all /limitaccess /source:E:\sources\sxs dism /image:C:\mount /get-featureinfo /featurename:NetFx3 dism /unmount-image /mountdir:C:\mount /commit几个必须注意的点/index要选对。一个 install.wim 里通常有家庭版、专业版、企业版多个索引用/get-wiminfo看清楚哪个是你实际要部署的版本。选错了等于白干。挂载需要相当的空间。WIM 展开后是十几个 GB 的规模挂载点所在分区要留足我一般直接给 30 GB 以上。/image:而不是/online:。挂载状态下用/online会去动你正在运行的系统那就出大事了。注入前先用/get-featureinfo /image:C:\mount确认当前状态注入后再查一次看到Enabled再提交。提交时用/commit不加就是丢弃改动。不要在挂载状态下直接改目录文件改动要通过 DISM 操作手动动文件会破坏组件存储的一致性。镜像改好之后后续所有从这份镜像装出来的机器NetFx3 都是已启用状态装机流程里就再也不用管这件事了。这是我在需要部署几十台以上同型号机器的场景里最推荐的方案。4.5 用策略把源钉住让图形界面和后续修复都能自动找到包前面说的都是我手动指定源。更省心的做法是在系统里配置一个长期有效的备用源路径这样任何按需功能的安装和组件修复都会自动去那里找负载。图形路径在计算机配置 → 管理模板 → 系统 → 指定可选组件安装和组件修复的设置。三个要点启用策略。把备用源文件路径填成你的 sxs 目录比如D:\FOD\sxs_22621_amd64或者 UNC 共享路径。把从不尝试从 Windows 更新下载负载设上避免它在本地源找不到时偷偷去联网等超时。对应的注册表位置在HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing LocalSourcePath (REG_EXPAND_SZ) D:\FOD\sxs_22621_amd64 RepairContentServerSource (DWORD, 2) 直接从 Windows 更新取修复内容如果你的环境里有内部更新服务器还要额外把直接从 Windows 更新下载修复内容而不是从内部更新服务器这一项设上否则某些修复请求会被路由到内部服务器而那里没有 NetFx3 的负载结果就是继续报 0x800F0950。手工改注册表的话注意LocalSourcePath的类型要选可扩充字符串值REG_EXPAND_SZ选成普通字符串在某些路径含变量的情况下会失效。策略配好之后最大的收益不是这一次装上了而是以后每次系统更新需要重新对齐组件、或者某个功能损坏需要修复时系统都能自己找到源。这在没有外网的环境里能省掉大量重复劳动。5. 报错对照与排查链路从日志顺藤摸瓜5.1 常见报错码的含义和触发条件报错码提示大意我这边最常见的触发条件先做什么0x800F081F找不到源文件路径写错、sxs 里没有对应架构的 cab、介质与系统 build 差太远核对路径和 cab 文件名换同版本介质0x800F0906无法下载所需文件没加/LimitAccessDISM 想联网兜底但出不去补上参数再确认更新源策略0x800F0950无法完成请求的更改和上面同源Windows 11 上措辞不同常伴更新策略拦截看 CBS 日志判断是下载还是源问题0x800F0907操作未完成源目录里有 cab但架构或语言不匹配或者文件本身损坏换介质重新复制源目录0x800F0922系统分区空间不足类提示少见于此功能主要出现在累积更新上检查系统保留分区和系统盘空间我反复强调的是这批错误码本身的信息量很有限真正有价值的判断都在日志里。同一个 0x800F081F可能是路径问题也可能是组件存储被精简过处置方式完全不同。5.2 第一步永远是看日志而不是反复重试两个日志文件位置固定%windir%\Logs\DISM\dism.log %windir%\Logs\CBS\CBS.logCBS.log 被系统占用直接搜有时候会失败我的做法是先复制一份出来再搜copy %windir%\Logs\CBS\CBS.log %temp%\cbs_copy.log findstr /i netfx3 %temp%\cbs_copy.log findstr /i 0x800f %temp%\cbs_copy.logdism.log 可以直接搜findstr /i netfx3 %windir%\Logs\DISM\dism.log判断方法简单粗暴但有效搜到的行里出现 download、WU、Windows Update 之类的字眼说明它走的是联网路径问题在策略和出口出现 source、payload、not found、SXS 之类的字眼说明问题在本地源去核对路径、版本、架构。这两个方向的处理方式完全不同先分清能省掉一半时间。还有一个很多人不知道的日志%windir%\Logs\CBS\Poqexec.log。它记录的是组件安装的事务处理过程当安装卡在某些奇怪的状态、或者提示需要重启但重启后依然没装上时这个日志里能找到线索。5.3 0x800F081F 的两条分支这个错最常见我把它拆成两种典型情形。情形一源本身不对。表现是报错来得很快十几秒内就有结果。原因是/source路径打错、目录层级多了一层或者少了一层、介质版本差太远。快速验证方法Test-Path D:\FOD\sxs_22621_amd64 Get-ChildItem D:\FOD\sxs_22621_amd64 | Measure-Object -Property Length -Sum | ForEach-Object { [math]::Round($_.Sum/1MB,1) }目录不存在就是路径问题存在但总大小只有几十 MB说明复制不完整总大小正常但里面没有 netfx3 的 cab说明这份介质里这个功能的负载被裁掉了。情形二组件存储被清理或损坏。表现是路径、版本、架构全部核对无误换了多份介质依然报同样的错。这时候通常是系统被人优化过——用了第三方精简工具或者执行过组件存储清理把版本状态搞乱了。判断方法是在C:\Windows\servicing\Packages里找 netfx3 相关的 muma 清单文件如果没有说明系统层面已经不认这个功能了。情形二的处置只有一条路用同版本 ISO 做就地升级修复把组件存储补齐然后再装 NetFx3。别指望换个源就能解决。5.4 0x800F0906 和 0x800F0950被策略和网络掐断这两个错误和 081F 的区别在于——本地源其实没问题是兜底路径走不通。典型表现是命令执行后卡着不动好几分钟然后才报错。三步处置第一加/LimitAccess。这是最重要的一步它让 DISM 放弃联网直接用本地源报错会立刻变得有意义。第二检查更新策略。内网环境里常见的是更新源被指向内部服务器而那台服务器上没有 NetFx3 的负载。这时候要么用策略把修复内容的来源改回 Windows 更新如果机器能出网要么按照 4.5 节把本地源路径配好让系统从本地取。第三检查系统盘空间。系统盘快满的时候DISM 也可能在事务阶段失败报出来的错和上面的很像。我遇到过系统盘只剩几百 MB 的机器清出空间后一次就过。5.5 预览版本 build 上的特殊情形测试通道的 build比如各种四位数五位数的内部版本号是最麻烦的。这类系统上在线路径上对应的按需包不一定及时存在而离线介质更是几乎拿不到。我的处置顺序是先修在线路径。检查系统能不能访问更新服务、内部服务器上有没有对应通道的内容、有没有被更新策略拦住。如果这台机器本来就该出网修通在线路径比去找一份不一定存在的介质现实得多。如果确实是完全隔离环境那就只能从能联网的同 build 机器上想办法或者评估是不是可以换个更常规的系统版本——为了跑一个老软件把整台机器的版本搞成必须同步维护的状态长期来看是负担。6. 装完怎么确认真的生效四层验证6.1 第一层DISM 状态和注册表dism /online /get-featureinfo /featurename:NetFx3看到State : Enabled是第一层通过。第二层看注册表reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5 /v Install reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 /v InstallInstall值为0x1表示已安装。注意 3.5 是包含 2.0 和 3.0 的累积版本所以正常情况下 v2.0.50727、v3.0、v3.5 三个键都会出现。如果只有 v3.5 而没有 v2.0.50727那说明装得不完整老程序照样跑不起来。6.2 第二层目录和 csc.exe 编译自测看目录dir %windir%\Microsoft.NET\Framework\v3.5 dir %windir%\Microsoft.NET\Framework64\v3.564 位系统上两个目录都应该有内容。Framework64下面空着或者不存在说明 64 位侧的组件没装上。最后一层是我最信得过的——直接编译一个最小程序跑一下class T { static void Main() { System.Console.WriteLine(netfx35 ready); } }保存成t.cs然后C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe /nologo t.cs t.exe能看到输出就说明运行时和编译器都在位。这个方法比看任何状态都实在因为它验证的是程序真能跑而不是系统说它能跑。测试完记得把生成的 exe 删掉别留在生产目录里。6.3 第三层应用侧的最终验证最后一定要拿真正要用的那个老程序跑一遍。我踩过的情况是NetFx3 装好了、编译测试也过了但目标程序是个 .NET 2.0 时期的 WinForms 程序还得依赖某些已经被后来的更新移除掉的兼容性设置或者需要额外的运行库配置。常见的一类问题是程序的配置文件里没有明确supportedRuntime在新的 CLR 加载策略下行为异常。解决办法是在应用程序目录下加一个同名.exe.config明确指定configuration startup supportedRuntime versionv2.0.50727/ /startup /configuration这类调整要看具体程序但思路是统一的NetFx3 是运行环境程序能不能跑还取决于它自己的配置别把应用层的问题误判成系统层的问题。7. 几个我踩过的坑和后续维护习惯7.1 精简镜像和组件存储清理的后果这是所有坑里最难处理的。第三方精简的 Windows 镜像或者生产环境里有人执行过组件存储清理操作会把这些按需功能的负载和版本状态破坏掉。表现就是你手里有完全正确的源路径、版本、架构无一错漏它照样报 0x800F081F。判断这类机器的特征C:\Windows\servicing\Packages目录里清理得异常干净、dism /online /get-features输出的功能列表比正常机器少一截、或者系统体积明显偏小。遇到这种机器我的建议是不要在这上面耗时间。要么用同版本 ISO 就地修复升级要么直接重装。我曾经在一台被精简过的机器上折腾了两个多小时换过四份介质最后用就地升级十五分钟解决——早该这么干。另一条相关经验不要在需要 NetFx3 的机器上随意跑第三方清理工具。有些清理工具会删掉WinSxS里的冗余备份装的时候不觉得有问题等到某个功能需要修复时才会发现组件存储已经没法用了。7.2 盘符、路径长度和权限这些琐碎但要命的事几个具体细节都是吃过亏的挂载 ISO 得到的盘符不固定。在有多块磁盘、多个分区的机器上ISO 可能是 E 也可能是 F。写脚本时不要硬编码盘符用卷标或者探测sources\sxs是否存在来判断$cands (Get-Volume | Where-Object { $_.DriveLetter }).DriveLetter | ForEach-Object { $($_):\sources\sxs } $src $cands | Where-Object { Test-Path $_ } | Select-Object -First 1路径长度。把 sxs 放在层级很深的目录里加上系统本身的长路径偶尔会出问题。我固定在D:\FOD\下放就是为了让路径尽量短。权限。用 UNC 共享时务必确认机器账户能读到。测试方法是以 SYSTEM 身份去访问——psexec -s cmd之后再dir \\fileserver\share能列出来才算真的通。这一步不做后面报错会绕很久。盘符在重装后变化。如果你把源路径写进了注册表策略而路径所在的分区盘符在维护后变了策略就指空了。所以我更倾向用 UNC 或者固定的挂载点。7.3 每月更新之后这份 sxs 还留不留答案是留而且按版本分目录留。原因是每次累积更新之后系统的组件版本会往前走某些老的源可能就不匹配了。但历史上成功的源在相当长时间内仍然可用尤其是同一大版本体系内的。我的做法是文件服务器上建一个FOD目录按版本号架构分子目录。每次下载新的系统 ISO 时顺手把sources\sxs复制进去几百 MB 的事。定期清理两代以前、已经不再维护的系统版本对应目录但保留至少一份。这个过程的价值在半年后集中爆发某台机器突然需要装 .NET 3.5你不用去翻当时的安装 U 盘直接从服务器上取五分钟解决。我自从建立这个习惯之后这类临时需求基本没再占用过超过十分钟的时间。最后一个个人习惯每台装过 NetFx3 的机器我都会顺手把那条生效的 DISM 命令和源路径记在运维记录里。不要小看这一步一年后你需要在一台备份恢复出来的机器上重做一遍时有这条记录和没这条记录差别可能是半小时和三分钟。
