Восстановление поврежденного WMI (информация не считывается удалённо)

Иногда случается так, что после установки одного из обновлений Windows WMI перестает работать на сервере или рабочей станции. Если данные не собираются на каком-то компьютере даже локально (при наличии прав администратора), скорее всего WMI поврежден.

Можно попробовать восстановить WMI по следующей инструкции.

1. Исправление ошибок регистрации библиотек WMI:

1. Перейдите в системный каталог Windows. Перейдите в подкаталог wbem.
В этом каталоге находятся файлы WMI.
cd %system32%
cd \wbem

2. Перерегистрируйте библиотеки
for %i in (*.dll) do RegSvr32 -s %i

3. Перерегистрируйте исполняемые файлы
regsvr32 -s scrcons.exe
regsvr32 -s unsecapp.exe
regsvr32 -s wbemtest.exe
regsvr32 -s winmgmt.exe
regsvr32 -s wmiadap.exe
regsvr32 -s wmiapsrv.exe
regsvr32 -s wmiprvse.exe

2. Исправление ошибок репозитория:

1. Остановите сервис WMI
net stop winmgmt
2. В папке
C:\Windows\System32\Wbem\
переименуйте Repository в Repository_bad
3.Запустите сервис WMI
net start winmgmt
4. Запустите команду
rundll32 wbemupgd, UpgradeRepository

Скрипт, позволяющий выполнить все описанное вверху (создайте .bat-файл, скопируйте туда следующие команды, и запустите его):
cd %system32%
cd \wbem
for %i in (*.dll) do RegSvr32 -s %i
regsvr32 -s scrcons.exe
regsvr32 -s unsecapp.exe
regsvr32 -s wbemtest.exe
regsvr32 -s winmgmt.exe
regsvr32 -s wmiadap.exe
regsvr32 -s wmiapsrv.exe
regsvr32 -s wmiprvse.exe

net stop winmgmt
cd %system32%
cd \wbem
ren Repository Repository_bad
net start winmgmt
rundll32 wbemupgd, UpgradeRepository

Программа «10-Страйк: Инвентаризация Компьютеров» — удаленный опрос и инвентаризация ПК предприятия по сети. Создание отчетов по «железу» и ПО, мониторинг изменений, обнаружение проблем, оповещение администратора. Легко установить и настроить. Возьмите свой парк компьютеров под контроль!

Скачайте бесплатную 30-дневную версию прямо сейчас и попробуйте.

Устранение неполадок в WMI

Любой бывалый Windows-админ не раз сталкивался с проблемами в работе службы WMI и ее компонентах. Наличие проблем в подсистеме WMI является критичным с точки зрения нормального функционирования системы, поэтому администратору приходится прибегать к тем или иным трюкам, позволяющим восстановить работоспособность WMI. В этой статье мы опишем достаточно простую методику диагностирования и устранения неполадок в службе WMI.

О наличии проблем с WMI может свидетельствовать широкий спектр ошибок:

• Ошибки обработки WMI запросов в системных журналах и логах приложений
• Ошибки GPO, завязанные на WMI ( некорректная работа wmi фильтров политик, и пр.)
• Ошибки в работе / невозможность установки агентов SCCM/SCOM
• Ошибки в работе скриптов (vbs или powershell), использующих пространство имен WMI

В первую очередь нужно проверить имеется ли в системе служба Windows Management Instrumentation (Winmgmt) и включена ли она.

Если служба присутствует и находится в состоянии Started, рекомендуется протестировать работоспособность WMI, обратившись к ней с помощью простого wmi-запроса. С помощью Powershell, например, это можно сделать так:

Если при выполнении простейшего WMI-запроса система возвращает ошибку (на скриншоте приведен пример корректного ответа службы WMI), вероятно имеет место некорректное функционирование сервиса WMI или ряда его подсистем, повреждение репозитория WMI или другие проблемы.

Утилита WMIDiag

Для «тонкой» диагностики службы WMI существует официальная утилита Microsoft — WMIDiag (Microsoft WMI Diagnosis). Утилита представляет собой vbs скрипт, который проверяет различные подсистемы WMI и записывает собранную информацию в лог файлы (по умолчанию логи находятся в каталоге %TEMP% — C:\USERS\%USERNAME%\APPDATA\LOCAL\TEMP\). Получившийся отчет состоит из файлов, имена которых начинаются с WMIDIAG-V2.1 и включает в себя следующие типы фалов :

