WMI

Метки:  , , , , , , , , , , , , , , ,

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

Windows Management Instrumentation (WMI) — инструментарий управления Windows, механизм [централизованного] управления и наблюдения за функционированием многочисленных (программных и аппаратных) компонентов компьютерной инфраструктуры под управлением операционной системы Windows.

С момента своего появления в Windows95 OSR2, WMI остается основным механизмом управления для всех пользовательских/серверных операционных систем линейки Windows. Фактически WMI делает доступным создание управляющих приложений (скриптов), целью которых является взаимодействие (сбор информации/управление) с многочисленными, разнородными ресурсами системы Windows. Со временем технология WMI активно развивалась и стала основой для создания серьёзных корпоративных продуктов, таких как Configuration Manager. WMI изначально является расширенной и адаптированной под Windows реализацией промышленного стандарта WBEM:

Web-Based Enterprise Management (WBEM) - модель управления [предприятием] на базе web-стандартов (иначе: при помощи Интернет).

В разработке WBEM участвовал ряд крупных компаний, ставивших своей целью разработку стандартов управления производственной информационной средой, обеспечивающих координацию работы всех физических и логических компонентов [этой среды] из единой точки [управления], не зависящих от типа оборудования, сетевой инфраструктуры, операционной системы и множества других нюансов (стандартизация). Для этого была предложена общая информационная модель (Common Information Model, CIM), служащая для [схематичного] представления физической и логической структуры любого управляемого компонента [на предприятии] в виде масштабируемой объектно-ориентированной информационной модели и описывающая интерфейсы доступа к данным.

Масштабируемость (расширяемость) модели CIM призвана обеспечить [системам/драйверам/приложениям] добавление собственных классов, объектов, методов и свойств.

А поскольку WMI базируется на CIM, то её можно считать открытой унифицированной системой интерфейсов доступа к множеству [контролируемых] параметров, имеющихся у разнородных (аппаратных/программных) компонентов, функционирующих под управлением операционной системы Windows.
Достаточно уже определений, всё же хотелось бы понять, какое это имеет практическое обоснование? Давайте представим себе [абстрактную] ситуацию: возьмем системного администратора Васю Пупкина из первой половины 90-х годов, сервера у него на какой-нибудь версии Windows NT, клиенты вообще не пойми на чём. Внезапно (внезапность вообще частый спутник нашего брата :) возникает мысль: хорошо бы знать, на скольких моих машинках установлена Windows95 OSR2, из отобранных систем выделить работающие с 8Мб ОЗУ (и больше) и собранные на матерях Zida 5DXP (Tomato Board), на каких из полученных систем BIOS версии младше 1.90? И это не самый сложный запрос, согласитесь. И как предлагаете эту самую задачу администратору Васе решать? Естественно, что решения подобных задач были в то время нетривиальны, ведь данные разнообразных компонентов ОС всегда хранились во множестве источников: база пользователей SAM, журнал событий Event Log, системный реестр, файловая система. Доступ к этим источникам осуществлялся с помощью многочисленных утилит (диспетчер пользователей, просмотрщик журнала событий, редактор реестра), и хорошо если этот инструментарий был доступен непосредственно в ОС, а ведь часто имелся лишь API и для доступа к информации приходилось вообще писать что-то своё!! Сколько же времени уходило на решение подобных задач? В общем, администратор для решения схожих задач должен был осваивать большое количество разнообразных техник и приемов. Способствовало ли это возникновению запроса на разработку некоего стандартизованного доступа к разнородным данным компонентов операционной системы?! Вопрос, конечно же, риторический.

WMI обеспечивает решение разнообразных задач управления: например, проведение инвентаризации оборудования и программного обеспечения, мониторинг работы процессов и служб и множество аналогичных.

WMI представляет собой непротиворечивую и расширяемую объектную модель представления широкого спектра объектов (ресурсов): аппаратные/логические устройства, исполняемые процессы, файловая система, реестр, приложения, базы данных и многое многое другое.

WMI построена по объектно-ориентированному принципу, то есть в ней большинство данных, связанных с разнообразными компонентами операционной системы, представлены в виде объектов, их свойств (атрибутов, характеристик объекта) и методов (действий на объектом).

