Erroneous Tasklist.exe

Question

Atualmente, estou gerenciando um sistema de farm do Citrix com base no Windows Server 2008R2. No passado, eu tinha usado um script Powershell para verificar a execução de processos de usuário e reiniciá-los, se necessário.

Eu usei a ferramenta “tasklist.exe” com parâmetros adicionais para verificar se um processo definido está sendo executado sob o usuário conectado. Infelizmente, o tasklist.exe parou de funcionar por alguns dias agora. Reiniciar resulta em uma mensagem de erro:

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

Como os servidores estão na Alemanha, traduzi a mensagem do alemão para o inglês. No servidor alemão, é chamado

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

Então, não tenho certeza se a tradução para o inglês está correta. Não há logs de erros no log de eventos.

Como é um sistema de produção, não houve alterações como atualizações e não há conexão com a Internet.

É possível que um registro de dll esteja faltando? Verifico com "depends.exe" para qualquer coisa que possa estar errada, mas não consigo identificar nenhuma diferença entre um servidor em funcionamento e o servidor não funcional.

Também verifiquei se há algum erro ao iniciar o "dcomcnfg", mas está tudo bem.

Uma nova cópia do tasklist.exe de um servidor em funcionamento não funcionou. O problema não está relacionado com o exectuável em si.

A sugestão fornecida em este link foi verificada com um não resultado positiv.

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

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

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

O padrão de vírus está atualizado (McAfee VDS 8.8 + ASE 8.8).

Alguém tem alguma sugestão sobre como posso obter o "tasklist.exe" em execução novamente? Como alternativa, gostaria de uma solução com comandos do Powershell que ajudasse a reconstruir as funções de “tasklist.exe” - não é uma tarefa fácil, pois não sou o melhor criador de scripts. 

Agradecemos antecipadamente por sua ajuda, sugestões ou sugestões!

Editar:

Na verdade, o problema estava relacionado ao WMI. A dica de Ryan Ries para verificar o WMI com

“wbemtest”

resultou em um erro semelhante ao tentar se conectar.

Neste caso, recebi um código de erro com o qual consegui encontrar a solução em Microsoft TechNet .

O script listado nessa página não funcionou para mim, mas o comando

“Winmgmt /salvagerepository”

fez.

Então, obrigado Ryan pela dica do WMI e obrigado r.tanner.f pela solução alternativa caso todo o resto não funcione.

    

Answer 1

Embora seja possível usar algo além do tasklist.exe para obter uma lista de processos em execução no sistema, me preocupa que o tasklist.exe pare de funcionar de repente. É um processo básico e fundamental no sistema e o fato de que ele parou de funcionar pode ser um sinal de corrupção de dados ou algum outro problema que só poderia piorar.

Não tentar descobrir o que causou isso, mesmo que você consiga contorná-lo usando o Powershell, WMIC ou algum outro executável, é como acobertar a luz "Check Oil" no painel do seu carro com fita isolante. Isso não significa que o problema subjacente ainda não existe.

Além disso, parece que tasklist.exe utiliza o WMI para obter as informações, portanto, se tasklist.exe não estiver funcionando, isso pode indicar um problema sistêmico com o WMI em sua máquina e, assim, usar outras ferramentas que dependem do WMI provavelmente não vai funcionar também ...

Veja como você soluciona isso. Obtenha o Process Monitor da Sysinternals. Capture eventos na máquina em funcionamento e capture eventos na máquina que não funciona. Filtrar no tasklist.exe à medida que você o executa. Agora, coloque os dois arquivos de rastreamento lado a lado e veja onde eles diferem. Quais eventos na máquina em funcionamento estão retornando SUCESSO onde os mesmos eventos na máquina que não está funcionando estão retornando NOME NÃO ENCONTRADO ou algum outro código que não seja de sucesso?

Desde a mensagem de erro que você mencionou uma classe inválida, aposto que os eventos que acontecem nas chaves de registro HKCR\CLSID\{GUID}\ , \HKLM\Software\Classes , etc., mostrarão algumas diferenças definidas entre os dois arquivos de rastreamento.

Editar: Além disso, se você quiser testar o próprio WMI, um método que você pode usar é executar wbemtest . Clique em Connect... e use root\cimv2 como o namespace. Você deve poder deixar todo o resto em branco ou padrão. Em seguida, clique no botão que diz Query e digite select * from win32_process como sua consulta e clique em Apply . Você deve recuperar um monte de identificadores de processo válidos e nenhuma mensagem de erro.

Boa sorte ...

    

Answer 2

É provável que seja mais fácil substituir o uso de tasklist.exe por um pequeno PowerShell do que rastrear o que deu errado, tasklist.exe. Olhe a resposta de Ryan Ries embora; Ele faz alguns pontos positivos sobre por que é importante rastrear isso, e que o WMI pode ser quebrado e evitar que isso funcione de qualquer maneira (nesse caso, você tem problemas maiores). Por que vale a pena, eu gosto mais da resposta dele.

A verificação de um processo executado pelo usuário atual é bastante simples no PowerShell:

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

Get-WMIObject obviamente obtém um objeto WMI, neste caso win32_process. Canalize isso para Where-Object e filtre qualquer coisa diferente de foo.exe. Em seguida, percorra cada objeto e execute o método GetOwner() . Por fim, filtre qualquer nome de usuário que não seja igual ao usuário atual.

Estou adicionando um retorno após os canais para legibilidade (também válido em um script), mas você também pode reduzi-lo com alguns aliases e manter uma linha:

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

O PowerShell é amigável e não morde. Você não precisa ser um bom roteirista para obter o que precisa, então não se preocupe em tentar usá-lo.