WMI 存储库损坏导致管理工具报错？从校验到重建的修复顺序
运行 wmic、PowerShell 的 Get-WmiObject，或打开某些管理工具时提示『Win32: 无效的类』『WMI 存储库损坏』。WMI 是很多系统工具的底座，仓库损坏会导致连锁故障，按下面顺序修复，操作由轻到重，避免误删自定义 WMI 类。
一、验证 WMI 是否真的损坏
- 管理员 CMD 运行 wmic os get caption，若报错说明 WMI 异常。
- 运行 winmgmt /verifyrepository，返回『一致』说明仓库正常，返回『不一致』则已损坏。
- 用 wbemtest 连接 root\cimv2，尝试枚举类，观察是否报错。
二、尝试修复而非重建
- 运行 winmgmt /salvagerepository 尝试 salvage 恢复。
- 若失败，执行 winmgmt /resetrepository 将仓库重置为初始干净状态（会丢失自定义 WMI 类）。
- 停止服务：net stop winmgmt，再启动 net start winmgmt。
三、重建 WMI 仓库（终极手段）
- 停止 winmgmt 服务，进入 %SystemRoot%\System32\wbem。
- 重命名 Repository 文件夹为 Repository.old。
- 重新启动 winmgmt，系统会重建空仓库；随后运行 mofcomp *.mof 与 mofcomp *.mfl 重新编译标准类。
- 重启后让系统自动发现设备并注册 WMI 提供程序。
四、修复权限与依赖
- 确认 Windows Management Instrumentation 服务登录身份为『本地系统』。
- 用 wmimgmt.msc 右键『属性—安全』，确认当前用户对各命名空间有『执行方法/远程启用』权限。
- 若提供程序缺失，重新安装对应软件以注册其 WMI 提供程序。
技术总结：WMI 报错先用 /verifyrepository 判定是否损坏，优先 salvage 修复，不行再 reset，最后重命名 Repository 重建并重新编译 MOF；操作顺序从轻到重避免误删自定义类。