Когда 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.