Windows Server 2012 R2离线安装.NET 3.5排错

简介：面向在 Windows Server 2012 R2 与云服务器上安装 .NET Framework 3.5 屡次失败、被提示「找不到源文件」或「请使用源选项指定还原该功能所需的文件位置」的运维与开发人员，这份离线源文件集合可配合 DISM 指定源路径完成功能还原，免去逐台翻找系统镜像。压缩包共1568个文件、约99.19MB，以720个dll动态库、180个resx资源、84个exe程序为主体，并含aspx页面、config配置、sql脚本、browser浏览器定义、ini与tlb类型库等，目录层级贴近系统原生安装源，便于按版本与架构检索。已有10328人下载学习，适合批量部署与排错场景长期留存备查。

1. 一句「无法安装 .NET Framework 3.5」能耗掉一整天

服务器上跑 SQL Server 安装程序，走到先决条件检查那一步停住，提示需要 .NET Framework 3.5；转到服务器管理器把功能勾上，进度条又退回来，报错 0x800F0906。来回折腾，一天就没了。Windows Server 2012 和 2012 R2 上这类故障特别常见：系统默认不携带 .NET Framework 3.5 的安装源，它属于「按需功能」，没法像普通软件那样下个 exe 双击了事，必须从系统组件源里取文件。机房没外网、更新走内网服务器、装机 ISO 早不知道扔哪去了，三件事凑一起就是个死循环。下面按报错码逐个拆，命令都能直接抄。

2. 0x800F0906 和 0x800F081F：先分清是「拿不到源」还是「源不对」

这两个错误码长得像，处理方式却完全相反。前者是系统根本没拿到组件文件，后者是拿到了但内容对不上。很多人一看到报错就去搜「.NET 3.5 离线安装包」，下回来一个 exe 双击，装完提示成功，回头 SQL Server 还是拦着不让过——因为那条路根本没走系统的组件安装通道。判断顺序应该是：先看错误码，再看有没有指定源，最后才谈补文件。

2.1 四个错误码对应的四种处境

先把错误码和处境对上，能省掉一大半试错时间：

0x800F0906 是最常见的一个。它出现的前提是：你执行了启用功能的命令，但没告诉系统去哪儿找文件，系统就默认去 Windows Update 拿。机房里的服务器十有八九出不去，于是超时、重试、失败。反过来，一旦你加了/Source参数，错误码就会变成 0x800F081F——这不是变严重了，而是问题从「拿不到」变成了「对不上」，方向反而明确了。

0x800F0907 容易被误判成权限问题。它其实是策略层的拦截：内网更新服务器通常只批准安全补丁，不会批准「按需功能」这类组件包，系统去问了一圈被告知没有，就返回这个码。看到它别急着改服务启动类型，改服务没用。

2.2 用系统 ISO 的 sources\sxs 当源：一条命令解决 0906

手边有对应版本的系统 ISO，这是最省事的路子。挂载 ISO（假设盘符是 D:），确认sources\sxs目录存在，然后执行：

:: 先确认源目录真的存在，这一步别省，路径写错一样报 081F dir D:\sources\sxs :: 在线启用 NetFx3，只从本地源取文件，不回 Windows Update dism /online /enable-feature /featurename:NetFx3 /all /Source:D:\sources\sxs /LimitAccess

参数逐个说清楚，改的时候心里有数：

/LimitAccess值得单独强调。不加它，DISM 在本地源里找不到文件时仍会尝试联网，于是先卡几分钟，最后抛一个 0906 或者更含糊的 0x800F0906 变体，让你误以为是源的问题。加上它，找不到就直接报 081F，排查方向立刻清晰。

执行过程中进度条长时间停在 20% 是正常的，这不是卡死。DISM 的进度按阶段推进，解压和注册组件占大头，机械盘上跑五到十分钟不奇怪。判断是否真卡住，看日志文件的修改时间还在不在往前走，比盯进度条靠谱。

2.3 域环境里更新被指到内网：0x800F0907 的处理

域内机器上，Windows Update的地址通常被组策略改成了内网服务器。这时候即使你加了本地源，某些场景下 DISM 仍会先去问策略里配置的地址。临时把这条策略关掉，能让排查路径干净很多：

