目前，我正在pipe理基于Windows Server 2008 R2的Citrix服务器场系统。 过去，我使用Powershell脚本检查正在运行的用户进程，并在必要时重新启动它们。
我使用了带有附加参数的工具“tasklist.exe”来检查定义的进程是否在login用户下运行。 不幸的是，tasklist.exe已经停止工作了几天了。 重新启动会导致错误信息：
“错误：未find”或“错误：无效的类”。
由于服务器在德国，我已经把信息从德文翻译成英文。 在德国服务器上，它被称为
“Fehler：Nicht gefunden”和“Fehler：Ungultige Klasse”。
所以，我不确定翻译成英文是否正确。 事件日志中没有错误日志。
由于这是一个生产系统，没有更新，如更新和没有互联网连接。
有没有可能是一个DLL注册丢失？ 我已经检查与“depends.exe”的任何可能是错误的，但我无法识别工作服务器和非工作服务器之间的任何区别。
我也检查了启动“dcomcnfg”时是否有错误，但一切正常。
来自工作服务器的tasklist.exe的全新副本不起作用。 问题与可执行的本身无关。
这个链接提供的提示是用非正式结果检查的。
regsvr32％Windir％\ system32 \ wbem \ fastprox.dll
regsvr32％Windir％\ system32 \ wbem \ wbemprox.dll
regsvr32％Windir％\ system32 \ wbem \ wbemsvc.dll
病毒码是最新的（McAfee VDS 8.8 + ASE 8.8）。
有没有人有任何build议，我怎样才能让“tasklist.exe”再次运行？ 或者，我想用一个Powershell命令的解决scheme来帮助重build“tasklist.exe”的function – 这不是一件容易的事情，因为我不是最好的scripter。
在此先感谢您的帮助，提示或build议！
编辑：
事实上，这个问题与WMI有关。 Ryan Ries的提示来检查WMI
“WBEMTEST”
导致尝试连接时出现类似的错误。
在这种情况下，我收到了一个错误代码，我可以在Microsoft TechNet上find解决scheme。
该页面中列出的脚本对我而言并不适用于我，而是命令
“Winmgmt / salvagerepository”
没有。
所以，感谢Ryan提供的WMI提示，并感谢r.tanner.f提供的解决方法，以防其他情况无法正常工作。
尽pipe可能使用除tasklist.exe之外的其他内容来获取系统上正在运行的进程的列表，但是令我担心tasklist.exe突然停止工作。 这是系统的一个基本的，基本的过程，它停止工作的事实可能是数据损坏或其他问题的迹象，只会变得更糟。
不要试图找出造成这种情况的原因，即使您能够使用Powershell或WMIC或其他可执行文件解决此问题，就像用电子胶带覆盖汽车仪表板上的“Check Oil”指示灯一样。 这并不意味着底层的问题不存在。
此外，tasklist.exe似乎利用WMI来获取信息，因此如果tasklist.exe不工作，这可能表示您的计算机上存在WMI的系统问题，因此使用依赖于WMI的其他工具可能不会工作要么…
这是你如何解决这个问题。 从Sysinternals获取进程监视器。 捕获工作机器上的事件，并捕获非工作机器上的事件。 运行时，在tasklist.exe上筛选。 现在把这两个跟踪文件并排放在一起，看看它们有什么不同。 工作机器上的哪些事件正在返回SUCCESS，其中非工作机器上的相同事件正在返回NAME NOT FOUND或其他一些不成功的代码？
由于您提到的错误消息提到了一个无效的类，我敢打赌，在registry项HKCR\CLSID\{GUID}\ ， \HKLM\Software\Classes等中发生的事件将显示两条迹线之间的一些确定的差异文件。
编辑：另外，如果你想testingWMI本身，你可以使用的一种方法是运行wbemtest 。 单击Connect... ，并使用root\cimv2作为命名空间。 您应该能够保留一切空白或默认。 然后，单击表示Query的button，然后在select * from win32_process键入select * from win32_process作为查询，然后单击Apply 。 你应该得到一堆有效的进程句柄，没有错误信息。
祝你好运…
用一个小小的PowerShellreplace你的tasklist.exe的使用可能会比较容易，而不是跟踪tasklist.exe出了什么问题。 尽pipe如此，请看Ryan Ries的回答。 他提出了一些关于为什么跟踪这个问题非常重要的一些要点，而且WMI可能会被破坏，并且无法正常工作（在这种情况下，您会遇到更大的问题）。 为了什么是值得的，我更喜欢他的答案。
在PowerShell中检查当前用户运行的进程是否足够简单：
Get-WMIObject win32_process | Where {$_.ProcessName -eq "foo.exe"} | ForEach-Object {$_.GetOwner()} | Where {$_.User -eq [Environment]::Username}
Get-WMIObject显然获得一个WMI对象，在这种情况下是win32_process。 将其传入Where-Object并过滤与foo.exe不等的内容。 然后遍历每个对象并运行GetOwner()方法。 最后，过滤不等于当前用户的任何用户名。
为了可读性，我在pipe道之后添加了一个返回值（在脚本中也是有效的），但是也可以用一些别名来减less它们，并坚持一行：
gwmi win32_process | ?{$_.ProcessName -eq "smartclient.exe"} | %{$_.GetOwner()} | ?{$_.User -eq [Environment]::UserName}
PowerShell是友好的，不咬人。 你不需要做一个好的脚本来获得你所需要的东西，所以不要害怕尝试使用它。