在致命崩溃后恢复 Windows Management Instrumentation (WMI)

前几天我遇到了这种情况：我的学生正在测试系统功能管理，域中的两台机器（均运行 Windows 10）在使用 Windows Management Instrumentation 时开始返回错误。主要管理员假期还没有回来，我不得不记住我是IT部门的前任负责人:)

我马上回答第三个问题：如果没有正常工作的 WMI，在我看来，你只能留下一台家用游戏电脑，除了玩游戏和看视频，什么都不做（除了让孩子学习编程） . 在其他情况下，尤其是在公司机器上，尤其是在域中，WMI 应该像发条一样工作。这是我的看法，可能有人不同意。

现在谈谈发生的原因：可能有很多。展望未来，我会说在一台机器上发生这种情况是因为硬盘驱动器空间不足，然后由于 UPS 损坏而导致电源故障（唉，没有人是安全的；服务器，当然，受到保护，通常没有工作机器）。第二个更糟糕：非致命的硬盘驱动器故障，然后是 BSOD。一般来说，处理原因并不那么重要，主要是找出原因不是病毒或黑客攻击。但是，系统文件的故意删除或意外损坏也应仔细考虑。

WMI 性能的恢复应该分阶段进行，从备用方法到破坏性方法。您应该为在最坏的情况下必须重新安装系统这一事实做好准备。不用说，大多数命令必须以管理员身份运行。

阶段1。检查服务的运行情况。

我们检查该服务在系统中Windows Management Instrumentation (Winmgmt)是否可用，是否已启用。我们调用 Services（在 Windows 10 中，最简单的方法是通过Start / Administrative Tools / Services，但我更喜欢在任何版本的 Windows 中的命令行上键入，最旧的除外services.msc），查找Инструментарий управления Windows/Windows Management Instrumentation，检查它是否正在运行：

如果它没有运行，尝试启动它，将启动模式设置为“自动”。如果正在运行，请尝试重新启动（停止/启动）。之后，我们检查 WMI 的性能。最简单的方法是执行任何 WMI 查询powershell（我提醒您，Windows 10 中的 powershell 是通过Start / Windows PowerShell / Windows Power Shell 启动的，但在我看来，以管理员权限启动命令行更容易，并且已经输入了powershell），例如，像这样：（你可以做另一个，你最喜欢的:)）

Get-WmiObject -List -ComputerName localhost

如果你有一个飞出的物体的脚布，一切都井井有条。如果错误已经爬升，说明性能没有恢复，我们进行第二阶段。

在此期间，我将谈谈官方的 Microsoft WMI 诊断实用程序。不知为何，大家争相推荐它作为康复的好帮手。唉，我花了很多时间分析这个实用程序的结果：脚本创建了一堆日志文件，如果你不着急，你可以通过这些文件，你有很多时间和一磅普洱/ 咖啡机。没有它，我可以更快地找出失败的原因。它可以直接帮助 WMI 早期恢复的可能性很小。

第 2 阶段。无损恢复

值得首先尝试重新注册库并重新编译对象属性扩展文件 ( Managed Object Format, MOF) 和这些文件的语言组件 ( MFL)。如果您尝试 WMI 查询并出现“WMI.MOF 文件中的错误”或任何其他 MOF 文件之类的错误，几乎可以保证正常工作。为此，请执行以下操作：

1. 停止 WMI 服务，一定要禁用它的自动启动
2. 重新注册 Windows\system32\wbem 文件夹中的所有库
3. 重新注册 WMI 服务和 WMI 提供程序主机
4. 我们启动 WMI 服务并让它自动启动
5. 重新编译 MOF 和 MFL 文件

您可以将所有这些收集到一个 BAT 文件中并运行：

# пункт 1
sc config winmgmt start= disabled
net stop winmgmt
# пункт 2
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
#пункт 3
wmiprvse /regserver
winmgmt /regserver
#пункт 4
sc config winmgmt start= auto
net start winmgmt
#пункт 5
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

我注意到通过这种方式我在第一台机器上恢复了 WMI 操作。不幸的是，第二个没有奏效。如果你不能，是时候进入第 3 步了

第 3 阶段。破坏性恢复

事实上，在第三步中，我们重新创建了 WMI 存储库，它位于 Windows\System32\Wbem\Repository 文件夹中，是一个存储标准 WMI 类的数据和定义以及附加 WMI 类的静态信息的数据库，如果它们是在您的汽车上创建的。

操作前先检查硬盘和文件系统的状况！！！

检查完整性（不适用于 Windows XP 及以下版本）：

winmgmt /verifyrepository

如果答案不是“WMI 数据库一致”，您可以使用以下命令执行“软恢复”：

winmgmt /salvagerepository

其次是服务重启：

net stop Winmgmt
net start Winmgmt

如果软恢复失败，我们会尝试将存储库恢复到其初始状态（结果：在您的系统上注册的所有其他 WMI 类很可能必须重新注册）：

winmgmt /resetrepository

然后重新启动系统。我注意到第二台机器在这个阶段之后开始工作。后果不是很郁闷，但很严重：我不得不重新安装Visual Studio和Delphi Starter，MS Office无法工作，不得不手动卸载，删除文件夹、文件和注册表项，然后重新安装。此外，我们自己的所有 WMI 类都消失了。

但是，如果这没有帮助，您将不得不删除并再次创建存储库。这可以通过以下 BAT 文件完成：

# Остановим службу WMI, обязательно запретив её автостарт
sc config winmgmt start= disabled
net stop winmgmt
# проводим реинициализацию WMI
cd %windir%\system32\wbem
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf
# создаем на всякий случай резервную копию нашего хранилища в папку WMI_VicoNT_Backup
# у вас, разумеется, может быть другое имя папки
if exist WMI_VicoNT_Backup rd WMI_VicoNT_Backup /s /q
rename Repository Repos_bakup
# воссоздаем хранилище
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
# запускаем службу WMI, заново регистрируем WMI Provider Host
sc config winmgmt start= auto
net start winmgmt
wmiprvse /regserver

我们使计算机超载。如果即使在这些步骤之后 WMI 也不起作用，那么只有一种方法 - 重新安装系统。