使用 DISM(Deployment Imaging Service and Management Tool)进行清理是修复和优化 Windows 11 系统的一种常见方法。DISM 可以帮助修复系统映像、清理不必要的文件、修复损坏的系统文件等。以下是如何使用 DISM 进行清理的基本步骤:
PS C:\WINDOWS\system32> dism /?
部署映像服务和管理工具
版本: 10.0.26100.5074
DISM.exe [dism_options] {Imaging_command} [<Imaging_arguments>]
DISM.exe {/Image:<path_to_offline_image> | /Online} [dism_options] {servicing_command} [<servicing_arguments>]
描述:
DISM 枚举、安装、卸载、配置和更新 Windows 映像中的功能和程序包。可以使用的命令取决于提供的映像以及映像是处于脱机还是运行状态。
FFU 命令:
/Capture-Ffu - 将物理磁盘映像捕获到新的 FFU 文件中。
/Apply-Ffu - 应用 .ffu 映像。
/Split-Ffu - 将现有 .ffu 文件拆分成多个只读已拆分 FFU 文件。
/Optimize-Ffu - 优化 FFU 文件,使其其可应用于不同大小的存储
。
WIM 命令:
/Apply-CustomDataImage - 冻结自定义数据映像中包含的文件。
/Capture-CustomImage - 将自定义设置捕获到 WIMBoot 系统上的增量 WIM 文件中。捕获的目录包括所有子文件夹和数据。
/Get-WIMBootEntry - 显示指定磁盘卷的WIMBoot 配置项。
/Update-WIMBootEntry - 更新指定磁盘卷的 WIMBoot 配置项。
/List-Image - 显示指定映像中的文件和文件夹的列表。
/Delete-Image - 从具有多个卷映像的 WIM 文件删除指定的卷映像。
/Export-Image - 将指定映像的副本导出到其他文件。
/Append-Image - 将其他映像添加到 WIM 文件中。
/Capture-Image - 将驱动器的映像捕获到新的 WIM 文件中。捕获的目录包含所有子文件夹和数据。
/Get-MountedWimInfo - 显示有关安装的 WIM 映像的信息。
/Get-WimInfo - 显示有关 WIM 文件中的映像的信息。
/Commit-Wim - 保存对安装的 WIM 映像的更改。
/Unmount-Wim - 卸载安装的 WIM 映像。
/Mount-Wim - 从 WIM 文件安装映像。
/Remount-Wim - 恢复孤立的 WIM 安装目录。
/Cleanup-Wim - 删除与损坏的已安装 WIM映像关联的资源。
通用映像处理命令:
/Split-Image - 将现有 .wim 文件拆分为多个只读拆分 WIM (SWM) 文件。
/Apply-Image - 应用一个映像。
/Get-MountedImageInfo - 显示有关安装的 WIM 和 VHD 映像的信息。
/Get-ImageInfo - 显示有关 WIM、VHD 或 FFU 文件中映像的信息。
/Commit-Image - 保存对装载的 WIM 或 VHD 映像的更改。
/Unmount-Image - 卸载已装载的 WIM 或 VHD 映像。
/Mount-Image - 从 WIM 或 VHD 文件装载映像。
/Remount-Image - 恢复孤立的映像装载目录。
/Cleanup-Mountpoints - 删除与损坏的已安装映像关联的资源。
映像规格:
/Online - 以正在运行的操作系统为目标。
/Image - 指定脱机 Windows 映像的根目录的路径。
DISM 选项:
/English - 用英文显示命令行输出。
/Format - 指定报告输出格式。
/WinDir - 指定 Windows 目录的路径。
/SysDriveDir - 指定名为 BootMgr 的系统加载程序文件的路径。
/LogPath - 指定日志文件路径。
/LogLevel - 指定日志(1-4)中所示的输出级别。
/NoRestart - 取消自动重新启动和重新启动提示。
/Quiet - 取消除错误消息之外的所有输出。
/ScratchDir - 指定暂存目录的路径。
若要获得有关这些 DISM 选项及其参数的详细信息,请在紧挨着 /? 之前指定一个选项。
示例:
DISM.exe /Mount-Wim /?
DISM.exe /ScratchDir /?
DISM.exe /Image:C:\test\offline /?
DISM.exe /Online /?
使用 DISM(Deployment Imaging Service and Management Tool)进行清理是修复和优化 Windows 11 系统的一种常见方法。DISM 可以帮助修复系统映像、清理不必要的文件、修复损坏的系统文件等。以下是如何使用 DISM 进行清理的基本步骤:
1. 打开命令提示符(以管理员身份)
首先,你需要以管理员身份打开命令提示符:
- 按下 Win + X,然后选择 “Windows Terminal (管理员)” 或 “命令提示符 (管理员)”。
2. 使用 DISM 检查系统映像
输入以下命令来检查系统映像的健康状态:
bashCopy Code
DISM /Online /Cleanup-Image /CheckHealth
- /CheckHealth: 检查系统映像的健康状况,并查看是否存在损坏。
3. 修复系统映像(可选)
如果在上一步中发现了损坏,你可以使用以下命令修复它:
bashCopy Code
DISM /Online /Cleanup-Image /RestoreHealth
- /RestoreHealth: 自动修复 Windows 映像中的损坏文件,通常需要连接到互联网以下载修复文件。
4. 清理不必要的文件
DISM 还可以用于清理不再使用的系统文件,释放磁盘空间。使用以下命令:
bashCopy Code
DISM /Online /Cleanup-Image /StartComponentCleanup
- /StartComponentCleanup: 清理 Windows 系统中不再需要的组件,并删除旧的更新备份。
5. 清理 WinSxS 文件夹
如果你的目标是清理 WinSxS 文件夹中的累积文件,释放空间,可以运行:
bashCopy Code
DISM /Online /Cleanup-Image /AnalyzeComponentStore
- /AnalyzeComponentStore: 分析 WinSxS 文件夹,帮助你了解清理的空间。
然后,你可以通过运行以下命令清理它:
bashCopy Code
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase
- /ResetBase: 删除所有旧的更新版本,只保留最新的版本,进一步释放空间。
6. 完成后检查系统状态
清理完成后,建议再次运行以下命令,确保系统映像健康:
bashCopy Code
DISM /Online /Cleanup-Image /CheckHealth
注意事项:
- 在运行 DISM 命令时,建议保持网络连接,尤其是在修复系统映像时。
- 如果系统遇到无法修复的错误,可能需要考虑使用系统还原或重装操作系统。
DISM /AnalyzeComponentStore 完整底层解构
0. 顶层核心定位(一句话区分所有 DISM 命令)
/AnalyzeComponentStore 是 Windows 唯一的【WinSxS 组件仓库体检诊断命令】
区别对标(全网最精准分层):
-
/CheckHealth:仅读预设损坏标记位(极速、浅层) -
/ScanHealth:扫描组件哈希/ manifest 完整性(文件级损坏) -
/RestoreHealth:修复组件仓库损坏(补文件、修依赖) -
/AnalyzeComponentStore:统计、建模、体检、溯源臃肿冗余 不修复、不下载、不替换,只做仓库健康度量化分析
核心本质:它是 WinSxS 组件仓库的「CT 体检机」,专门解决:系统为什么臃肿、更新残留多少、可清理空间、组件堆叠层级、仓库健康评分。
一、底层原理(核心运行机制)
1. Windows CBS 组件存储模型底层逻辑
Win10/Win11 采用 CBS 基于组件的服务架构(Component Based Servicing):
所有系统更新、补丁、功能升级不覆盖旧组件,而是叠加新组件。
因此 WinSxS 天然存在:
-
旧版本组件残留
-
替换废弃组件备份
-
失败更新缓存
-
重叠版本依赖栈
-
失效驱动/功能组件沉淀
2. AnalyzeComponentStore 四大核心扫描维度
命令底层并行执行 4 类内核级扫描:
-
组件版本堆叠扫描 遍历 CBS 注册表依赖树,统计:同功能多版本共存数量、新旧组件重叠度
-
冗余残留体积统计 识别:已被新补丁替换、标记为退役、失效不可引用的老旧组件
-
有效/无效组件比例建模 区分:正在被系统引用的活跃组件& 完全废弃的僵尸组件
-
可安全清理容量计算 根据系统更新规则、依赖拓扑,计算不会破坏系统的可释放空间
3. 关键底层判定规则(微软核心私有模型)
-
新组件安装成功 → 旧组件标记为Superseded(被取代)
-
Analyze 精准区分:可删除的废弃
WIM 原始镜像源 ↓ WinSxS 组件仓库(Analyze 扫描核心层) ├─ 活跃组件(当前系统运行依赖) ├─ 叠加更新组件(新版本补丁) └─ 被取代冗余组件(臃肿根源) ↓ 硬链接映射 System32 / 驱动 / 系统二进制(SFC 作用层)
-
组件存储总大小 = 活跃组件 + 叠加组件 + 冗余残留 + 缓存
-
实际有效大小 = 仅当前运行必需组件
-
可清理空间 = 孤立僵尸组件 + 过期被取代组件(无回滚需求)
3. 健康度评估模型
通过「冗余占比」判定系统臃肿等级,直接决定后续是否执行
/StartComponentCleanup四、完整调用链(从命令输入到内核执行)
用户执行 DISM /Online /Cleanup-Image /AnalyzeComponentStore ↓ dism.exe 入口初始化 ↓ 加载 dismcore.dll、cbscore.dll、providers.dll ↓ 调用 CBS 组件服务 COM 接口 ↓ 唤醒 TrustedInstaller 模块(不启动完整进程,仅内核服务托管) ↓ 1. 读取 CBS 注册表组件状态库 2. 遍历 WinSxS 所有组件 manifest 清单 3. 比对组件版本依赖拓扑 4. 分类统计四种组件状态 5. 算法计算可清理容量、臃肿占比 ↓ 生成标准化体检报告 ↓ 输出:总大小、冗余大小、推荐清理建议
-
Superseded 被取代态:有新版替代,仅用于回滚
关键区别 RestoreHealth:
-
Pending 挂起态:更新未完成、等待重启
Analyze 无网络请求、无文件下载、无文件替换、无修复动作,纯本地静态分析。
-
Orphaned 孤立僵尸态:无依赖、无回滚价值、完全废弃
2. 仓库容量计算模型
五、依赖链(文件+服务+注册表+权限)
最终报告公式(底层算法):
1. 核心依赖文件
-
dism.exe主程序 -
dismcore.dllDISM 核心镜像解析 -
cbscore.dllCBS 组件状态解析核心(最关键) -
providers.dll组件枚举提供者 -
wimgapi.dll镜像结构解析
2. 服务依赖(必须正常运行)
-
TrustedInstaller(核心组件查询权限支撑)
-
CBS 系统组件服务(内核态常驻)
无需:BITS、Windows Update、CryptSvc(纯本地扫描)
3. 注册表依赖(核心数据源)
路径:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing存储:所有组件版本、状态、依赖关系、取代标记、安装时间
4. 权限依赖
-
必须管理员权限
-
需要读取 CBS 系统受保护注册表项
-
需要读取 WinSxS 高权限目录
六、配套链(完整工具生态配对)
1. 前置配套
-
系统无严重 CBS 注册表损坏
-
WinSxS 目录结构完整(未被精简阉割)
-
TrustedInstaller 服务不被禁用
2. 后置配套(Analyze 输出结果对应动作)
Analyze 只是诊断,配套清理命令:
-
常规冗余清理:
DISM /Online /Cleanup-Image /StartComponentCleanup -
深度过期更新清理(删除可回滚包):
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase
3. 完整诊断链路组合
DISM /CheckHealth # 查标记损坏 DISM /ScanHealth # 查文件组件损坏 DISM /AnalyzeComponentStore # 查臃肿冗余 DISM /RestoreHealth # 修复损坏 DISM /StartComponentCleanup # 清理冗余 SFC /scannow # 修复最终文件
七、故障链(Analyze 报错/扫描失败根因)
常见失效场景
-
CBS 注册表损坏:组件依赖树错乱,无法统计
-
系统精简阉割:删除 cbscore.dll、CBS 注册表项
-
TrustedInstaller 被组策略/注册表禁用
-
WinSxS 目录权限错乱,无法枚举组件
-
更新挂起:存在 pending 更新,组件状态锁定
-
磁盘 NTFS 元数据损坏,目录读取异常
八、解决方案链(分级处理体系)
一级:常规扫描异常
重启 Windows 更新组件、开启 TrustedInstaller,重试扫描
二级:组件状态异常/挂起
清理更新缓存、删除 SoftwareDistribution 缓存、重启重置更新状态
三级:CBS 组件轻微损坏
先执行
/RestoreHealth 修复仓库架构,再重新 Analyze四级:重度系统精简/注册表崩坏
离线 DISM 修复 + 重置组件存储,或介质修复安装
九、终极核心总结(区别全网浅度教程)
1. 能做什么
-
量化 WinSxS 真实臃肿程度
-
识别版本堆叠、僵尸组件、过期更新残留
-
精准计算安全可清理空间,杜绝误删系统核心文件
-
评估系统组件仓库健康度与冗余度
2. 不能做什么
-
不修复损坏、不下载文件、不修改组件
-
不清理任何数据,只做分析统计
-
无法修复 CBS 架构性损坏
3. 终极公式
-
CheckHealth = 查标记
-
ScanHealth = 查文件损坏
-
RestoreHealth = 修组件仓库
-
AnalyzeComponentStore = 体检臃肿冗余
-
StartComponentCleanup = 清理冗余
DISM /Online/Cleanup-Image /RestoreHealth 完整全栈解构
0. 一句话顶层定义
RestoreHealth 不是修复系统文件 它是 修复 Windows 系统映像存储(WinSxS 组件仓库)。
- SFC:修复当前系统文件
- DISM RestoreHealth:修复系统文件的原始备份仓库(WinSxS)
SFC 依赖 DISM 修好的仓库才能修文件 这是 99% 的人不懂的底层架构关系。
一、底层原理(核心模型)
1. Windows 系统修复双层模型
第一层:运行时系统文件(C:\Windows\System32 等)
损坏 → SFC 修复
第二层:系统组件仓库(WinSxS)
所有系统文件原版备份、版本备份、更新备份全部存在这里 WinSxS 损坏、缺失、版本错乱、组件残留 → SFC 无法修复 必须用 DISM RestoreHealth
RestoreHealth 核心原理
- DISM 扫描 WinSxS 组件清单、组件哈希、组件依赖树、组件版本匹配
- 发现:缺失 / 损坏 / 版本不匹配 / 残留更新组件
- 自动从 Windows Update / WSUS / 本地源 install.wim 下载对应版本原版组件
- 替换修复 WinSxS 仓库
- 重建组件清单、重置组件状态、修复依赖链
本质:重装系统组件仓库,不重装系统
2. 三种系统损坏层级(底层模型链)
- 表层文件损坏 → SFC 可修
- 仓库底层组件损坏 → SFC 修不了 → 需要 DISM RestoreHealth
- 仓库严重架构损坏(清单损坏) → RestoreHealth 失败,需要离线源修复
二、架构链(Windows 组件化架构)
1. Windows 映像架构模型
WIM 原始镜像(install.wim)
↓ 部署阶段释放
WinSxS 组件仓库(系统核心源)
↓ 硬链接映射
System32 / SysWOW64 / 驱动 / 系统二进制
- 所有系统文件全部硬链接指向 WinSxS
- 系统没有独立文件,全部是组件仓库的链接副本
2. WinSxS 内部架构
- 组件清单:
component store manifest - 组件哈希库
- 组件依赖树
- 更新版本叠加层
- 失效组件残留缓存
RestoreHealth 的本质:重建整套组件架构
三、完整调用链(精准底层执行链路)
DISM.exe /Online /Cleanup-Image /RestoreHealth
↓
DISM 调用核心 COM 组件:Deployment Image Servicing Provider
↓
调用系统内核服务:
TrustedInstaller (Windows Modules Installer)
↓
1. 扫描 WinSxS 组件 manifest 完整性
2. 校验组件哈希、依赖关系、版本链
3. 检测 corrupted / missing / orphaned components
↓
自动查询系统源优先级:
1. 本地 WIM 源(优先)
2. WSUS 服务器
3. Windows Update 在线源
↓
下载匹配版本的完整组件包
↓
替换损坏组件、重建组件清单、修复依赖拓扑
↓
清理无效残留更新、修复重叠版本冲突
↓
重置组件存储状态为健康
关键进程
- TrustedInstaller.exe(核心执行体,权限高于 SYSTEM)
- wuauserv / usosvc(更新源下载)
- dismhost.exe(隔离执行沙箱)
四、依赖链(文件 + 服务 + 注册表 + 权限)
1. 系统依赖文件
dism.exe主程序dismcore.dll核心镜像服务providers.dll组件解析wimgapi.dllWIM 镜像解析库cbscore.dll组件基础服务(CBS)
2. 服务依赖(必须全开)
- Windows Modules Installer (TrustedInstaller) 核心
- Windows Update (wuauserv)
- USO Service (现代更新服务)
- BITS 后台传输
- CryptSvc 加密校验服务
3. 注册表依赖
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
- 组件状态库
- 更新依赖树
- 损坏标记位
4. 权限依赖
- 必须 管理员
- 必须 TrustedInstaller 权限可用
- 禁止系统精简、禁止篡改 CBS 注册表
五、配套链(完整生态配套)
1. 前置配套
- 网络正常(或本地 install.wim 源完整)
- BITS 服务正常
- 系统更新组件未被阉割
- CBS 注册表结构完整
2. 后置配套
修复完成必须执行:
SFC /Scannow
DISM 修仓库、SFC 修文件
3. 同源配套指令(完整三件套)
DISM /Online /Cleanup-Image /CheckHealth # 仅检测
DISM /Online /Cleanup-Image /ScanHealth # 深度扫描
DISM /Online /Cleanup-Image /RestoreHealth # 修复
六、模型链(Windows 现代化修复模型)
1. CBS 组件服务模型(Component Based Servicing)
Win10/Win11 不再是单文件系统 而是 组件化订阅模型
每一个系统文件 = 归属一个系统组件 每个组件有:
- 版本号
- 依赖组件列表
- 哈希校验
- 更新叠加层
- 安装状态标记
2. 损坏模型(三种病态模型)
- 文件层损坏(SFC 可修复)
- 组件层损坏(Manifest / 哈希 / 依赖损坏 → DISM 修复)
- 架构层损坏(CBS 注册表崩、仓库崩 → 必须离线修复)
3. 修复模型
- SFC:文件级修复
- DISM:组件架构级修复
七、故障链(为什么 RestoreHealth 会失败)
常见失败根因(底层)
- WinSxS 组件清单损坏(最常见)
- 更新残留冲突、版本重叠
- 精简系统删除了 CBS 组件库
- BITS 传输异常
- 组策略屏蔽 Windows Update 源
- 本地源版本和系统版本不匹配
- TrustedInstaller 服务异常
- 磁盘坏块 / NTFS 元数据损坏
八、解决方案链(分级修复方案体系)
一级修复(常规)
DISM /Online /Cleanup-Image /RestoreHealth
SFC /scannow
二级修复(在线源失败)
挂载对应版本 ISO,指定本地源
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\Sources\Install.wim:6 /LimitAccess
三级修复(组件架构崩)
- 重置 Windows 更新组件
- 清理 SoftwareDistribution
- 重置 BITS
- 修复 CBS 注册表
四级修复(终极)
离线 DISM 修复 + 重置组件存储
九、终极总结(你要的结构化定义)
DISM RestoreHealth 能干什么
- 修复 WinSxS 组件仓库底层架构损坏
- 修复 组件依赖树、版本冲突、清单损坏
- 修复 SFC 无法解决的深层系统损坏
DISM RestoreHealth 不能干什么
- 不能直接修复 System32 文件(交给 SFC)
- 不能修复磁盘坏道、NTFS 损坏
- 不能修复被人为精简删除的系统组件
- 不能跨版本修复源文件
一句话终极架构公式
SFC = 文件层修复 DISM = 系统组件架构层修复 WinSxS = Windows 的系统内核本体

浙公网安备 33010602011771号