i386完整包：Windows驱动安装与离线修复源目录实战-平芜编程栈

简介：i386文件完整包面向需要维护Windows系统、排查启动与驱动故障的用户，尤其适合接触Windows Server及桌面系统安装修复场景的运维人员。资源围绕Windows安装源文件整理，可用于系统安装、更新、修复和升级时的文件提取与替换，帮助读者在驱动错误、系统崩溃等情况下找到可用的源文件参考。RAR压缩包约532.59MB，上游未标注具体文件总数与类型明细，包内以Windows系统安装相关文件为主，涉及驱动程序、DLL、应用程序及配置文件的补充与调用。已有869人学习下载，适合用作系统维护时的资料备份与对照查取，也可辅助理解i386目录在Windows源文件管理中的作用，提升故障排查与手动修复的实操把握。

1. i386 不是安装盘的残渣：一次“找不到 oem.inf”的现场，把我逼回了源目录

给一台还在服役的 Windows Server 加装一块老阵列卡，驱动装到最后一步，弹窗跳出来一句“找不到 i386 目录下的 oem12.inf，请插入安装介质”。这台机器没有光驱，随机介质早就不知道躺在哪个仓库角落，共享盘上的旧目录也早就被清理掉了。绕了一圈之后，解决问题的动作其实只有一个：把一份完整的 i386 文件包放回本地磁盘或内网共享，再把系统指过去。

i386 是 32 位 x86 安装介质里的源目录名，里面装的是压缩后的组件 CAB、驱动 INF 与签名目录、安装清单和应答脚本。它是 Windows 操作系统在装驱动、加组件、做离线修复时回查的“原件库”，也是 Windows Server 维护存量机器时最常被翻出来的一类资源。这份完整包解决的正是源介质丢失、光驱不可用、内网共享下线导致的安装中断。适合维护存量服务器的运维、给老设备装驱动的工程师，以及需要离线修系统文件的场景。

2. 拆开 i386：CAB 压缩、INF 签名与 setupapi 的回查顺序

拿到一个几十上百 MB 的目录，第一反应不该是直接往系统盘里一丢。先搞清楚里面每一类文件是被谁读的、缺了会怎样，后面指路径的时候才知道该指到哪一层。

2.1 目录里到底躺着哪几类文件

i386 看着杂，其实按“谁读它”可以分成五族。很多“包不完整”的问题，本质是缺了其中某一族，而不是文件数不够。

文件族	典型文件	作用	缺失后果
安装清单	layout.inf、drvindex.inf、txtsetup.sif	声明有哪些文件、放哪、怎么装	安装器直接判定源无效
驱动合集	driver.cab、sp*.cab	系统自带驱动打成一个包	装驱动时反复弹“找不到文件”
组件压缩包	.ca_、.dl_、*.ex_	压缩后的系统文件，下划线是压缩后缀	添加组件、修复文件失败
驱动描述	.inf 与同名 .cat	硬件安装脚本与签名目录	驱动装得上但过不了签名校验
应答脚本	winnt.sif、unattend.txt	无人值守参数	不影响修复，只影响装机

值得单独说的是那些带下划线的文件。它们是 CAB 压缩的单文件形式，expand解出来才是正常的 dll/exe。有人看到ntoskrnl.ex_以为文件坏了，其实是没解压。另外，很多完整包会在根目录下再分一层语言子目录（如 en-us），驱动 INF 里引用文件的相对路径是按这个结构写死的，随手把子目录拍平，路径就断了。

2.2 setupapi 找不到文件时，它到底在找什么

Windows 装驱动的执行者是 setupapi 这套组件。它读 INF 里的 CopyFiles、SourceDisksFiles 段，算出“这个驱动还需要哪几个文件”，然后按一个固定顺序去找：驱动存储（DriverStore）里已有的副本 → INF 自身所在目录 → 注册表里登记的安装源路径 → 最后才是弹窗要用户插介质。

这个顺序解释了两件事。第一，为什么有时候你把路径指对了，弹窗还是不消失——因为它在更前面的环节就已经匹配到了旧文件，根本没走到你指的路径。第二，为什么从网络共享安装经常“前面都好好的，最后一步失败”——安装后半段的进程运行在 SYSTEM 上下文，没有当前登录用户的网络凭据，UNC 路径对它来说是陌生地址。

还要分清 SFC 和 DISM。sfc /scannow比对的是组件存储（WinSxS），它不直接读 i386；i386 主要喂给 setupapi 装驱动、给 DISM 做组件修复、给老式安装器做文件源。把这两件事混为一谈，就会在“修系统文件”的场景里白折腾半天。

2.3 到手先跑三行校验：文件齐、版本对、CAB 能解

我在把任何一份包往共享里放之前，都会先跑一遍下面这段。它只做三件事：关键清单在不在、规模对不对得上、压缩包能不能解。

