Erroneous Tasklist.exe

Solution 1:

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...

Solution 2:

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.