И для тех, кто пока еще слабо разбирается в объектно-ориентированном программировании, скажу что объект (или экземпляр класса) - сложноструктурированное представление информации, которое полностью описывает некую сущность в ОС. Класс - это модель объекта, некое абстрактное понятие, своеобразный "чертеж", содержащий описательную часть, на основе которой затем создаются объекты. Класс описывает свойства и методы, доступные у создаваемых впоследствии по этому описанию объектов. WMI поддерживает запросы от управляющих приложений на следующие операции:

  • получение/изменение элементов данных (свойств) управляемых объектов.
  • вызов методов управляемых объектов (действий над управляемыми объектами).
  • выполнение запросов к набору данных управляемых объектов.
  • регистрация для получения событий от управляемых объектов.

Инфраструктура WMI

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

Служба/сервис WMI

В системе за всё это отвечает компонент под названием Менеджер объектов CIM (Common Information Model Object Manager, CIMOM), занимающийся обслуживанием взаимодействия управляющих приложений с WMI-провайдерами и управлением хранилищем базы данных WMI (репозиторием). Традиционно, как и большинство подобного функционала, CIMOM реализован в системе в виде службы, которая в данном конкретном случае носит название Инструментарий управления Windows. Исполняемый модуль, содержащий весь функционал (функции CIMOM) службы WMI, именуется winmgmt.exe и размещается в директории %SystemRoot%\System32\Wbem\. В разных версиях операционной системы Windows служба WMI запускалась по-разному:

Версия Метод запуска
Windows 2000- Менеджер запускался в качестве отдельной службы Windows. При таком способе WMI-провайдеры загружались в единое адресное пространство процесса, таким образом при падении одного провайдера мог завалиться весь процесс целиком. Вдобавок это порождало проблемы безопасности.
Windows XP Все компоненты службы WMI запускаются в контексте общего хоста служб SVCHOST.
Windows Vista+ Усовершенствована изоляция процессов путем загрузки провайдеров WMI в один или несколько экземпляров WMIPrvse.exe. Доработки в стабильности и безопасности WMI, включая задание уровней изоляции процессов, контекста безопасности, лимита ресурсов для провайдеров WMI.

CIMOM запускается в контексте общего хоста служб (svchost), но может быть и запущен в качестве отдельного процесса. Провайдеры WMI должны быть зарегистрированы при помощи CIMOM для корректного перенаправления запросов от конечного (управляющего) приложения к целевому провайдеру. В дополнение ко всему, для доступа к WMI из сценариев, в системе присутствует библиотека поддержки сценариев WMI (WMI scripting library), которая располагается в файле wbemdisp.dll. Параметры конфигурации сервиса WMI представлены в ключе реестра:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM
WMI предоставляет доступ к собственным ресурсам через программный интерфейс компонентной объектной модели (COM API).

Провайдеры WMI

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

Таким образом, WMI-провайдеры обеспечивают связь между менеджером объектов CIM и управляемыми ресурсами.

Из этого следует, что фактически провайдеры WMI маскируют [собой] детали внутренней реализации управляемых ими объектов, позволяя CIMOM взаимодействовать с подконтрольными провайдерам объектами единообразно, используя WMI API. Для лучшего понимания механизма можно провести аналогию между WMI-провайдерами и драйверами устройств: они так же обеспечивают взаимодействие с аппаратным или программным ресурсом (или набором ресурсов). Провайдеры (поставщики) являются основой WMI, поскольку:

Практически все классы WMI и соответствующие им методы реализованы посредством провайдеров WMI.