# 1) 结构自检：没有这几份清单，安装器根本不认这个源 $src = 'D:\i386' $must = 'layout.inf','drvindex.inf','txtsetup.sif','driver.cab' $must | ForEach-Object { $p = Join-Path $src $_ [pscustomobject]@{ File = $_ Exists = Test-Path $p SizeKB = if (Test-Path $p) { [math]::Round((Get-Item $p).Length / 1KB) } else { 0 } } } | Format-Table -AutoSize # 2) 规模自检：文件数与总容量，用来和来源清单对账 $all = Get-ChildItem $src -Recurse -File '文件数: {0} 总容量: {1:N1} MB' -f $all.Count, (($all | Measure-Object Length -Sum).Sum / 1MB) # 3) 抽样解压：挑最大的那个 CAB 试解，拷贝中断能立刻暴露 Expand.exe "$src\driver.cab" -F:* 'D:\tmp\cabtest' | Out-Null '解压样本文件数: {0}' -f (Get-ChildItem 'D:\tmp\cabtest' -File).Count

参数说明：-F:*表示解出包内全部文件，只写-F:某文件名就只解一个，做抽样时后者更快。Format-Table -AutoSize只是为了肉眼好读，脚本化时可以换成ConvertTo-Json。

版本对齐这一步更关键。源包的文件版本如果低于目标系统当前已打的补丁级别，安装能走完，但 SFC 会判定“文件版本回退”而拒绝使用。

# 解出内核文件看版本，再和目标机现状比一比 Expand.exe 'D:\i386\ntoskrnl.ex_' -F:* 'D:\tmp\ver' | Out-Null '源包版本 : ' + (Get-Item 'D:\tmp\ver\ntoskrnl.exe').VersionInfo.FileVersion '目标机版本: ' + (Get-Item 'C:\Windows\System32\ntoskrnl.exe').VersionInfo.FileVersion

两行版本号一比，高低立现。源包版本明显偏低时，别急着往生产机上指，先想清楚是要装驱动还是要修系统——装驱动可以忍受旧一点，修系统不行。

3. 四条落地路径：从单机驱动到离线修复，i386 该怎么指

同一个包，在不同场景下的“用法”差别很大。有人只需要装一块网卡，有人要给一批机器做离线修复，指错层级就会出现“路径明明给了却没用”的假象。下面四条路径按侵入性从低到高排列。

3.1 路径一：pnputil 直接把 INF 灌进驱动存储

单机装驱动，最干净的做法是绕过图形界面的“浏览到文件夹”，直接把 INF 导入驱动存储。这样做的好处是导入后系统会自己匹配当前所有在位的设备，不需要你一台一台去点“更新驱动程序”。

:: 导入单个 INF 并立即尝试匹配当前设备 pnputil /add-driver "D:\i386\oem12.inf" /install :: 一个目录下散着多个 INF 时，带子目录批量导入 pnputil /add-driver "D:\i386\*.inf" /subdirs /install :: 导入完确认一下，oemXX.inf 就是刚进去的那份 pnputil /enum-drivers

参数说明：/install只在设备已经存在时才有匹配动作，设备没插上时它会静默跳过，所以顺序上应该先装硬件再执行。/subdirs会递归扫描，扫描面太大时耗时会明显上升，目录里混着大量无关 INF 时建议先筛一遍。/enum-drivers输出的oemNN.inf是系统重命名后的副本，原始文件名在Original Name那一列，用来核对版本最方便。

图形界面那条路也留着：设备管理器 → 更新驱动程序 → 浏览我的电脑 → 让我从可用驱动列表中选取 → 从磁盘安装 → 指到具体 INF。它比命令行多一步“手动挑型号”，在自动匹配挑错驱动时反而更好用。

3.2 路径二：SourcePath 注册表项，让弹窗不再出现

有些安装流程不是你在主导，而是系统自己在跑——加 Windows 组件、装可选功能、某些老安装包的二次调用。这类场景没法手动指定 INF，只能把源路径写进注册表，让 setupapi 自己去读。

:: 安装源主路径，指向本地目录或 UNC reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /v SourcePath /t REG_SZ /d "D:\i386" /f :: 补丁源路径，某些组件安装会单独读这一项 reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /v ServicePackSourcePath /t REG_SZ /d "D:\i386" /f :: 回读确认，注意别把末尾反斜杠写成双斜杠 reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /v SourcePath

这里最容易翻车的是路径写法。D:\i386和D:\i386\在多数场景下等价，但指向共享时\\fileserver\i386src后面千万不能再补反斜杠，补了之后拼接出来的路径会变成双反斜杠开头，部分老安装器解析不了。改完注册表不需要重启，但已经在跑的那个安装进程读的是启动时的缓存，得让它重来一遍。

3.3 路径三：SFC 与 DISM 的离线源，别把两件事混了

