Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I’m currently managing a Citrix-farm system based on Windows Server 2008R2. In the past, I had used a Powershell script to check for running user-processes and restart them if necessary.

I used the tool “tasklist.exe” with additional parameters to check if a defined process is running under the logged-on user. Unfortunately the tasklist.exe had stopped working for a few days now. Restarting it results in an error message:

“Error: Not found” or “Error: invalid class”.

Since the servers are in Germany, I have translated the message from German to English. On the German server, it’s called

“Fehler: Nicht gefunden” and “Fehler: Ungultige Klasse”.

So, I’m not sure if the translation to English is correct. There are no error logs in the event log.

As it is a production system, there have been no changes such as updates and there is no internet connection.

Is it possible that a dll registration is missing? I’ve check with “depends.exe” for anything that might be amiss but I’m not able to identify any difference between a working server and the non-working server.

I’ve also checked if there are any errors when starting “dcomcnfg” but everything is ok.

A fresh copy of tasklist.exe from a working server did not work. The problem isn't related to the exectuable itself.

The hint provided under this link was checked with a non positiv result.

regsvr32 %Windir%\system32\wbem\fastprox.dll

regsvr32 %Windir%\system32\wbem\wbemprox.dll

regsvr32 %Windir%\system32\wbem\wbemsvc.dll

Virus pattern are up-to-date (McAfee VDS 8.8 + ASE 8.8).

Does anybody have any suggestions on how I can get “tasklist.exe” running again? Alternatively, I would like a solution with Powershell commands that would help rebuild the functions of “tasklist.exe” – it’s not an easy task as I’m not the best scripter. 

Thanks in advance for your help, hints or suggestions!


Indeed the problem was related to the WMI. The hint from Ryan Ries to check the WMI with


resulted in a similar error when trying to connect.

In this case I received an error code with which I was able to find the solution at Microsoft TechNet.

The script listed in that page didn´t work for me but the command

“Winmgmt /salvagerepository”


So thank you Ryan for the WMI hint and thank you r.tanner.f for the workaround in case everything else didn’t work.

share|improve this question
up vote 4 down vote accepted

While it may be possible to use something else besides tasklist.exe to get a list of running processes on the system, it worries me that tasklist.exe just all of a sudden stopped working. It's a basic, fundamental process on the system and the fact that it stopped working could be a sign of data corruption or some other problem that could only get worse.

Not trying to find out what caused this, even if you're able to work around it by using Powershell or WMIC or some other executable, is like covering up the "Check Oil" light on your car's dashboard with electrical tape. It doesn't mean the underlying problem is not still there.

Furthermore, it appears that tasklist.exe utilizes WMI to get the information, so if tasklist.exe isn't working, that may indicate a systemic problem with WMI on your machine, and so using other tools that rely on WMI probably won't work either...

Here is how you troubleshoot this. Get Process Monitor from Sysinternals. Capture events on the working machine, and capture events on the non-working machine. Filter on tasklist.exe as you run it. Now put the two trace files side by side, and see where they differ. What events on the working machine are returning SUCCESS where the same events on the non-working machine are returning NAME NOT FOUND or some other non-success code?

Since the error message you got mentioned an invalid class, I bet the events that take place in the registry keys HKCR\CLSID\{GUID}\, \HKLM\Software\Classes, etc., will show some definite differences between the two trace files.

Edit: Also if you wanted to test WMI itself, one method you could use is to run wbemtest. Click Connect..., and use root\cimv2 as the namespace. You should be able to leave everything else blank or default. Then, click the button that says Query, and type select * from win32_process as your query and click Apply. You should get back a bunch of valid process handles and no error messages.

Good luck...

share|improve this answer
Word of caution: I've crashed my XenApp servers using Process Monitor. Make sure to filter what you're capturing... – Tanner Faulkner Aug 16 '13 at 15:33

It's likely going to be easier to replace your use of tasklist.exe with a little PowerShell, than to track down what went wrong tasklist.exe. Look at Ryan Ries' answer though; he makes some good points about why it's important to track this down, and that WMI might be broken and prevent this from working anyway (in which case you have bigger problems). For what it's worth, I like his answer better.

Checking for a process run by the current user is simple enough in PowerShell:

Get-WMIObject win32_process |
Where {$_.ProcessName -eq "foo.exe"} | 
ForEach-Object {$_.GetOwner()} | 
Where  {$_.User -eq [Environment]::Username}

Get-WMIObject obviously gets a WMI object, in this case win32_process. Pipe that in to the Where-Object and filter anything not equal to foo.exe. Then loop through each object and run the GetOwner() method. Finally, filter any username not equal to the current user.

I'm adding a return after the pipes for readability (also valid in a script), but you can pare it down with some aliases too and stick to one line:

gwmi win32_process | ?{$_.ProcessName -eq "smartclient.exe"} | %{$_.GetOwner()} | ?{$_.User -eq [Environment]::UserName}

PowerShell is friendly and doesn't bite. You don't need to be a good scripter to get what you need out of it, so don't shy away from trying to use it.

share|improve this answer
Upvoting your answer because you did offer a workaround, which in the end, if WMI isn't totally broken on his system, the OP might end up going for your answer because he can't or won't fix the actual problem. In either case, I think OP has two decent answers to his question. :) – Ryan Ries Aug 16 '13 at 15:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.