powershell – Use mofcomp.exe with a variable instead of a file – Stack Overflow

Use mofcomp.exe with a variable instead of a file

# Use `cf()` to save the script block's output to a temporary *.mof file
# and return that file's path.
& 'C:WindowsSystem32wbemmofcomp.exe' (cf -Extension .mof { Export-WMIDetailsHC ... })
cf  # clean up temporary file

# Define a succinct alias.
set-alias cf ConvertTo-TempFile
function ConvertTo-TempFile {
  [CmdletBinding(DefaultParameterSetName='Cleanup')]
  param(
      [Parameter(ParameterSetName='Standard', Mandatory=$true, Position=0)]
      [ScriptBlock] $ScriptBlock
    , [Parameter(ParameterSetName='Standard', Position=1)]
      [string] $LiteralPath
    , [Parameter(ParameterSetName='Standard')]
      [string] $Extension
    , [Parameter(ParameterSetName='Standard')]
      [switch] $NoBOM
  )

  $prevFilePath = Test-Path variable:__cttfFilePath
  if ($PSCmdlet.ParameterSetName -eq 'Cleanup') {
    if ($prevFilePath) { 
      Write-Verbose "Removing temp. file: $__cttfFilePath"
      Remove-Item -ErrorAction SilentlyContinue $__cttfFilePath
      Remove-Variable -Scope Script  __cttfFilePath
    } else {
      Write-Verbose "Nothing to clean up."
    }
  } else { # script block specified
    if ($Extension -and $Extension -notlike '.*') { $Extension = ".$Extension" }
    if ($LiteralPath) {
      # Since we'll be using a .NET framework classes directly, 
      # we must sync .NET's notion of the current dir. with PowerShell's.
      [Environment]::CurrentDirectory = $pwd
      if ([System.IO.Directory]::Exists($LiteralPath)) { 
        $script:__cttfFilePath = [IO.Path]::Combine($LiteralPath, [IO.Path]::GetRandomFileName()   $Extension)
        Write-Verbose "Creating file with random name in specified folder: '$__cttfFilePath'."
      } else { # presumptive path to a *file* specified
        if (-not [System.IO.Directory]::Exists((Split-Path $LiteralPath))) {
          Throw "Output folder '$(Split-Path $LiteralPath)' must exist."
        }
        $script:__cttfFilePath = $LiteralPath
        Write-Verbose "Using explicitly specified file path: '$__cttfFilePath'."
      }
    } else { # Create temp. file in the user's temporary folder.
      if (-not $prevFilePath) { 
        if ($Extension) {
          $script:__cttfFilePath = [IO.Path]::Combine([IO.Path]::GetTempPath(), [IO.Path]::GetRandomFileName()   $Extension)
        } else {
          $script:__cttfFilePath = [IO.Path]::GetTempFilename() 
        }
        Write-Verbose "Creating temp. file: $__cttfFilePath"
      } else {
        Write-Verbose "Reusing temp. file: $__cttfFilePath"      
      }
    }
    if ($NoBOM) { # UTF8 file *without* BOM
      # Note: Out-File, sadly, doesn't support creating UTF8-encoded files 
      #       *without a BOM*, so we must use the .NET framework.
      #       [IO.StreamWriter] by default writes UTF-8 files without a BOM.
      $sw = New-Object IO.StreamWriter $__cttfFilePath
      try {
          . $ScriptBlock | Out-String -Stream | % { $sw.WriteLine($_) }
      } finally { $sw.Close() }
    } else { # UTF8 file *with* BOM
      . $ScriptBlock | Out-File -Encoding utf8 $__cttfFilePath
    }
    return $__cttfFilePath
  }
}

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

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

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

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

