Winmgmt что это за служба windows 10
Обновлено: 07.07.2024
Технология WMI — это универсальное средство мониторинга и управления распределённой информационной средой в операционных систем семейства Windows. Она обеспечивает доступ к любым параметрам операционной системы, оборудованию, системным службам, драйверам и приложениям. Важной особенностью WMI является то, что хранящиеся в нём объекты (Objects) соответствуют динамическим ресурсам и не могут храниться постоянно, а создаются по запросу потребителя данных. Хранилище свойств объектов WMI называется репозиторием и расположено в системной папке операционной системы %SystemRoot%\System32\WBEM\Repository .
Средства инструментария управления Windows, в том числе и консольная утилита winmgmt.exe располагаются в системном каталоге %SystemRoot%\System32\WBEM\ . Путь каталога WMI всегда присутствует в переменной PATH ОС семейства Windows, что позволяет использовать утилиты управления WMI без указания полного пути исполняемого файла.
Формат командной строки winmgmt.exe:
winmgmt [/backup ] [/restore ] [/resyncperf] /standalonehost [ ]] [/sharedhost] [/verifyrepository [ ]] [/salvagerepository] [/resetrepository]
Параметры командной строки:
/backup - WMI получает команду сохранить архивную копию базы данных с указанным именем файла. Аргумент "имя_файла" должен содержать полный путь к местоположению файла. Для этого процесса необходима блокировка записи в базу данных, что позволяет приостанавливать операции записи в базу данных до окончания архивации.
/restore - Восстанавливает базу данных WMI из указанного архивного файла. Аргумент "имя_файла" должен содержать полный путь к местоположению архивного файла. Для восстановления WMI сохраняет существующую базу данных для обратной записи на случай сбоя операции. Затем база данных восстанавливается из архивного файла, указанного в аргументе "имя_файла". Если не удается получить монопольный доступ к базе данных, существующие клиенты отключаются от WMI. Аргумент "флаг" должен иметь значение 1 (принудительно - отключение пользователей и восстановление) или 0 (по умолчанию - восстановление, если пользователи не подключены), при этом он указывает режим восстановления.
/resyncperf - Регистрирует системные библиотеки производительности в WMI.
/standalonehost [ ] - Перемещает службу Winmgmt в автономный процесс Svchost, который имеет фиксированную конечную точку DCOM. По умолчанию установлена конечная точка ncacn_ip_tcp.0.24158 . Тем не менее, конечную точку можно изменить, запустив Dcomcnfg.exe. Аргумент "уровень" является уровнем проверки подлинности для процесса Svchost. Если уровень не указан, по умолчанию используется значение 4 (RPC_C_AUTHN_LEVEL_PKT) . Допустимые уровни проверки подлинности в порядке возрастания уровня безопасности:
/sharedhost - Перемещает службу Winmgmt в общий процесс Svchost, обслуживающий группу из нескольких служб. Служба ”Инструментарий управления Windows” использует для запуска модуль svchost.exe и может быть сконфигурирована как служба winmgmt , входящая в состав группы netsvcs (sharedhost), либо как отдельная служба winmgmt группы winmgmt (standalonehost). В обоих случаях при запуске службы будет загружаться одна и та же динамическая библиотека WMIsvc.dll, однако доступ к ней во втором случае более ограничен настройками по умолчанию для группы winmgmt. Стандартно, служба ”Инструментарий управления Windows” конфигурируется как sharedhost
/verifyrepository [ ] - Выполняет проверку согласованности базы данных WMI. При добавлении модуля /verifyrepository без аргумента проверяется обновляемая база данных, используемая WMI в настоящее время. Если указать аргумент "путь", можно будет проверить любую сохраненную копию базы данных. В таком случае аргумент "путь" должен содержать полный путь к сохраненной копии базы данных. Сохраненная база данных должна представлять собой папку с целой базой данных.
Примеры использования WinMgmt
winmgmt - при запуске без параметров командной строки программа отображает краткую справку по использованию.
winmgmt /backup C:\backup\wmibackup - сохранить резервную копию WMI в файле C:\backup\wmibackup.
winmgmt /restore C:\backup\wmibackup - восстановить базу данных WMI из сохраненной копии C:\backup\wmibackup . Восстановление будет выполнено, если нет активных подключений к базе данных.
winmgmt /restore C:\backup\wmibackup 1 - восстановить базу данных WMI из сохраненной копии C:\backup\wmibackup . Перед восстановлением будет выполнен сброс активных подключений к базе данных.
winmgmt /resyncperf - перерегистрировать счетчики производительности. Требуется если монитор производительности отображает неправильные результаты оценки производительности системы.
winmgmt /standalonehost - перенастроить службу ”Инструментарий управления Windows” на конфигурацию с использованием отдельного процесса Svchost. Командная строка для запуска службы в данном случае будет иметь вид:
%systemroot%\system32\svchost.exe -k winmgmt
winmgmt /sharedhost - перенастроить службу ”Инструментарий управления Windows” на конфигурацию с использованием общего для сетевых служб процесса Svchost. Командная строка для запуска службы в данном случае будет иметь вид:
%systemroot%\system32\svchost.exe -k netsvcs
winmgmt /verifyrepository - проверить целостность текущей базы данных WMI
winmgmt /verifyrepository c:\backup\Repository.001 - Проверить целостность базы данных WMI, размещенной в каталоге c:\backup\Repository.001
winmgmt /salvagerepository - проверить целостность текущей базы данных WMI и, при обнаружении ошибок – перестроить ее. Команда относится только к текущей базе WMI, используемой службой ”Инструментарий управления Windows” (короткое имя службы - Winmgmt)
Для более углубленной диагностики инструментария управления Windows можно воспользоваться дополнительным средством от Microsoft WMIdiag или стандартной командой wmic /trace:ON .
На компьютере под управлением Windows 10 перестала работать WMI .
Никакие скрипты, раньше нормально работавшие, теперь не функционируют. Диапазон возвращаемых ошибок достаточно велик: 0x80041XXX, 0x800420XX, 0x700310XX (“Инициализация класса WMI невозможна”, “Вызов WMI запрещен”, “WMI вернул некорректный ответ”, "Ошибка в файле WMI.MOF" и так далее).
Я столкнулся с этой ситуацией на днях: мои студенты тестировали управление системными функциями и две машины в домене (на обеих – Windows 10) стали возвращать ошибки при работе с Windows Management Instrumentation. Основной админ ещё не вышел из отпуска, пришлось вспоминать, что я бывший руководитель Отдела ИТ :)
Сразу отвечу на третий вопрос: без рабочего WMI, на мой взгляд, можно оставлять лишь домашний игровой компьютер, на котором, кроме игр и просмотра видео, больше ничего не делается (разве что дети учатся программировать). В остальных случаях, особенно на корпоративных машинах, тем более в домене, WMI должна работать как часы. Это моё мнение, кто-то может не согласиться.
Теперь о причинах произошедшего: их может быть очень много. Забегая вперед, скажу что на одной машине это произошло из-за того, что на жестком диске закончилось место, а затем был сбой по питанию из-за сломанного ИБП (увы, никто не застрахован; сервера, конечно, защищены от подобного, а обычная рабочая машинка не была). На второй хуже: нефатальный сбой жесткого диска с последующим BSOD. В целом, разобраться с причинами не так уж и важно, главное, выяснить, что причиной не является вирус или попытка взлома. Впрочем, намеренное удаление или случайная порча системных файлов тоже должны быть рассмотрены достаточно пристально.
Восстановление работоспособности WMI следует проводить поэтапно, от щадящих методов к деструктивным. Следует быть готовым к тому, что в самом худшем случае систему придётся переустановить. Не стоит лишний раз напоминать, что большинство команд должно выполняться от имени администратора.
1 этап. Проверка работы сервиса.
Проверяем имеется ли в системе служба Windows Management Instrumentation (Winmgmt) и включена ли она. Вызываем Службы (в Windows 10 проще всего через Пуск/Средства администрирования/Службы, но я предпочитаю в любой версии Windows, кроме самых старых, напечатать в командной строке services.msc ), ищем Инструментарий управления Windows/Windows Management Instrumentation , проверяем, запущена ли она:
Если она не запущена, пытаемся запустить, выставим режим запуска в «Автоматически». Если запущена, пытаемся перезапустить (Остановить/запустить). После этого проверяем работоспособность WMI. Проще всего сделать это, выполнив любой WMI-запрос в powershell (напоминаю, что powershell в Windows 10 запускается через Пуск/Windows PowerShell/Windows Power Shell, но проще, на мой взгляд, запустить командную строку с админовскими правами, а в ней уже набрать powershell ), например, такой: (вы можете выполнить другой, свой любимый :))
Если у вас вылетела портянка объектов, всё в порядке. Если же полезли ошибки, значит, работоспособность не восстановлена, переходим ко второму этапу.
Между делом скажу пару слов об официальной утилите Microsoft WMI Diagnosis. Все почему-то наперебой её рекомендуют, как хороший помощник при восстановлении. Увы, я убил достаточно много времени на анализ результатов действия этой утилиты: скрипт создал кучу лог-файлов, через которые продраться можно, если вы никуда не торопитесь, у вас есть куча времени и полкило пуэра/кофе-машина. В причинах сбоев я разобрался быстрее без неё. Вероятность того, что она может помочь непосредственно в скором восстановлении работы WMI – очень мала.
2 этап. Недеструктивное восстановление
Стоит попытаться вначале выполнить перерегистрацию библиотек и рекомпиляцию файлов расширения свойств объектов ( Managed Object Format, MOF ) и языковую составляющую этих файлов ( MFL ). Практически гарантированно сработает, если попытка WMI-запроса у вас вызывала ошибку вида “Ошибка в файле WMI.MOF” или любом другом MOF-файле. Для этого выполним следующие операции:
- Остановим службу WMI, обязательно запретив её автостарт
- Перерегистрируем все библиотеки в папке Windows\system32\wbem
- Перерегистрируем службы WMI и WMI Provider Host
- Запускаем службу WMI и разрешаем её автостарт
- Рекомпилируем MOF и MFL файлы
Можно собрать всё это в один BAT-файл и запустить:
Отмечу, что таким образом я восстановил работу WMI на первой машине. Со второй, увы не получилось. Если у вас не получается, пора переходить к 3му этапу
3 этап. Деструктивное восстановление
Фактически, на 3м этапе мы пересоздаем хранилище WMI, как таковое, которое находится в папке Windows\System32\Wbem\Repository и является базой данных, в которой хранятся данные и определения стандартных WMI-классов и статическая информация дополнительных WMI-классов, если они создавались на вашей машине.
Перед операциями проверьте состояние жёсткого диска и файловой системы.
Проверяем целостность (На Windows XP и ниже не работает):
В случае ответа отличного от “База данных WMI согласована”, можно выполнить "мягкое восстановление" командой:
с последующим перезапуском службы:
с последующим рестартом системы. Отмечу, что вторая машина заработала после этого этапа. Последствия были не сильно удручающими, но серьёзными: пришлось переинсталлировать Visual Studio и Delphi Starter, MS Office отказался работать и его пришлось деинсталлировать вручную, удаляя папки, файлы и записи из реестра, с последующей повторной установкой. Также слетели все наши собственные классы WMI.
Но, если и это не помогло, придётся удалять и создавать хранилище заново. Это можно сделать следующим BAT-файлом:
Перегружаем компьютер. Если и после этих действий WMI не заработала, путь один – переустановка системы.
Файлы WMI Service Control Utility, такие как WinMgmt.exe, используют расширение EXE. Файл считается файлом Win32 EXE (Исполняемое приложение) и впервые был создан компанией Microsoft для пакета ПО Microsoft® Windows® Operating System.
Файл WinMgmt.exe впервые был создан 11/08/2006 в ОС Windows Vista для Windows Vista. Последним обновлением версии [v10.0.15063.0 (WinBuild.160101.0800)] для Windows является 10, выпущенное 07/29/2015. Файл WinMgmt.exe включен в пакет ПО в Windows 10, Windows 8.1 и Windows 8.
В этой статье приведены подробные сведения о WinMgmt.exe, руководство по устранению неполадок с файлом EXE и список версий, доступных для бесплатной загрузки.
Совместимость с Windows 10, 8, 7, Vista, XP и 2000
Средняя оценка пользователей
| Сведения о разработчике и ПО | |
|---|---|
| Разработчик ПО: | Microsoft Corporation |
| Программа: | Microsoft® Windows® Operating System |
| Авторское право: | © Microsoft Corporation. All rights reserved. |
| Сведения о файле | |
|---|---|
| Набор символов: | Unicode |
| Код языка: | English (U.S.) |
| Флаги файлов: | (none) |
| Маска флагов файлов: | 0x003f |
| Точка входа: | 0x2970 |
| Размер кода: | 8704 |
| Информация о файле | Описание |
|---|---|
| Размер файла: | 78 kB |
| Дата и время изменения файла: | 2017:03:18 18:19:03+00:00 |
| Дата и время изменения индексного дескриптора файлов: | 2017:11:05 07:07:54+00:00 |
| Тип файла: | Win32 EXE |
| Тип MIME: | application/octet-stream |
| Предупреждение! | Possibly corrupt Version resource |
| Тип компьютера: | Intel 386 or later, and compatibles |
| Метка времени: | 2082:06:26 08:35:16+00:00 |
| Тип PE: | PE32 |
| Версия компоновщика: | 14.10 |
| Размер кода: | 8704 |
| Размер инициализированных данных: | 82944 |
| Размер неинициализированных данных: | 0 |
| Точка входа: | 0x2970 |
| Версия ОС: | 10.0 |
| Версия образа: | 10.0 |
| Версия подсистемы: | 10.0 |
| Подсистема: | Windows command line |
| Номер версии файла: | 10.0.15063.0 |
| Номер версии продукта: | 10.0.15063.0 |
| Маска флагов файлов: | 0x003f |
| Флаги файлов: | (none) |
| Файловая ОС: | Windows NT 32-bit |
| Тип объектного файла: | Executable application |
| Подтип файла: | 0 |
| Код языка: | English (U.S.) |
| Набор символов: | Unicode |
| Наименование компании: | Microsoft Corporation |
| Описание файла: | WMI Service Control Utility |
| Версия файла: | 10.0.15063.0 (WinBuild.160101.0800) |
| Внутреннее имя: | winmgmt |
| Авторское право: | © Microsoft Corporation. All rights reserved. |
| Оригинальное имя файла: | winmgmt.exe |
| Название продукта: | Microsoft® Windows® Operating System |
| Версия продукта: | 10.0.15063.0 |
✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.
WinMgmt.exe — ошибки выполнения
Ошибки выполнения — это ошибки Windows, возникающие во время «выполнения». Термин «выполнение» говорит сам за себя; имеется в виду, что данные ошибки EXE возникают в момент, когда происходит попытка загрузки файла WinMgmt.exe — либо при запуске приложения Windows, либо, в некоторых случаях, во время его работы. Ошибки выполнения являются наиболее распространенной разновидностью ошибки EXE, которая встречается при использовании приложения Windows.
К числу наиболее распространенных ошибок WinMgmt.exe относятся:
Не удается запустить программу из-за отсутствия WinMgmt.exe на компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему.
Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
Поиск причины ошибки WinMgmt.exe является ключом к правильному разрешению таких ошибок. Несмотря на то что большинство этих ошибок EXE, влияющих на WinMgmt.exe, происходят во время запуска, иногда ошибка выполнения возникает при использовании Microsoft® Windows® Operating System. Причиной этого может быть недостаточное качество программного кода со стороны Microsoft Corporation, конфликты с другими приложениями, сторонние плагины или поврежденное и устаревшее оборудование. Кроме того, эти типы ошибок WinMgmt.exe могут возникать в тех случаях, если файл был случайно перемещен, удален или поврежден вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.
Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):
Если на этапе 1 не удается устранить ошибку WinMgmt.exe, перейдите к шагу 2 ниже.
Шаг 2. Запустите средство проверки системных файлов (System File Checker), чтобы восстановить поврежденный или отсутствующий файл WinMgmt.exe.
Средство проверки системных файлов (System File Checker) — это утилита, входящая в состав каждой версии Windows, которая позволяет искать и восстанавливать поврежденные системные файлы. Воспользуйтесь средством SFC для исправления отсутствующих или поврежденных файлов WinMgmt.exe (Windows XP, Vista, 7, 8 и 10):
Следует понимать, что это сканирование может занять некоторое время, поэтому необходимо терпеливо отнестись к процессу его выполнения.
Если на этапе 2 также не удается устранить ошибку WinMgmt.exe, перейдите к шагу 3 ниже.
Шаг 3. Выполните обновление Windows.
Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла WinMgmt.exe. Мы храним полную базу данных файлов WinMgmt.exe со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Windows . Чтобы загрузить и правильно заменить файл, выполните следующие действия:
Windows 10: C:\WINDOWS\system32\wbem\Windows 8.1: C:\WINDOWS\system32\wbem\
Windows 8: C:\WINDOWS\system32\wbem\
Windows 7: C:\WINDOWS\system32\wbem\
Windows 7: C:\Windows\SysWOW64\wbem\
Показать на 4 каталогов больше + Windows Vista: C:\WINDOWS\system32\wbem\
Windows Vista: C:\Windows\SysWOW64\wbem\
Windows XP: C:\WINDOWS\system32\dllcache\
Windows XP: C:\WINDOWS\system32\wbem\
Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.
В ходе работы с несколькими приложениями вдруг начинаем замечать просадку производительности, и ее причиной в Диспетчере задач является процесс WMI Provider Host, который чрезмерно грузит процессор.
Этот компонент является одним из ключевых звеньев стабильной работы системы, и используется приложениями для получения информации о состоянии ОС посредством запросов через WMI-провайдеры. И когда WmiPrvSE.exe начинает грузить процессор, то такое поведение связано с необычным поведением его службы — Инструментария управления Windows, которая начинает использовать больше ресурсов компьютера, чем требуется, или вызвано вмешательством в работу стороннего процесса.
Перезапуск службы Инструментария управления Windows
В многих случаях высокая нагрузка на процессор может вызвана некорректной работой службы Инструментария управления Windows. Попробуйте ее перезапустить.
Откройте окно «Выполнить» клавишами Win + R, наберите команду services.msc и подтвердите ее запуск на Enter.
В списке найдите Инструментарий управления Windows. Щелкните по ней правой кнопкой мыши и выберите «Перезапустить».
Теперь нужно перезапустить связанные службы. Закройте окно и кликните правой кнопкой мыши на значок Пуск. В контекстном меню перейдите на пункт «Командная строка (администратор). Для вызова командной строки в Windows 7 откройте строку поиска, наберите команду cmd и правым кликом мыши запустите ее от имени администратора.
В консоли введите одну за другой перечисленные команды, подтверждая запуск каждой на Enter.
net stop iphlpsvc
net stop wscsvc
net stop Winmgmt
net start Winmgmt
net start wscsvc
net start iphlpsvc
Закройте командную строку и перезапустите компьютер. Нагрузка на процессор, создаваемая процессом WMI Provider Host, должна существенно снизится.
Выполнение чистой загрузки
Вполне возможно, что WMI Provider Host сильно грузить ЦП из-за определенного приложения. Поэтому попробуйте выполнить чистую загрузку системы и изолировать приложение, которое вызывает чрезмерное использование ресурсов системы.
При чистой загрузке запускается минимальный набор служб, требуемые для поддержки стабильной работы ОС.
Войдите в систему с учетной записью администратора. Откройте диалоговое окно «Выполнить» нажатием на Win + R, наберите команду msconfig и подтвердите ее запуск на Enter.
В верхнем меню перейдите на вкладку «Службы» и отметьте флажком опцию «Не отображать службы Майкрософт». Останутся только сторонние, которые связаны с программами, установленные пользователем.
Нажмите на кнопку «Отключить». Таким образом, они не будут загружены автоматически при следующем запуске системы.
Перейдите на вкладку «Автозагрузка» и нажмите на ссылку «Открыть диспетчер задач».
Откроется список с программами, которые загружаются вместе с ОС. Нужно отключить все включенные программы нажатием на соответствующую кнопку.
После перезагрузите компьютер. Таким образом, система запустится в состоянии «чистой» загрузки. Теперь проверьте, насколько WMI Provider Host грузит ЦП. Если нагрузка на процессор снизилась к нормальным значениям, это означает, что какая-то сторонняя программа была ее причиной.
Начните включать по одной и несколько служб, каждый раз перезагружая ПК, пока высокая нагрузка на процессор не вернется.
Переустановите приложение, которая вызывает высокое использование ресурсов ПК или отключите его.
Поиск ошибок в журнале просмотра событий
С помощью журнала событий можно обнаружить ошибочный процесс, который воздействует на WMI Provider Host и заставляет его грузить процессор.
В поисковой строке (Win + S) наберите «просмотр событий» и кликните по найденному результату.
В верхнем меню перейдите на вкладку «Вид» и отметьте флажком «Отобразить аналитический и отладочный журналы».
В левой части экрана перейдите по пути:
Журналы приложений и служб – Microsoft – Windows – WMI-Activity
Дважды кликните WMI-Activity, чтобы развернуть его содержимое, и нажмите на Operational, чтобы открыть операционные журналы в нижней части окна.
Просмотрите ошибки. На вкладке общие в описании найдите термин ClientProcessId и запомните или запишите его значение, например, 6340.
Закройте «Просмотр событий».
Теперь откройте Диспетчер задач. В строке «Выполнить» (Win + R) наберите taskmgr и подтвердите на Enter.
Перейдите в закладку Службы и найдите число с тем же ИД процесса, что следует за параметром ClientProcessID.
Читайте также: