Назад | Перейти на главную страницу

Обнаружить поврежденный WMI

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

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

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

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

Подробнее о том, как это использовать, см. На Устранение неполадок WMI с помощью WMIDiag.

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

Один из способов сделать это (если вы установите для поведения отказа сценария значение «игнорировать») было бы назначить оператор gwmi переменной, а затем проверить переменную этой переменной.

$connectToWMI = gwmi win32_service -computername [computername]

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

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

trap [Exception] {continue}

У меня нет ответа на конкретный вопрос, но почему это важно? Вы получаете уведомление от вашего скрипта о том, что он не удался, и вам нужно вручную исправить это. Это уведомление происходит из-за сбоя сценария. Если вы добавили в скрипт дополнительный код для первой проверки поврежденного WMI, рабочий процесс все равно будет точно так же.

/ edit - ОК - значит, у вас есть разные, потенциально неизвестные способы отказа WMI, если он поврежден? И вы просите какой-то единственный способ проверить, не поврежден ли он? Тогда ты СОЛ. Я замечу, что ты говоришь

"(и в послесловиях тратится время на выяснение, отказал ли он по важным системным причинам или это просто из-за поврежденного WMI)"

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