1. Самым примитивным способом восстановления репозитория является удаление/переименование его рабочей директории. То есть, вы переименовываете директорию %SystemRoot%System32WbemRepository, к примеру, в Repository.old и ждете. После определенного таймаута сервис определит отсутствие директории репозитория и запустит процедуру восстановления. Но этот простой способ особенно никем не применяется, поскольку не учитывает перекомпиляцию не входящих в автовосстановление (список .mof в реестре) классов и не выполняет перерегистрацию провайдеров.
2. Вне зависимости от того, где и как оно применяется, удаление рабочего WMI-репозитория является достаточно разрушительной операцией, которая может повлечь за собой потерю данных, возникновение ошибок в WMI-приложениях, замедление отклика некоторых операций, и возникновении других, сложнодиагностируемых проблем.
3. Существуют приложения, которые в процессе установки в систему [самостоятельно] напрямую обновляют репозиторий, вообще не используя никаких .mof-файлов. Соответственно, при пересоздании (удалении и создании) репозитория подобные приложения не имеют возможности обновить базу данных и их данные, связанные с WMI, будут удалены (потеряны) вплоть до момента, пока вы не переустановите означенные приложения (в режиме восстановления).
4. Следует помнить, что не все приложения хранят свои WMI-провайдеры (.dll) и .mof-файлы в %SystemRoot%System32wbem. Соответственно, вам нужно будет выявить подобные приложения (поиск по маске *.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%SysWOW64wbem, а на 32-битных системах из %SystemRoot%System32wbem, но оказалось, что (в ОС, начиная с Windows 7) в директории для 64-битной ОС отсутствуют многие .mof файлы, что меня лично настораживает. Рекомендация могла устареть? К тому же, большинство на это забивает и радуется 🙂

Поэтому вы уже поняли, что приведенные тут решения несовершенны, но в реальных боевых условиях не раз помогали избавиться от проблем с WMI (даже удивительно).

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

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

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

Исправление .net framework 3,0 после установки .net framework 3,5 repair .net framework 3.0 after .net framework 3.5 installation

При восстановлении .NET Framework 3,0 после установки .NET Framework 3,5 элементы конфигурации, появившиеся .NET Framework 3,5 в machine.config , удаляются. If you do a repair of .NET Framework 3.0 after you installed .NET Framework 3.5, configuration elements introduced by .

NET Framework 3.5 in machine.config are removed. Однако файл web.config остается неизменным. However, the web.config file remains intact. Чтобы решить эту проблему, восстановите .NET Framework 3,5 после этого через ARP или используйте средство регистрации службы рабочего процесса (WFServicesReg.exe) с /c параметром.

Средство регистрации служб рабочего процесса (WFServicesReg.exe) можно найти по адресу%windir%Microsoft.NETframeworkv3.5 или%WINDIR%Microsoft.NETframework64v3.5. WorkFlow Service Registration Tool (WFServicesReg.exe) can be found at %windir%Microsoft.NETframeworkv3.5 or %windir%Microsoft.NETframework64v3.5

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

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

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

Вне зависимости от версии WMI в системе имеется несколько предопределенных пространств – корневое пространство имён Root, и 4 пространства, располагающихся уровнем ниже: CIMv2, Default, Security и WMI.

Все пространства имен являются производными от КОРНЕВОГО (Root) пространства имен. Пространства имен организуют в себе классы WMI и другие элементы, таким образом их проще представить себе в качестве контейнера или каталога файловой системы. Некоторые пространства имен содержат вложенные пространства имен, и так далее.

Классы объектов WMI распределены иерархически в пространства имен, похожих на используемые в традиционных объектно-ориентированных языках программирования. Одно из существующих в Windows пространств имен назначается пространством по умолчанию, в стандартной поставке им является пространство имен RootCIMV2. Таким образом, при запросах объектов, в которых явно не задано пространство имен, будем выбрано пространство по умолчанию.

Метод 1

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

winmgmt /verifyrepository

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

winmmgmt /salvagerepository

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

winmgmt /verifyrepository

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

net stop winmgmt /ywinmgmt /resetrepository

Метод 2

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

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

Некоторые разделы реестра windows communication foundation невозможно восстановить с помощью операции восстановления msi в .net framework 3.0 some windows communication foundation registry keys are not repaired by performing an msi repair operation on the .net framework 3.0

Если удалить какие-либо разделы реестра из следующего списка: If you delete any of the following registry keys:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelService 3.0.0.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelService 3.0.0.0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelOperation 3.0.0.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelOperation 3.0.0.0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelEndpoint 3.0.0.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesServiceModelEndpoint 3.0.0.0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSMSvcHost 3.0.0.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSMSvcHost 3.0.0.0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSDTC Bridge 3.0.0.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSDTC Bridge 3.0.0.0

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

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

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

Ошибки wmi

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

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

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

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

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

1. Ошибки в log-файлах самих приложений: WBEM_E_NOT_FOUND – 0x80041002.
2. Ошибки отказа при подключении к пространствам имен RootDefault или Rootcimv2;
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 и перекомпиляция mof файлов

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

sc config winmgmt start= disabled

net stop winmgmt

cd %windir%system32wbem

for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s

wmiprvse /regserver

winmgmt /regserver

sc config winmgmt start= auto

net start winmgmt

for /f %%s in ('dir /b *.mof') do mofcomp %%s

for /f %%s in ('dir /b *.mfl') do mofcomp %%s

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

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

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

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

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

Совет. На практике бывают случаи, когда пересоздание хранилища WMI приводит к проблемам со сторонним софтом. Вызван этот эффект тем, что все записи в базе WMI обнуляются (до состояния чистой системы). Такое ПО, вероятно, придется переустанавливать в режиме восстановления.

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

winmgmt /verifyrepository

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

Winmgmt /salvagerepository

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

net stop Winmgmt

net start Winmgmt

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

Winmgmt /resetrepository

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

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

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

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

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

Правильная настройка узла wcf/wf в службах iis после установки .net framework 3.5 configure iis properly for wcf/wf webhost after installing .net framework 3.5

Если при установке .NET Framework 3,5 не удается настроить дополнительные параметры конфигурации IIS, связанные с WCF, в журнал установки заносится ошибка и выполняется продолжение. When .NET Framework 3.5 installation fails to configure additional WCF-related IIS configuration settings, it logs an error in the installation log and continues.

Все попытки запуска приложений WorkflowServices будут неудачными, поскольку отсутствуют обязательные параметры конфигурации. Any attempt to run WorkflowServices applications will fail, since the required configuration settings are missing. Например, не удастся загрузить службы правил или XOML. For example, loading xoml or rules service can fail.

Чтобы решить эту проблему, используйте средство регистрации службы рабочего процесса (WFServicesReg.exe) с /c параметром, чтобы правильно настроить карты сценариев IIS на компьютере. To workaround this problem, use the WorkFlow Service Registration Tool (WFServicesReg.exe) with the /c switch to properly configure IIS script maps on the machine.

Средство регистрации служб рабочего процесса (WFServicesReg.exe) можно найти по адресу%windir%Microsoft.NETframeworkv3.5 или%WINDIR%Microsoft.NETframework64v3.5. WorkFlow Service Registration Tool (WFServicesReg.exe) can be found at %windir%Microsoft.NETframeworkv3.5 or %windir%Microsoft.NETframework64v3.5

Провайдеры 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), реализующей весь функционал провайдера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В системе за всё это отвечает компонент под названием Менеджер объектов CIM (Common Information Model Object Manager, CIMOM), занимающийся обслуживанием взаимодействия управляющих приложений с WMI-провайдерами и управлением хранилищем базы данных WMI (репозиторием).

Традиционно, как и большинство подобного функционала, CIMOM реализован в системе в виде службы, которая в данном конкретном случае носит название Инструментарий управления Windows. Исполняемый модуль, содержащий весь функционал (функции CIMOM)

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

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

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

Устранение неполадок при установке troubleshoot setup issues

В этой статье описывается, как устранять неполадки при установке Windows Communication Foundation (WCF). This article describes how to troubleshoot Windows Communication Foundation (WCF) setup issues.

Язык запросов wmi (wql)

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

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

Тем не менее не все провайдеры управляемого объекта поддерживают WQL, в подобных ситуациях менеджер объектов CIM должен преобразовать запрос к виду, обрабатываемому [конкретным] провайдером. WQL представляет собой специально сконструированные запросы, которые являются подмножеством (подвидом) SQL.

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

Похожее:

Скачать Все официальные темы Windows с сайта Microsoft 28.11.2019 Windows 10 1080P, 2K, 4K, 5K HD wallpapers free download | Wallpaper Flare Сборник кнопок «Пуск» для Windows 7/8 скачать торрент файл бесплатно Скачать Realtek High Definition Audio Drivers 6.0.9151 WHQL с облака