• .log файлы содержат подробный отчет об активности и работе утилиты WMIDiag
• .txt файлы содержат итоговые отчеты о найденных ошибках, на которые стоит обратить внимание
• В .csv файлах содержится информация, нужная для долгосрочного анализа работы подсистемы WMI

Совет. В 64 битных версиях Windows wmidiag нужно запускать так:

в противном случае появится ошибка: WMIDiag must be run from native 64-bit environment. It is not supported in Wow64.

После окончания работы утилиты WMIDiag администратор должен изучить полученные файлы логов, проанализировать и попытаться исправить найденные ошибки.

В общем случае, WMIDiag может дать информацию по исправлению частных ошибок в WMI , но в большинстве случаев процесс это довольно трудоемкий и стоит потраченного времени только при решении инцидентов в критичных системах (как правило, на продуктивных серверах). Для массового сегмента рабочих станций пользователей гораздо проще «бить по площадям» и решать проблему работы WMI более радикально.

Перерегистрация библиотек WMI и перекомпиляция mof файлов

Следующий скрипт представляет собой «мягкий» вариант восстановления работоспособности службы WMI на отдельно взятом компьютере (выполняется перерегистрация dll библиотек и службы WMI, перекомпилируются mof файлы). Данная процедура является безопасной и ее выполнение не должно привести к каким-либо новым проблемам с системой.

Указанные команды можно выполнить путем простой вставки в окно командой строки, либо сохранить код в bat файле и запустить его с правами администратора. После окончания работы скрипта, систему нужно перезагрузить и вновь проверить работу WMI.

Пересоздание репозитория (хранилища) WMI

В том случае, если предыдущий способ не помог, придется перейти к более «жесткому» способу восстановления работоспособности службы WMI, заключающегося в пересоздании хранилища.

WMI репозиторий (хранилище) находится в каталоге %windir%\System32\Wbem\Repository и представляет собой базу данных, в которой содержится информация о метаданных и определениях WMI классов. В некоторых случаях репозитория WMI может содержать статическую информацию классов. При повреждении репозитория WMI, в работе службы Windows Management Instrumentation (Winmgmt) могут наблюдаться ошибки вплоть до полной невозможности ее запустить.

В том случае, если вы подозреваете, что репозиторий WMI поврежден, имейте в виду, что его пересоздание это последняя вещь, к которой нужно прибегнуть только в том случае, если никакие другие операции реанимировать WMI не помогают.

В Windows Vista и выше проверить целостность репозитория WMI можно с помощью команды:

Если команда возвращает, что база данных WMI находится в неконсистентном состоянии (INCONSISTENT), стоит попробовать выполнить «мягкое» восстановление репозитория:

И перезапустить службу wmi:

Если описанная выше команда не помогла, выполняем сброс репозитория на начальное состояние (hard reset) так:

В том случае, если команды Winmgmt /salvagerepository и Winmgmt /resetrepository желаемого эффекта не дали, стоит попробовать выполнить «жесткое» пересоздание базы WMI вручную таким сценарием:

Данный скрипт полностью пересоздает хранилище WMI (старый репозитория сохраняется в каталоге Repos_bakup). После окончания работы скрипта компьютер нужно перезагрузить, после чего протестировать работу службы WMI простым запросом.

WMI Provider Host Windows 10 грузит процессор

WMI Provider Host – безопасный системный процесс, работа которого обычно не отнимает много ресурсов. Однако иногда в «Диспетчере задач» можно увидеть, что WMI захватывает память компьютера и тормозит работу системы.

WMI – аббревиатура, которая расшифровывается как Windows Management Instrumentation. Этот системный инструмент отвечает за связь приложений и сервисов с системой. По сути, он обеспечивает корректную работу всех периферийных устройств: принтера, картридера, флеш-накопителей и т.д. Отключение процесса нежелательно, поэтому при обнаружении высокой нагрузки необходимо искать и устранять причину сбоя.

Причины повышения нагрузки

Повышенная активность WMI Provider Host – это норма, но только на короткий срок. Процесс включается в работу и нагружает память, когда сервис или приложение запрашивают через него информацию у системы. Если в этот момент ещё и подключить колонки или мышку, то произойдёт скачок активности и нагрузка на память увеличится. Но всё это занимает секунды.

Постоянная нагрузка на систему со стороны WMI Provider Host – не норма. Причиной такого поведения процесса может быть:

• Вирусное заражение. Возможно, в «Диспетчере задач» отображается не настоящий процесс, а его зловредный клон.
• Некорректное обновление системы.
• Неправильно установленное приложение.

Исправить ошибку в автоматическом режиме не получится. Искать и устранять причину придётся руками, проверяя состояние служб и приложений.

Проверка на вирусы

Я обычно начинаю диагностику с проверки системы на вирусы. В случае с WMI Provider Host это особенно актуально, потому что злоумышленники любят маскировать зловреды под различные системные процессы. Обнаружить подмену можно и без антивирусного ПО.

1. Нажимаем правой кнопкой на панель задач или «Пуск».
2. Выбираем в контекстном меню «Диспетчер задач».

3. Находим в списке процессов WMI Provider Host (Wmiprvse.exe).

4. Щёлкаем по нему правой кнопкой и выбираем «Открыть расположение файла».

Исполняемый файл настоящего процесса располагается в папке System32 – wbem в директории Windows. Для уверенности кликаем по нему правой кнопкой, открываем свойства и на вкладке «Подробно» смотрим строку «Авторские права» – в ней должна быть указана Microsoft Corporation.

Если нас перебрасывает в другой каталог или в авторских правах указана не Microsoft, значит, систему грузит фейковый процесс, за которым скрывается зловредное ПО. Это повод для того, чтобы расчехлить антивирусные утилиты и запустить пару проверок всех разделов жёсткого диска. Я использую для сканирования связку бесплатных утилит AdwCleaner и Dr.Web CureIt!.

Работа с обеими программами строится по одному принципу: запускаем сканирование, ждём результат и избавляемся об обнаруженных зловредных файлов. После завершения проверки снова возвращаемся в «Диспетчер задач» и проверяем состояние процесса. Перестал грузить – радуемся и думаем над тем, как вирус попал в систему. Не перестал грузить – ищем причину дальше.

Перезапуск службы

Прежде чем погружаться в поиски приложений и сторонних процессов, которые могут оказывать влияние на WMI Provider Host, попробуем перезапустить саму службу. Если сбой был единичным, то это поможет – мы просто заставим системный компонент забыть ошибочное поведение и снова заработать нормально.

1. Нажимаем на клавиатуре сочетание клавиш Win+R для вызова окна «Выполнить».
2. Набираем в строке services.msc и нажимаем «Ок».

3. В списке служб находим «Инструментарий управления Windows».

4. Щёлкаем правой кнопкой по службе и выбираем опцию «Перезапустить».

После перезапуска необходимо вернуться в «Диспетчер задач» и посмотреть, какую нагрузку WMI Provider Host оказывает на систему теперь.

Поиск проблемного приложения

Самая сложная часть – найти компонент, который напрягает процесс своими обращениями.

1. По очереди отключаем внешние устройства (мышь, клавиатуру, веб-камеру, принтер, флеш-накопители и т.д) и смотрим на уровень нагрузки. Если после отсоединения очередного девайса процесс приходит в норму, значит, виновник обнаружен.
2. Удаляем сомнительные приложения, которые были недавно установлены. Особое внимание уделяем наборам виджетов, которые собирают системную информацию для отображения температуры компонентов, состояния памяти и т.д.

Если вы обнаружили, что виновато внешнее устройство, то нужно обновить его драйверы или отказаться от его использования. Для обновления драйвера:

1. Открываем «Диспетчер устройств».
2. Находим устройство, при отключении которого нагрузка снизилась.
3. Кликаем по нему правой кнопкой и выбираем опцию «Обновить драйвер».
4. Запускаем автоматический поиск программного обеспечения.

Если автоматический поиск не даёт результата, то я иду на сайт производителя оборудования и проверяю наличие драйверов. Есть софт – скачиваем и устанавливаем вручную. Нет софта – кажется, нам придётся отказаться от этого оборудования, которое неадекватно нагружает службу WMI Provider Host.

Влиять на состояние процесса может также служба или программа. Есть два способа обнаружить виновника. Первый – ручной поиск: отключаем по очереди несистемные компоненты и каждый раз перезагружаем компьютер.

1. Нажимаем Win+R для запуска окна «Выполнить».
2. Вводим команду msconfig.
3. Переходим на вкладку «Службы».
4. Отмечаем «Не отображать службы Microsoft».

5. Нажимаем «Отключить все», чтобы деактивировать сторонние службы.

6. Переходим на вкладку «Автозагрузка» и кликаем по ссылке «Открыть Диспетчер задач».

