当 WMI 损坏时，它会以最奇怪的方式失败，某些查询（大多数）会起作用，一些查询会抛出异常，另一些查询会超时，还有一些查询根本不会返回（或返回部分/错误的）结果。
由于我有一项复杂而重要的 WMI 系统监控工作，因此我希望能够在运行脚本之前发现损坏的 WMI 存储库。根据脚本行为确定它很困难（因为 WMI 可能会以多种方式失败），而且人们通常需要花费大量时间才能确定它是系统错误还是 WMI 错误。
我本质上正在寻找一种方法，可以在我的 PowerShell 脚本开始时执行，以预先确定 WMI 是否已损坏。
答案1
微软产品支持服务团队提供了一个专门用于发现和诊断损坏的 WMI 数据库的脚本，WMI 诊断实用程序。
有关如何使用的更多信息，请访问使用 WMIDiag 排除 WMI 故障。
不幸的是，如果您想在开始运行一项工作时运行它，我不太确定它对您有多大用处，它更像是人们倾向于设置定期自动在其资产中运行以报告需要查看的机器的那种东西。
答案2
一种方法是（如果将脚本失败行为设置为“忽略”）将 gwmi 语句分配给一个变量，然后检查该变量的变量。
$connectToWMI = gwmi win32_service -computername [computername]
然后检查变量的状态或值（使用 write-host 查看成功连接和失败时会发生什么）
看起来你也可以设置 Traps 来检查错误，但我没有用过。它类似于以下内容：
trap [Exception] {continue}
答案3
我不知道具体问题的答案，但这有什么关系？您会从脚本中收到失败的通知，然后必须手动修复它。出现此通知是因为脚本失败了。如果您在脚本中添加了额外的代码以首先检查损坏的 WMI，则工作流程仍然会一模一样。
/edit - 好的 - 所以你有不同的、可能未知的方式，如果 WMI 损坏，它可能会失败？而且你要求用一种方法来检查它是否损坏？那你就完蛋了。我会注意到你说
“（之后需要花时间弄清楚是否由于重要的系统原因而失败，或者是否仅仅是由于 WMI 损坏）”
那么，您需要在脚本中使用更好的返回代码，也许还需要更好的功能设计。如果您的脚本没有告诉您失败的原因，请修复它。gWaldo 在下面对陷阱提出了一个很好的建议。此时，我认为您最好重新考虑您正在做的事情，然后花一些时间在 StackOverflow 上。