:: 把「使用内网更新服务器」这一项临时置 0 reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f :: 重启两个相关服务，让改动生效 net stop wuauserv net stop bits net start wuauserv net start bits

这里改的是HKLM\SOFTWARE\Policies\...下的策略键，不是普通配置项。它的特点是优先级高，本地改了在下一次组策略刷新时可能被域里重新覆盖回来。所以我一般把它当临时手段用：装完 .NET 3.5 立刻改回 1，再跑一次gpupdate /force确认策略回到原样。这类改动属于「后悔药」，吃完得把药瓶放回去，不然哪天补丁打不上，又要重新查一遍。

如果不想动策略，正规做法是/Source加/LimitAccess组合，完全不依赖 Windows Update 的任何路径。这也是我在生产环境里优先选的方式——它对系统状态的侵入最小。

2.4 装完怎么验证：功能状态和注册表两处都要看

命令返回「操作成功完成」不等于事情结束。我见过好几次返回成功但功能实际处于「挂起」状态，重启后才真正生效，期间 SQL Server 依然拦。验证要看两处：

:: 第一处：功能当前状态，正常应为 Enabled dism /online /get-featureinfo /featurename:NetFx3 :: 第二处：注册表里的安装标记，Install 应为 1，SP 应为 1 reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install

第一处的输出里如果 State 显示Enable Pending，说明组件已经落地但还没完成收尾，重启一次即可。第二处的Install值是安装程序判断「装没装」的主要依据，很多第三方安装包（包括数据库安装程序）读的就是这个键，而不是去检查磁盘上有没有那几个 dll。这一点很关键，第 4 章会展开讲它引发的「假故障」。

3. 离线环境没有 ISO：用 sxs 源包补齐组件源

机房不通外网、装机 ISO 又找不到，是最难受的一种情况。这时候要么从别处拷一份对应版本的sources\sxs目录过来，要么从系统镜像的install.wim里把组件掏出来。这里用的离线源包，本质就是把这一步提前做完了：里面是一份与系统版本匹配的按需功能组件源，配一个把解压、指定源、启用功能串起来的脚本，省掉手工找目录的环节。

3.1 源包里的东西和系统要的东西怎么对上

系统要的其实就一样东西：microsoft-windows-netfx3-ondemand-package.cab，放在sources\sxs目录下，版本、架构、语言三者与目标系统严格一致。理解这个对应关系，很多 081F 就自动解释清楚了：

• 版本：Windows Server 2012 的内核版本是 6.2.9200，2012 R2 是 6.3.9600。两个版本的组件包不通用，拿 R2 的源去装 2012，必然 081F。
• 架构：x64 系统要 x64 的包，32 位包放进去照样报找不到。
• 语言：语言中立包最保险；如果源里只有带语言标记的包，而系统语言对不上，同样失败。

所以拿到任何一份离线源，第一件事不是急着执行命令，而是核对它属于哪个版本。核对方法见 3.3，一条systeminfo就够。

3.2 解压到本地再指定源：完整可抄的流程

先把压缩包解开。路径里不要带中文和空格，DISM 对这类路径的容忍度不高，出问题时日志也难看懂：

# 解压到固定目录，-Force 覆盖旧内容，避免残留半份文件 Expand-Archive -Path D:\pkg\settled_.net3.5install.zip -DestinationPath C:\sxs_src -Force # 确认 sxs 目录和解压出来的 cab 文件都在 Get-ChildItem C:\sxs_src -Recurse -Filter *.cab | Select-Object FullName, Length

Expand-Archive是 PowerShell 内置命令，2012 上自带，不需要额外装解压软件。-Force覆盖的意义在于：上一次解压中断留下的残缺文件，会让 DISM 读到一半报校验失败，表现出来又是一个莫名其妙的 081F。宁可整目录重来，也别在残骸上续。

确认目录结构后启用功能：

:: 把源指向解压出来的 sxs 目录本身，不是它的上级目录 dism /online /enable-feature /featurename:NetFx3 /all /Source:C:\sxs_src\sxs /LimitAccess

