检测损坏的WMI

Question

当WMI损坏时，它将以最奇怪的方式失败，某些查询(其中大多数)将工作，一些查询将抛出异常，另一些查询将超时，少数查询只返回不(或部分/错误)结果。

由于我有一个复杂的重要的WMI系统监视作业，所以我希望能够在运行脚本之前发现一个损坏的WMI存储库。从脚本行为中确定它很困难(因为WMI可能失败的方式很多)，而且人们通常会花费大量的时间来判断它是系统错误还是WMI错误。

我基本上是在寻找一种方法，tI可以在PowerShell脚本的开头执行，以预先确定WMI是否已损坏。

Answer 1

微软的产品支持服务团队()提供了一个脚本，专门用于识别和诊断损坏的WMI数据库，即WMI诊断实用程序。

更多关于如何在用WMIDiag解决WMI问题使用它的信息。

不幸的是，我不太确定这对你有多大的帮助--如果你想在一开始就运行这个任务，这更像是人们经常会自动运行的那种东西，用来报告需要查看的机器的情况。

Answer 2

一种方法(如果将脚本失败行为设置为“忽略”)是将gwmi语句赋值给变量，然后检查该变量的变量。

$connectToWMI = gwmi win32_service -computername [computername]

然后检查变量的状态或值(使用写主机查看成功连接和失败的预期结果)。

它看起来也可以为错误检查设置陷阱，但我没有使用它。就像这样：

trap [Exception] {continue}

Answer 3

我没有具体问题的答案，但这有什么关系呢？您从脚本中得到通知它失败了，然后您必须手动修复它。此通知之所以发生，是因为脚本失败。如果您在脚本中添加了额外的代码，以便首先检查损坏的WMI，则工作流仍将完全相同。

/edit -好的-那么你有不同的，潜在的未知的方式，WMI可能会失败如果它被破坏了？你想要一个方法来检查它是否被破坏了？那你就是索尔了。我会注意到你说

“(而后记则花时间找出它是因为重要的系统原因而失败，还是仅仅是因为WMI损坏)

那么，您需要更好的返回代码，或者在脚本中进行更好的功能设计。如果您的脚本没有告诉您失败的原因，请修复它。gWaldo对诱捕有一个很好的建议。在这一点上，我认为您最好重新考虑您正在做的事情，然后花一些时间在StackOverflow上。