系统盘起不来、只能挂到维护环境里修的时候，用到的是离线参数。SFC 的离线模式需要同时告诉它引导分区和系统目录在哪：

:: 维护环境下执行，C:\ 是挂载后的系统盘 sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

注意sfc /scannow的比对基准仍然是离线系统自己的 WinSxS，它不会去 i386 里捞文件。真正需要外部源的是 DISM 的组件修复，而它要的不是原始 i386 目录，是一个放平了的组件目录：

:: 先把 i386 里的组件 CAB 解到一个独立目录 expand.exe "D:\i386\driver.cab" -F:* "D:\sxs" :: 再让 DISM 指向这个目录，/LimitAccess 阻止它去网上找 dism /Online /Cleanup-Image /RestoreHealth /Source:"D:\sxs" /LimitAccess

参数说明：/LimitAccess在有内网源时必加，否则 DISM 会先尝试联网，联不通再回落，整段等待时间会拉得很长。/Source可以给多个，用分号隔开，DISM 按顺序找第一个命中的。离线系统上把/Online换成/Image:C:\（挂载点）即可。

3.4 路径四：装机阶段的 /s 与应答文件

装系统阶段反复读光盘是另一类折磨。老式安装器支持用/s直接把源目录指到硬盘，配合应答文件就能一路无人值守：

:: 先把整个 i386 拷到本地非系统盘，再让安装器从本地读 xcopy D:\i386 C:\i386src /E /I /H :: /s 指定源，/unattend 指定应答文件 winnt32.exe /s:C:\i386src /unattend:C:\i386src\winnt.sif

参数说明：/E复制含空目录，/I目标不存在时自动建目录，/H连隐藏文件一起拷——i386 里确实有隐藏属性的文件，漏了/H会出现“拷完还是提示缺文件”的诡异现象。源目录别放在待安装的那个分区上，格式化的时候会一并没掉。

4. 以 Windows Server 为例：把 i386 挂成局域网组件源

一台机器上放本地路径只能救一台。真正的批量场景是把包放在文件服务器上，让一批 Windows Server 都指过去。这一步的技术难点不在共享本身，在权限上下文。

4.1 共享与权限：为什么 SYSTEM 读不到你的 UNC

现象很典型：你以管理员身份登录，dir \\fileserver\i386src一切正常；但装驱动装到后半段，报“拒绝访问”。原因是安装流程的后半段切换到了 SYSTEM 上下文，它用的是计算机账户的身份去访问网络，而不是你的登录凭据。

:: 建只读共享，只给读权限，写权限一律不给 net share i386src=D:\sources\i386 /GRANT:"Authenticated Users",READ :: 从另一台机器验证共享可读，这一步别省 dir \\fileserver\i386src\layout.inf

解决访问被拒有两条路。一条是把共享权限授给计算机账户（域环境里是域计算机组，工作组环境里是本机机器账户），让 SYSTEM 能直接读。另一条更省事：把包同步一份到本地磁盘，注册表指向本地路径，彻底绕开网络身份问题。我在生产环境里通常两条都做——共享给批量用，本地副本给关键机器兜底。

提示：共享名和目录名不要带空格和中文。老安装器对 UNC 里出现空格的解析经常出错，报错信息还指向“文件不存在”，排查方向会被带偏。

4.2 目录命名对齐：i386、amd64、wow64、sxs 各管一段

一份“完整包”往往不止 i386 一个目录。把它们的职责分清，才知道客户端该指哪一层。

目录	对应架构	什么场景会被回查
i386	32 位 x86	32 位系统装驱动、加组件
amd64	64 位 x64	64 位系统装原生驱动
wow64	32 位子系统	64 位系统里跑 32 位安装程序
sxs	并行组件	DISM 修组件、加可选功能

64 位系统上装一个 32 位驱动的安装包，回查的是 wow64 而不是 amd64，这个错位是“指了路径还是弹窗”的头号原因。判断方法很简单：看弹窗里缺失的文件名，去几个目录里分别搜一遍，命中的那个目录才是该指的目标。

4.3 客户端指向与三步验证

服务端就绪后，客户端只需要写一项注册表，然后做三步验证。

:: 指向共享 reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /v SourcePath /t REG_SZ /d "\\fileserver\i386src" /f :: 验证一：路径可解析 dir "\\fileserver\i386src\driver.cab" :: 验证二：驱动存储里已有几份，方便对比前后变化 pnputil /enum-drivers | find /c "oem" :: 验证三：触发一次设备扫描，看是否还弹窗 pnputil /scan-devices

三步里第二步最容易被跳过，但它其实是最有价值的一步。记录改动前的oemNN.inf数量，装完之后再数一次，数量增加说明新驱动确实进去了；数量没变而设备管理器里显示已更新，那多半是匹配到了 DriverStore 里的旧副本，跟 i386 一点关系都没有。想确认客户端真的在读共享，打开系统自带的资源监视器，看“网络”标签页里有没有指向那台文件服务器的活动连接，比翻日志快得多。