7. Отключаем все компоненты автозагрузки и перезагружаем компьютер.

Если после перезапуска системы чрезмерная нагрузка на память пропала, то искать её причину следует в службах и программах, которые были отключены. Для определения приложения, вызывающего ошибку, необходимо вернуться на вкладку «Службы», по очереди включать все сторонние компоненты, перезагружать компьютер и каждый раз проверять состояние процесса WMI Provider Host. При обнаружении источника необходимо отключить службу или деинсталлировать приложение.

Второй способ поиска приложений или служб, которые работают с ошибками – использование инструмента «Просмотр событий Windows».

1. Нажимаем Win+R для запуска окна «Выполнить».
2. Вводим eventvwr.msc для перехода в «Просмотр событий».
3. Раскрываем меню «Вид» и отмечаем пункт «Отобразить аналитический и отладочный журнал».
4. Открываем блоки «Журналы приложений и служб» – Microsoft – Windows – WMIActivity – Operational.
5. В средней части окна мы видим список событий. В нём нужно найти строки с уровнем «Ошибка». Если их несколько, то выбираем несколько последних по времени.
6. Нажимаем левой кнопкой на каждое событие с уровнем «Ошибка» и на вкладке «Общие» находим значение ClientProcessId. Нам нужен его номер – например, 948. У разных ошибок могут быть разные отличающиеся номера – записываем их все.

Если журнал не вёлся, необходимо его включить. Для этого в разделе WMIActivity выбираем Trace и в блоке «Действия» переходим в свойства. На вкладке «Общие» отмечаем пункт «Включить ведение журнала» и нажимаем «Применить». После обновления логов на главной странице появятся сведения об активных процессах и их уровне.

После определения номера ClientProcessId запускаем «Диспетчер задач» и переходим на вкладку «Подробности». В столбце «ИД процесса» ищем числовые сочетания, которые получили в журнале событий.

После обнаружения соответствующего процесса необходимо решить, что с ним делать.

• Если это системный процесс, то перед отключением обязательно ищем, за работу каких компонентов Windows он отвечает, и можно ли его деактивировать. Если нельзя, то как можно решить проблему с его ошибочной работой.
• Если это процесс приложения, то деинсталлируем его и устанавливаем заново.
• Если процесс имеет неизвестное происхождение, запускаем антивирусную проверку и удаляем все обнаруженные зловредные файлы.

Процесс не обязательно сразу отключать – для начала пробуем его перезапустить, то есть снять задачу и затем заново открыть исполняемый файл.

Откат обновлений

Ошибки при установке обновлений Windows 10 тоже могут быть причиной того, что WMI Provider Host начнёт сходить с ума и перегружать систему запросами. Для решения проблемы придётся откатывать апдейты до тех пор, пока не будет нарушен некорректный элемент.

1. Открываем «Параметры» Windows 10 сочетанием клавиш Win+I или через меню «Пуск».
2. Переходим в раздел «Обновление и безопасность».
3. Нажимаем на ссылку «Просмотр журнала обновлений» и ждём, пока он загрузится.

4. Жмём на ссылку «Удалить обновления».

5. Находим список апдейтов Microsoft Windows.

6. Сортируем их по времени инсталляции, нажимая на столбец «Установлено».

7. Щёлкаем правой кнопкой по самому свежему апдейту и выбираем «Удалить».

8. Подтверждаем намерение избавиться от обновления и ждём завершения процедуры.

После успешного удаления апдейта необходимо проверить, снизилась ли нагрузка со стороны WMI Provider Host. Если ничего не меняется, то удаляем следующее обновление и так далее, пока не найдём источник проблемы. Переживать об апдейтах не стоит – вскоре Windows снова обнаружит их и установит заново, уже без ошибок. Но это работает только в том случае, если у вас включено автоматическое обновление системы.

Я отказался от автоматического обновления, поэтому после удаления апдейтов ставлю их заново в ручном режиме. Это несложно:

1. Открываем «Параметры».
2. Переходим в раздел «Обновление и безопасность».
3. Нажимаем «Проверить наличие обновлений».
4. Загружаем и устанавливаем всё, что Windows удалось обнаружить.

Часто в обновлениях приходит исправление ошибок – в том числе и связанных с повышенной нагрузкой отдельных процессов на систему. Поэтому не стоит их игнорировать и работать на старой версии системы. Даже если после инсталляции обновления появились новые ошибки, это устраняется переустановкой апдейта или выпуском исправления со стороны разработчиков.