这里最容易错的是/Source的层级。指向C:\sxs_src会失败，指向C:\sxs_src\sxs\microsoft-windows-netfx3-ondemand-package.cab这个文件也会失败——DISM 要的是目录，而且必须是包含 cab 的那一层。报错依旧是 081F，看不出层级问题，只能靠对目录结构。

如果解压出来是散装的 cab 而不是sxs目录，就自己建一个同名目录，把所有 cab 放进去再指过去。

3.3 只有 install.wim 没有 sxs 目录：挂载提取

有些 ISO 精简过，sources\sxs被删了，只剩install.wim。好消息是组件在 wim 里也有，只是藏在WinSxS下，需要挂载后翻出来。先看 wim 里有几个索引，别瞎猜：

:: 列出镜像索引，确认哪个是带 GUI 的版本 dism /get-wiminfo /wimfile:E:\sources\install.wim :: 挂载为只读，避免误改镜像文件 dism /mount-wim /wimfile:E:\sources\install.wim /index:2 /mountdir:C:\mount /readonly :: 在挂载目录里找 NetFx3 相关的组件包 dir C:\mount\Windows\WinSxS | findstr /i netfx3

索引号很关键。/index:2通常对应标准版（带 GUI），/index:1往往是 Server Core。选错索引，拷出来的组件和当前系统对不上，还是 081F。用systeminfo看当前系统是哪个版本，再回去对 wiminfo 的输出，两边一致了再挂载。

拷完文件记得卸载，/readonly挂载的用/discard丢弃挂载点即可，不会污染原镜像：

dism /unmount-wim /mountdir:C:\mount /discard

如果卸载时报「目录被占用」，八成是资源管理器或某个命令行窗口正停在这个目录里，退出去再执行。

3.4 PowerShell 的 Install-WindowsFeature 也能指定源

懒得记 DISM 参数的话，PowerShell 这条更顺手，尤其适合写进初始化脚本批量跑：

# 先看功能当前状态，避免重复安装 Get-WindowsFeature -Name Net-Framework-Core # 直接从 wim 的指定索引取源，冒号后面那个数字就是索引号 Install-WindowsFeature -Name Net-Framework-Core -Source WIM:E:\sources\install.wim:2

-Source支持两种写法：一种指向sxs目录路径，一种用WIM:路径:索引的格式直接读镜像。第二种省掉了解压步骤，但每次执行都要读镜像，慢一些，且索引号写错会直接失败。Net-Framework-Core是 PowerShell 里 .NET 3.5 的功能名，和 DISM 里的NetFx3是同一个东西的两个名字，混用会提示找不到功能，这是新手最容易卡住的地方。

装完用Get-WindowsFeature -Name Net-Framework-Core复核一遍，Install State显示Installed才算落地。

4. SQL Server 仍然提示需要 .NET 3.5：三处容易误判的细节

功能装完了，回头再跑数据库安装程序，还是那句「需要 .NET Framework 3.5」。这时候问题往往不在组件本身，而在检测逻辑、版本匹配或者一个没做完的重启。这三处坑我都踩过，每次都得翻日志才回过神来。

4.1 安装程序读的是注册表，不是磁盘上有没有文件

这是最常见的一类「假故障」。有人图省事，直接从别的机器拷v3.5目录下的 dll 过来，或者装了个第三方的精简运行库。磁盘上文件齐全，程序也能跑，但注册表里HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5下的Install值压根没写。数据库安装程序在做先决条件检查时读的就是这个键，读不到就判定未安装。

还有一种更隐蔽的情况：64 位系统上存在两个注册表视图，某些 32 位的检测程序会去WOW6432Node下面找。两边都查一遍，心里才踏实：

:: 64 位视图 reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install :: 32 位视图（某些安装程序走这条） reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\NET Framework Setup\NDP\v3.5" /v Install

两个位置都返回Install REG_DWORD 0x1才算稳妥。只有一个有、另一个没有，说明当初的安装路径不完整，最干净的解法是卸掉重来，用第 2、3 章的方式走正规通道装一遍，别在残缺状态上打补丁。手工补注册表值能骗过检测，但运行时会缺程序集，后面报的是另一类错，更难查。

4.2 装完提示成功但仍在拦：先看是不是「挂起」状态

Windows 的组件安装有个特性：文件落地和状态生效是两回事。系统在有待重启的挂起操作时，新的组件安装会被标记为 pending，表面上返回成功，实际要重启才完成。数据库安装程序这时去查，依然认为没装。

判断方法很简单，看两个挂起标志：

# CBS 挂起：组件安装服务有待完成的操作 Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending" # 文件重命名挂起：有文件等着重启后替换 (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).PendingFileRenameOperations

任意一个返回真，别犹豫，直接重启。我吃过一次亏：为了省事跳过重启，反复重装数据库安装程序，装了三遍都失败，日志里全是「先决条件不满足」，重启后一次就过了。这种亏吃过一次就记住了。

重启之后如果还是拦，再去看组件存储日志。C:\Windows\Logs\CBS\CBS.log里搜错误码，能看到具体是哪个组件包解压失败：

# 只看最近 20 条带错误码的记录，日志太大不要整份打开 Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "0x800f" | Select-Object -Last 20

4.3 2012 和 2012 R2 的源不能混用

这是 081F 的头号成因，也是最容易被忽略的。两台机器在服务器管理器里长得几乎一样，实际内核版本差一个大版本。拿错源的表现是：命令语法全对，源目录也确实有 cab 文件，就是报 081F，让人怀疑人生。

动手前先花十秒确认版本：

:: 看 OS 名称和版本号，6.2.x 是 2012，6.3.x 是 2012 R2 systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

版本号对上了，再看源的来源。我的习惯是把源包按版本分目录存放，目录名直接带版本号，取用时不至于拿错。生产环境里我见过一次事故：运维同事用同一份源给一批服务器装，其中混了两台不同小版本的机器，结果一半成功一半失败，排查了两小时才发现是源的问题，不是命令的问题。

另外，打了系统补丁之后，组件版本理论上仍向下兼容，但极小概率出现源里的包比系统已装的还旧，DISM 会拒绝降级。遇到这类情况，优先从当前系统的安装介质取源，而不是从旧备份里翻。

4.4 装完 .NET 3.5 之后，数据库安装还可能卡在别的先决条件

.NET 3.5 只是第一道门。数据库安装程序的先决条件检查是一串的，3.5 过了之后可能立刻提示下一项不满足，让人误以为 3.5 没装上、在原地打转。实际上它已经推进了，只是报错文案相似。

区分方法：看安装程序日志里的检查项名称。每一项先决条件都有独立的名字，卡在不同的项上，说明进度在往前走。这时候不要回头重装 .NET 3.5，去处理新的那一项，否则就是典型的「修好了 A，反复拆 A，B 一直没动」。

还有一种情况是装完 3.5 后立刻执行安装，系统还在后台做组件注册，CPU 占用居高不下。等几分钟，或者干脆重启一次再装，成功率明显高一些。这类等待看起来玄学，实际上是 CBS 在写组件存储，抢在这一步插进去，安装程序读到的状态就是半成品。

5. 常见问题与避坑：五个反复遇到的坑

这一节把前面零散提到的坑集中列一遍，按「现象 → 原因 → 解决」写，遇到对应现象直接对号入座即可。

5.1 进度条停在 20% 十几分钟不动，以为卡死强退了

现象：执行 DISM 命令后进度条长时间停在 20%，看起来毫无反应，有人直接 Ctrl+C 中断。

原因：DISM 的进度是按阶段展示的，不是按文件数量。解压组件包、注册到 WinSxS 这一步耗时最长，机械盘或者系统盘 I/O 吃紧时会明显变慢，但进程仍在正常工作。中断的后果是组件装了一半，留下一个挂着 pending 状态的功能，后续无论怎么装都报冲突。

解决：判断是否真卡住，看日志文件有没有在长大：

# 隔十几秒执行一次，LastWriteTime 还在变说明仍在工作 Get-Item C:\Windows\Logs\DISM\dism.log | Select-Object LastWriteTime, Length

时间在更新就继续等。真要中断，中断后先执行一次dism /online /cleanup-image /revertpendingactions清掉挂起动作，再重新来，别直接重试。

5.2 源目录明明存在，还是报 0x800F081F

现象：/Source指向的路径用dir能看到一堆 cab 文件，命令执行仍报找不到源文件。

原因：三种可能——路径层级指错（指到了 sxs 的上一级或具体文件）、源版本与系统不匹配、cab 文件不完整。第三种最隐蔽，压缩包传输中断或者解压时被安全软件拦掉一个文件，目录看着是满的，实际少一个。

解决：先核对路径层级，/Source必须指向包含 cab 的那一层目录；再用systeminfo核对版本；最后比对文件数量和解压包里的清单。三步走完还不行，换一份源包重新解压，别在原目录上修修补补。

5.3 提示安装成功，数据库安装程序照样拦

现象：DISM 返回「操作成功完成」，Get-WindowsFeature也显示已安装，但数据库安装程序在检查阶段仍然报需要 .NET 3.5。

原因：多半是挂起状态未完成，或者安装程序读的是另一个注册表视图。前者重启即可，后者需要两个视图都确认一遍。

解决：先重启，再执行第 4.1 节的两条reg query，两个位置都返回 0x1 才算真装好。只有一个位置有值，说明安装路径不完整，卸了重装比补注册表靠谱。

5.4 域环境下改完策略，过一会儿又被覆盖回去

现象：按 2.3 节把UseWUServer改成 0，装完 .NET 3.5 忘了改回，或者改回了但下次组策略刷新又被域里的设置覆盖，表现为时好时坏。

原因：Policies路径下的键由域策略统一管理，本地修改的优先级低于域下发，刷新周期一到就被刷回去。

解决：这类改动只当临时手段。装完立刻改回原值并执行gpupdate /force验证。如果长期需要在这台机器上装组件，正规做法是让管理员在内网更新服务器上批准对应的按需功能组件，而不是每次手动改注册表。

5.5 系统盘空间不足，报 0x800F0922

现象：命令跑到一半失败，错误码 0x800F0922，或者提示组件存储损坏。

原因：组件安装需要往WinSxS写文件，系统盘剩余空间不足时直接失败。这个错误码含义比较泛，空间不足是其中最常见的一种。

解决：先看剩余空间，至少留出 2 到 3 GB 的余量，再清理组件存储：

:: 清理被替换的旧组件版本，能腾出可观空间，执行时间较长 dism /online /cleanup-image /startcomponentcleanup

清理完成后重新执行安装命令。如果提示组件存储本身损坏，加/ResetBase参数前务必确认没有正在回滚的更新，这个操作不可逆。

6. 快速定位这类组件安装故障：我固定的六步顺序

被这类问题折腾过几轮之后，我形成了一套固定顺序，基本能在十分钟内把范围缩小到具体哪一环。顺序的价值在于：每一步都能排除掉一批可能性，不至于在错误的方向上反复试。

这张表里，第 2 步和第 6 步是最容易被跳过的。跳过第 2 步的人会在一台已经装好的机器上反复重装，跳过第 6 步的人会在挂起状态下得出「装了没用」的错误结论。我的血泪经验是：任何一次组件安装之后，只要没重启，就不要相信任何验证结果。

还有一个习惯值得养成：把/LimitAccess当成默认参数。只要是有本地源，一律加上，让系统彻底不去碰 Windows Update。这样报错永远只有 081F 一种形态，排查复杂度直接减半。不加的话，每次都要先等它联网超时，再猜到底是网的问题还是源的问题。

日志别等症状严重了才去看。C:\Windows\Logs\DISM\dism.log和C:\Windows\Logs\CBS\CBS.log这两个文件，在命令执行完的当下看一眼，比事后回溯效率高得多。CBS 日志动辄几百 MB，别整份打开，用Select-String按错误码过滤最后几十行，足够定位。

从那以后我每次给新服务器上架，第一件事就是把对应版本的离线组件源和一份安装脚本放到固定的本地目录，写进装机清单，再也没出现过装到一半发现没源、临时找 ISO 的窘境。资源就在那儿，按第 3 章的流程解压、指定源、启用功能，三步走完，剩下的交给重启。希望帮到你。

本文还有配套的精品资源，点击获取