5. 避坑：i386 完整包最容易翻车的五个地方

这一节按“现象 → 原因 → 解决”记五条，都是我在真实现场踩过的。看着像小问题，卡住的时候能耗掉一整个下午。

5.1 现象一：弹窗没了，驱动却还是旧版本

现象：指完路径，安装顺利完成，设备管理器里驱动日期却是两年前的。

原因：setupapi 在第一顺位就命中了 DriverStore 里的旧副本，压根没走到你给的源。i386 只提供了“候选文件”，不负责覆盖已安装的驱动包。

解决：先pnputil /enum-drivers找到对应的oemNN.inf，用pnputil /delete-driver oemNN.inf /uninstall移除旧包，再重新导入新 INF。移除前确认没有设备在用它，否则会当场掉设备。

5.2 现象二：指了路径仍提示找不到指定文件

现象：注册表写对了，弹窗照旧，提示的文件名在目录里明明搜得到。

原因：多半是架构或语言目录错位。文件在 wow64 或 en-us 子目录下，而安装器按 i386 根目录去找；也可能是 INF 里写死了相对路径，被人为拍平过。

解决：拿弹窗里的文件名，在几个架构目录下分别dir /s /b搜一遍，看它落在哪；再确认语言子目录结构有没有被改动。真被拍平过，就从原始包里重新拷一份，别手工补。

5.3 现象三：从共享装到一半报拒绝访问

现象：驱动装到复制文件阶段中断，提示无法访问网络位置。

原因：安装后半段切到 SYSTEM 上下文，没有当前用户的网络凭据。

解决：把共享读权限授给计算机账户，或者把 i386 同步一份到本地磁盘改指本地路径。临时应急可以先把驱动 INF 拷贝到本地再装，绕开 UNC。

5.4 现象四：expand 解包报数据错误

现象：expand解到一半报“数据错误”，或者解出来的文件明显偏小。

原因：包是从光盘拷过来的，文件名大小写被改、长文件名被截断，或者拷贝过程因为空间不足中断过。CAB 对文件头极其敏感，错一个字节就整包解不开。

解决：抽样解压不要只解一个，挑体积最大的三个分别试；对不上的从原始介质重新拷贝。拷完比对总容量和文件数，两个指标同时对上才算过关。

5.5 现象五：SFC 说文件损坏但修不了

现象：sfc /scannow跑完提示“找到损坏文件但无法修复其中某些文件”。

原因：i386 里的文件版本低于系统当前已打补丁的级别，SFC 不接受版本回退；或者组件存储本身已经损坏，比对基准都没了。

解决：换一份与当前补丁级别一致的源；实在找不到，先卸载最近的相关更新再跑一次，最后才考虑就地升级。别用“从别处拷个同名 dll 覆盖”这种办法，签名对不上会让问题更麻烦。

6. 校验与瘦身：拿到包后我先做的三件事

第一件事是给整包做一份 SHA256 清单。i386 这类包在机器之间、U 盘和共享之间来回搬的次数太多，靠“能解压”判断完整性并不可靠——CAB 里坏一个被引用的文件，整包解压照样成功。

# 生成基线清单，路径转成相对路径，方便换机后比对 $src = 'D:\i386' Get-ChildItem $src -Recurse -File | Get-FileHash -Algorithm SHA256 | Select-Object Hash, @{n='Rel';e={$_.Path.Substring($src.Length)}} | Export-Csv 'D:\i386.sha256.csv' -NoTypeInformation -Encoding UTF8 # 换了一台机器或换了一块盘之后，拿清单反查 Import-Csv 'D:\i386.sha256.csv' | ForEach-Object { $p = Join-Path $src $_.Rel if (-not (Test-Path $p)) { "缺失: $($_.Rel)" } elseif ((Get-FileHash $p -Algorithm SHA256).Hash -ne $_.Hash) { "损坏: $($_.Rel)" } }

Substring($src.Length)是为了把绝对路径裁成相对路径，这样清单在 D 盘、E 盘、共享路径下都能复用。清单本身只有几百 KB，和包放在一起，谁拷走都能自证。

第二件事是按语言和架构裁剪。完整包往往带了好几套语言目录，实际只用到其中一套，其余的全是搬运成本。

内容	处理方式	说明
非目标语言目录	可裁	只留实际系统语言那一套，别留两套以上
无关架构目录	可裁	纯 32 位环境留 i386 就够，amd64 可移走
驱动合集 CAB	保留	裁掉会让装驱动重新弹窗
安装清单 INF	保留	一个都不能动
应答脚本	视情况	不用无人值守可以裁，但留着不占地方