Провайдеры WMI обычно представлены в системе в виде пары файлов:

  • MOF-файла, определяющего классы событий/данных (для которых данные будут предоставляться);
  • исполняемого модуля (формата DLL/EXE/***-файла), содержащего код, обеспечивающий весь процесс обработки/предоставления данных;

Выбор файла-контейнера для хранения кода достаточно широкий, поскольку любое приложение в системе (включая и драйвера) теоретически может функционировать в качестве провайдера (поставщика) WMI и создавать собственные классы WMI. Тем не менее, код провайдеров чаще представляется следующими методами:

  • в качестве динамических библиотек (COM DLL) пользовательского режима;
  • в качестве драйверов режима ядра;

Каждый WMI-провайдер имеет собственные идентификаторы CLSID, зарегистрированные в системном реестре и ассоциированные с ним для дальнейшего разрешения COM. Данный CLSID используется для поиска соответствующей библиотеки (DLL), реализующей весь функционал провайдера. WMI провайдер собирает данные: например, при запросе списка процессов - опрашивает все работающие/запущенные в системе процессы, при работе с реестром - перечисляет ключи реестра, и так далее.

Классически провайдеры реализуются в виде COM/DCOM-серверов, представленных в виде библиотек (DLL), обычно располагающихся в каталоге %SystemRoot%\System32\Wbem\.

В то время как служба WMI обслуживает управляющие приложения через COM-интерфейс, WMI-провайдеры действуют в качестве COM-серверов, обрабатывающих запросы от службы WMI. Когда провайдер загружается, он регистрирует собственное положение и классы, объекты, свойства, методы и события, которые он предоставляет [в WMI]. WMI использует эту информацию для перенаправления запросов к соответствующему провайдеру. Так же взаимодействие между разными участниками WMI может происходить:

  • локально - через COM-интерфейс;
  • удаленно - через DCOM-интерфейс или [более современный] Windows Remote Management (WinRM).

WMI обрабатывает запросы от управляющих приложений следующим образом:

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

WMI структура

Microsoft предлагает некоторое количество "встроенных" провайдеров в составе дистрибутива операционной системы Windows: журнала событий, системного реестра, файловой системы и некоторых других.

Репозиторий (хранилище)

Как было сказано выше, WMI базируется на том, что информация о состоянии любого управляемого объекта может быть представлена в виде общей информационной модели (CIM), которая сама по себе фактически и является хранилищем объектов и классов, моделирующих различные компоненты компьютерной системы. Таким образом, в общем случае:

Репозиторий CIM - хранилище модели CIM.

или более адаптированно для реалий операционной системы:

WMI (CIM) Репозиторий - это дисковая база данных, используемая для хранения "откомпилированного представления" объектов WMI (определений классов и экземпляров пространств имен) и обеспечивающая эффективный (оптимизированный) доступ к ним.

Где класс выступает в качестве модели (шаблона) управляемого объекта (фактически любого компонента операционной системы: процесса, сервиса, файловой системы, события, диска и многого другого). В файловой системе репозиторий располагается по пути: %SystemRoot%\System32\Wbem\Repository\ и состоит из следующих файлов (для Windows 7):

Имя Описание
index.btr Индекс (индексный файл, словарь), содержащий ключи и адреса записей в файле данных (objects.data). Содержит индекс Би-дерева, используемым для поиска CIM-записей в файле objects.data. Ключи в индексе являются ASCII-строками, которые содержат хеш данных [фиксированной длины]. Когда необходимо извлечь объект из objects.data, используется индекс для быстрого поиска смещения.
mapping1.map
mapping2.map
mapping3.map
Порядковый номер в заголовке каждого файла сопоставления помогает службе WMI выбрать активный файл сопоставления. [Активный] файл сопоставления определяет, как именно сопоставить номер страницы логических данных с номером страницы физических данных внутри файлов objects.data и index.btr. Без этих сопоставителей, невозможно корректно интерпретировать данные в файле objects.data.
objects.data Данные объектов. Собственно, сам репозиторий. Файл objects.data содержит CIM-записи в двоичном формате. В ранних версиях Windows репозиторий размещался в файле cim.rep.

Данные в WMI могут быть двух типов:

  • статические (откомпилированные) данные -- доступны в определении класса или объекта и хранятся в репозитории WMI;
  • динамические (формируемые в процессе) данные -- доступны в виде ответа на запрос к WMI-провайдеру (создаются "на лету"). например, объекты Win32_Process, которые генерируются в ходе опроса дерева процессов.

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

В дополнение ко всему, в репозитории WMI хранится информация о безопасности WMI.

Судя по всему, WMI использует доработанную версию Microsoft Jet Database Engine для доступа к данным репозитория, поддерживающую вставку, удаление, поиск ключей и сопоставление по префиксу ключа (спасибо, кэп).

MOF

Спецификация CIM, помимо всего прочего, включает в себя описание языка, предназначенного для предоставления понятного человеку способа описания структур CIM. WMI использует так называемый формат управляемого объекта (MOF, Managed Object Format) в качестве языка, используемого для описания классов CIM.

MOF представляет собой язык (формат, способ) описания классов, экземпляров [классов] и иных структур CIM с использованием специализированных директив, описываемых в привычном для нас текстовом формате. Базируется на языке описания интерфейсов (Interface Definition Language, IDL).

MOF-файл содержит директивы, задающие: имена сущностей, которые могут быть запрошены, типы полей в сложных классах, и разрешения, связанные с группами объектов. Структуры подавляющего большинства объектов WMI описываются парой файлов следующих форматов:

  • <имя_файла>.mof - общее описание объектов;
  • <имя_файла>.mfl - локализованное описание объектов;

Данные, содержащиеся в файлах MOF при помощи специальных утилит компилируются и сохраняются в репозитории WMI. Например, mofcomp.exe фактически выполняет компиляцию/вставку данных, описанных в файлах MOF, в репозиторий CIM. Можно сказать, что MOF это фактически объектно-ориентированный язык, позволяющий описывать:

  • Пространства имен - Классы
  • Свойства
  • Методы
  • Квалификаторы
  • Интерфейсы
  • Ссылки
  • Комментарии

Разработчик может создавать собственные классы [данных], предоставляющие данные, доступные через уже имеющиеся в системе провайдеры WMI, такие (например) как данные системного реестра. В этих случаях, администратор должен импортировать сторонние mof-файлы. Например, файл провайдера SMS smsprov.mof содержит определения [на MOF-языке], описывающие пространство имен Root\SMS и содержащиеся в нем классы. MOF использует синтаксис C++ и предоставляет [своеобразный] шаблон для описания WMI-объекта. В то время, как WMI-провайдеры генерируют неструктурированные данные, MOF-файлы представляют шаблоны, в которых сгенерированные данные форматированы.

Классы и пространства имен WMI

Классы WMI сгруппированы в пространства имен (namespaces), которые выстроены иерархически в виде дерева (с единым корнем) и напоминают используемые в традиционных объектно-ориентированных языках программирования.

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

Вне зависимости от версии WMI в системе имеется несколько предопределенных пространств - корневое пространство имён Root, и 4 пространства, располагающихся уровнем ниже: CIMv2, Default, Security и WMI. Все пространства имен являются производными от КОРНЕВОГО (Root) пространства имен. Пространства имен организуют в себе классы WMI и другие элементы, таким образом их проще представить себе в качестве контейнера или каталога файловой системы. Некоторые пространства имен содержат вложенные пространства имен, и так далее. Классы объектов WMI распределены иерархически в пространства имен, похожих на используемые в традиционных объектно-ориентированных языках программирования. Одно из существующих в Windows пространств имен назначается пространством по умолчанию, в стандартной поставке им является пространство имен Root\CIMV2. Таким образом, при запросах объектов, в которых явно не задано пространство имен, будем выбрано пространство по умолчанию.

Язык запросов WMI (WQL)

Очевидно было бы крайне неудобно ограничивать доступ из управляющих приложений (потребителей WMI) к управляемым объектам лишь функциями WMI API (доступного исключительно из кода приложений), гораздо универсальнее создать специализированный удобочитаемый язык запросов, который может быть использован в различного вида инструментарии (программах/консолях). Для этой цели был разработан Язык запросов WMI:

WMI Query Language (WQL) - язык запросов, предоставляющий простой синтаксис для обращения к экземплярам объектов, классам и пространствам имен WMI. С использованием подобных запросов и происходит обращение потребителей (управляющих приложений) WMI к управляемым объектам WMI. WQL, в свою очередь, является Microsoft-адаптацией языка запросов CIM (CIM Query Language, CQL).

Тем не менее не все провайдеры управляемого объекта поддерживают WQL, в подобных ситуациях менеджер объектов CIM должен преобразовать запрос к виду, обрабатываемому [конкретным] провайдером. WQL представляет собой специально сконструированные запросы, которые являются подмножеством (подвидом) SQL. Концептуальное отличие от ANSI SQL — это отсутствие инструкций для изменения данных, то есть при помощи WQL возможна лишь выборка данных с помощью команды SELECT. Помимо ограничений на работу с объектами, WQL не поддерживает такие операторы как DISTINCT, JOIN, ORDER, GROUP, математические функции, а конструкции IS и NOT IS применяются только в сочетании с константой NULL. WQL запросы можно протестировать при помощи GUI-утилиты wbemtest и CUI-утилиты wmic (утилита wmic не требует указания ключевого слова SELECT и полей выборки), а затем применять их в собственных скриптах.

Права доступа к пространствам имен

Механизм безопасности действует в WMI на уровне пространств имен. Для каждого пространства может быть определен собственный дескриптор безопасности, содержащий таблицу контроля доступа. Каждая запись таблицы контроля доступа содержит информацию о том, какие права (разрешения) имеет [тот или иной] пользователь при выполнении операций в данном пространстве имен. Несмотря на то, что пространства имен расположены по идентичному пути, то есть имеют единый корень, привилегии отличны для каждого пространства имен, и поэтому разрешения дочернего пространства имен не наследуются от родительского. Чтобы проверить/назначить разрешения WMI, выполните следующие действия:

  1. ПускАдминистрирование и выберите пункт Управление компьютером;
  2. Разверните узел Службы и приложения и щелкните правой кнопкой мыши элемент управления WMI;
  3. Правая кнопка мыши → выберите пункт меню Свойства, чтобы открыть диалоговое окно Свойства элемента управления WMI;
  4. Перейдите на вкладку Безопасность и разверните корневой узел Root. Выберите требуемый объект пространства имен (установив курсор), затем нажмите кнопку Безопасность;

Отладка/запись событий WMI

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

  1. Открыть Просмотр Событий (Event Viewer, Eventvwr).
  2. В меню Вид, выбрать Отобразить аналитический и отладочный журналы.
  3. В дереве в левом фрейме разворачиваем пункт Журналы приложений и служб (Applications and Service Logs) → Microsoft → Windows → WMI Activity
  4. Правую кнопку мыши на пункте Trace и выбираем Включить журнал (Enable Log). Если выбрать Свойства из того же меню, то можно увидеть куда пишутся события трассировки: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-WMI-Activity%4Trace.etl.

Инструменты для взаимодействия с WMI

Наименование Назначение
wmimgmt.msc Оснастка консоли управления [MMC] для настройки WMI (локальная система).
winmgmt.exe Консольная утилита управления WMI (локальная система).
wbemtest.exe Утилита [с графическим интерфейсом] для взаимодействия с инфраструктурой WMI: подключение к пространству имен, выполнения операций (локальная/удаленная система).
wmic.exe Консольная утилита для взаимодействия со структурой WMI (локальная/удаленная система).
wmidiag.vbs Утилита (скрипт) диагностики WMI, разработанный MS. На данный момент недоступна на официальном сайте MS, поскольку некоторые версии WMIDiag корректно работали только с определенными версиями ОС Windows.
mofcomp.exe Компилятор MOF-файлов. Выполняет анализ директив (инструкций) MOF-файла и добавление определенных там классов/экземпляров классов в репозиторий WMI (локальная система).
Windows Scripting Host (WSH) в Windows представлены два языка, базирующихся на WSH: VBScript и JScript. Несмотря на то, что эти языки [морально] устарели, оба всё еще остаются мощными скриптовыми языками, прекрасно решающими задачи по взаимодействию с WMI.
Powershell Язык сценариев от разработчиков.
winrm.exe Консольная утилита для удаленного управления Windows. Может быть использована для перечисления экземпляров объектов WMI, вызова методов, создания/удаления экземпляров объектов посредством службы WinRM (локальная/удаленная система). При помощи утилиты можно задавать параметры сервиса WinRM.
C/C++ Есть возможность взаимодействовать с WMI с помощью "неуправляемого" кода, написанного на C/C++, для этого используется Component Object Model (COM) API для WMI. Для этого существует набор интерфейсов IWbem* и некоторых других.
.NET Библиотека классов .NET предоставляет несколько WMI классов в рамках пространства имен System.Management, взаимодействующих с WMI в языках C#, VB.Net, and F#.

Ошибки WMI

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

Если репозиторий имеет те или иные повреждения, то служба WMI нормально функционировать не будет.

Ну а последствия неправильного функционирования службы WMI в системе следующие:

  • отказ в запуске [зависимых от WMI] системных служб;
  • отказ в установке/запуске приложений [зависимых от WMI];
  • некорректная работа объектов групповых политик;
  • ошибки при выполнении скриптов [использующих WMI];

Более осязаемые проявления проблем с сервисом/репозиторием WMI:

  1. Ошибки в log-файлах самих приложений: WBEM_E_NOT_FOUND - 0x80041002.
  2. Ошибки отказа при подключении к пространствам имен Root\Default или Root\cimv2;
  3. Ошибка/подвисание при открытии свойств WMI в оснастке Управление компьютером: "WMI : Not Found", "0x80041010 WBEM_E_INVALID_CLASS", "Filed to initialize all required WMI classes";
  4. Подвисание разных утилит по работе с WMI (wbemtest и прч);
  5. Отсутствие в репозитории некоторых схем/классов/объектов;
  6. Проблема в запуске SCCM-агента (WBEM_E_INVALID_CLASS - 0x80041010);
  7. Ошибки подключения/операций (0x8007054e);
  8. Ошибки подгрузки WMI-провайдеров: WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013;
  9. Ошибки доступа при попытке доступа к WMI-объектам: E_ACCESS_DENIED - 0x80070005;
  10. Ошибки поиска пространств имен: WBEM_E_INVALID_NAMESPACE - 0x8004100E;
  11. Ошибки в Журнале событий Windows (Приложение) - источник WinMgmt, EventID - 10;

Восстановление WMI

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

  1. Набор действий по восстановлению репозитория через утилиты командной строки;
  2. [многочисленные] скрипты по восстановлению репозитория/перекомпиляции mof/mfl, перерегистрации провайдеров;

Эти методики подходят для большинства ситуаций, которые могут встретиться на рабочих станциях пользователей/серверах. Тем не менее, имеется несколько тонких моментов в логике восстановления работоспособности WMI, и их нужно непременно усвоить:

  1. Самым примитивным способом восстановления репозитория является удаление/переименование его рабочей директории. То есть, вы переименовываете директорию %SystemRoot%\System32\Wbem\Repository, к примеру, в Repository.old и ждете. После определенного таймаута сервис определит отсутствие директории репозитория и запустит процедуру восстановления. Но этот простой способ особенно никем не применяется, поскольку не учитывает перекомпиляцию не входящих в автовосстановление (список .mof в реестре) классов и не выполняет перерегистрацию провайдеров.
  2. Вне зависимости от того, где и как оно применяется, удаление рабочего WMI-репозитория является достаточно разрушительной операцией, которая может повлечь за собой потерю данных, возникновение ошибок в WMI-приложениях, замедление отклика некоторых операций, и возникновении других, сложнодиагностируемых проблем.
  3. Существуют приложения, которые в процессе установки в систему [самостоятельно] напрямую обновляют репозиторий, вообще не используя никаких .mof-файлов. Соответственно, при пересоздании (удалении и создании) репозитория подобные приложения не имеют возможности обновить базу данных и их данные, связанные с WMI, будут удалены (потеряны) вплоть до момента, пока вы не переустановите означенные приложения (в режиме восстановления).
  4. Следует помнить, что не все приложения хранят свои WMI-провайдеры (.dll) и .mof-файлы в %SystemRoot%\System32\wbem. Соответственно, вам нужно будет выявить подобные приложения (поиск по маске *.mof), и либо произвести их переустановку, либо выполнить ручную регистрацию провайдеров (библиотек) и перекомпиляцию .mof-файлов.
  5. Существуют .mof-файлы, которые содержат директивы вида #pragma deleteclass или #pragma deleteinstance. По хорошему, некоторые источники советуют временно перемещать подобные файлы в стороннюю директорию перед потоковой перекомпиляцией всех .mof-файлов. Но никто этого делать не хочет, ну и мы не будем.
  6. [ начиная с Windows7 ] в каталоге репозитория можно обнаружить файлы, содержащие информацию об удалении, такие как OfflineFilesWmiProvider_Uninstall.mof, Wdf01000Uninstall.mof, Win32_EncryptableVolumeUninstall.mof, WinsatUninstall.mof, wpcuninst.mof, WsmAgentUninstall.mof, WUDFxUninstall.mof, в именах которых присутствует слово uninstall. И если скрипты перечисляют и компилируют все без исключения файлы, то компиляция подобных файлов приведет к удалению классов, соответственно последние станут недоступны. Но эту проблему можно обойти путем исключения.
  7. Перекомпиляция MOF-файлов зачастую должна производиться в определенной последовательности. Например, классы в файле [условно] 1.mof могут зависеть от классов, указанных в файле 2.mof. Если последние отсутствуют, утилита mofcomp.exe не будет добавлять классы. Для того, что бы подобрать правильную последовательность, нужно знать зависимости для всех классов, представленных в системе. Возможно эту проблему можно частично решить перекомпиляцией каких-то базовых (основных) .mof-файлов в первую очередь, перед основным циклом перекомпиляции всех остальных. Поэтому скрипты на данный момент не делают всё идеально, но все-равно даже это работает и приносит результат :)
  8. Везде встречаются рекомендации о том, что сперва надо компилировать .mof-файлы, а затем уже их локализованные .mfl-копии. Когда все файлы размещались в одной директории, было удобно, но в последних версиях ОС .mfl переехали в локализованные поддиректории (например, ru-RU), поэтому проход по *.mfl надо делать с учетом вложенных директорий?
  9. Имеются рекомендации, что в 64-битных ОС работу ручную перекомпиляцию репозитория надо выполнять из директории %SystemRoot%\SysWOW64\wbem, а на 32-битных системах из %SystemRoot%\System32\wbem, но оказалось, что (в ОС, начиная с Windows 7) в директории для 64-битной ОС отсутствуют многие .mof файлы, что меня лично настораживает. Рекомендация могла устареть? К тому же, большинство на это забивает и радуется :)
Поэтому вы уже поняли, что приведенные тут решения несовершенны, но в реальных боевых условиях не раз помогали избавиться от проблем с WMI (даже удивительно).

Метод 1

Самое правильное, это всегда начинать с наименее деструктивных техник работы с репозиторием, например с помощью входящей в состав дистрибутива утилиты winmgmt. Выполните следующую команду (начиная с Windows Vista/Server 2008):

winmgmt /verifyrepository

Если проверка вернула ошибку (например, WMI repository is INCONSISTENT), то выполняем перестроение репозитория:

winmmgmt /salvagerepository

Затем повторно проверяем репозиторий:

winmgmt /verifyrepository

Ну и если перестроение не дало результата и вы всё еще получаете ошибки, то можно воспользоваться более деструктивным методом (серия: остановка службы + сброс репозитория):

net stop winmgmt /y
winmgmt /resetrepository

Метод 2

Потенциально, приведенный в данном методе скрипт достаточно разрушителен, поскольку удаляет рабочий репозиторий. Тем не менее, при всех своих недостатках метод достаточно эффективен и не раз меня выручал. Следующий powershell-скрипт оптимизирован для использования под Windows 7 и выше, представляет собой последовательность действий по сохранению (в резервную папку) текущего репозитория, перестроению репозитория (перекомпиляции объектов), перерегистрации компонентных библиотек (провайдеров), а так же учитывает большинство описанных выше нюансов. Создайте файл resetWMI.ps1 и разместите там следующее содержимое:

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

Комментарии: 3

  1. Пример изменения яркости экрана через PS.

    (Get-WmiObject -Namespace root/WMI -Class WmiMonitorBrightnessMethods).WmiSetBrightness(1,80)
    80-яркость в процентах.

  2. Спасибо, за полезную статью)

  3. Очень доходчиво объясняете. Спасибо!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *