6 votos

Errónea Tasklist.exe

Actualmente estoy gestionando una Citrix-sistema de explotación basado en Windows Server 2008R2. En el pasado, había utilizado un script de Powershell para comprobar de usuario de ejecución de procesos y reinicie si es necesario.

He utilizado la herramienta "tasklist.exe" con parámetros adicionales para comprobar si un proceso definido se ejecuta bajo el usuario que ha iniciado sesión. Por desgracia, el tasklist.exe había dejado de trabajar durante un par de días ahora. El reinicio se produce un mensaje de error:

"Error: No se ha encontrado" o "Error: clase no válida".

Ya que los servidores están en Alemania, he traducido el mensaje del alemán al inglés. En el servidor alemán, se llama

"Fehler: Nicht gefunden" y "Fehler: Ungultige Klasse".

Así que, no estoy seguro de si la traducción al inglés es correcta. No hay registros de errores en el registro de sucesos.

Como es un sistema de producción, no se han producido cambios tales como actualizaciones y no hay ninguna conexión a internet.

Es posible que un registro dll que falta? He de verificación con "depends.exe" para cualquier cosa que pueda ir mal, pero no soy capaz de identificar cualquier diferencia entre un servidor de trabajo y el servidor.

También he comprobado si hay algún error al iniciar "dcomcnfg" pero todo está bien.

Una copia nueva de tasklist.exe a partir de un trabajo de servidor no funciona. El problema no está relacionado con el exectuable sí mismo.

La sugerencia proporcionados en virtud de este vínculo se comprobó que no tiene un resultado positivo.

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

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

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

De patrones de Virus está actualizada (McAfee VDS 8.8 + ASE 8.8).

¿Alguien tiene alguna sugerencia sobre cómo puedo conseguir "tasklist.exe" a correr de nuevo? Como alternativa, me gustaría una solución con los comandos de Powershell que podría ayudar a reconstruir las funciones de "tasklist.exe" – no es una tarea fácil, ya que no soy el mejor scripter. 

Gracias de antemano por su ayuda, consejos o sugerencias!


Editar:

De hecho, el problema estaba relacionado con la WMI. La sugerencia de Ryan Ries para comprobar la WMI con

"wbemtest"

resultó en un error similar cuando se intenta conectar.

En este caso he recibido un código de error con el que yo era capaz de encontrar la solución en Microsoft TechNet.

La secuencia de comandos listados en la página no funciona para mí, pero el comando

"Winmgmt /salvagerepository"

hicimos.

Así que gracias a Ryan para el WMI sugerencia y gracias r.tanner.f para la solución en caso de que todo lo demás no funciona.

4voto

Ryan Ries Puntos 33449

Si bien es posible utilizar algo más además de tasklist.exe para obtener una lista de procesos en ejecución en el sistema, me preocupa que tasklist.exe sólo, de repente dejó de funcionar. Es un básico, un proceso fundamental en el sistema y el hecho de que dejó de trabajar podría ser un signo de corrupción de datos o algún otro problema que podría llegar a ser peor.

No tratando de averiguar qué causó esto, incluso si usted es capaz de trabajar alrededor de ella mediante el uso de Powershell o WMIC o algún otro ejecutable, es como el encubrimiento de la "Verificación de Petróleo" luz en el salpicadero de su automóvil con cinta aislante. Esto no significa que el problema de fondo no es todavía allí.

Además, parece que tasklist.exe utiliza WMI para obtener la información, por lo que si tasklist.exe no funciona, que puede indicar un problema sistémico con WMI en el equipo, y para el uso de otras herramientas que se basan en WMI, probablemente, no funciona bien...

Aquí es cómo solucionar esto. Obtener Process Monitor de Sysinternals. La captura de eventos en el equipo de trabajo, y la captura de eventos en el no-trabajo de la máquina. Filtro en tasklist.exe como se ejecuta. Ahora poner los dos archivos de seguimiento al lado del otro, y ver donde se diferencian. ¿Qué eventos en la máquina de trabajo están volviendo a tener ÉXITO en el mismo de los acontecimientos en el no-trabajo de la máquina están regresando NO se ENCUENTRA el NOMBRE o cualquier otro que no sea código de éxito?

Desde el mensaje de error que se menciona una clase no válida, apuesto a que los eventos que tienen lugar en las claves del registro HKCR\CLSID\{GUID}\, \HKLM\Software\Classes, etc., se muestran algunas claras diferencias entre los dos archivos de seguimiento.

Edit: También si quería probar WMI sí mismo, un método que se podría utilizar es ejecutar wbemtest. Haga clic en Connect..., y el uso de root\cimv2 como el espacio de nombres. Usted debe ser capaz de dejar todo lo demás en blanco o por defecto. A continuación, haga clic en el botón que dice" Query, y el tipo select * from win32_process como la consulta y haga clic en Apply. Usted debe obtener un montón de válido identificadores de proceso y no hay mensajes de error.

Buena suerte...

3voto

nilesh Puntos 405

Es probable que va a ser más fácil de reemplazar el uso de tasklist.exe con un poco de PowerShell, que para seguir la pista de lo que salió mal tasklist.exe. Mirar a Ryan Ries' respuesta; hace algunos buenos puntos acerca de por qué es importante el seguimiento de este, y que WMI puede ser roto y evitar que esto de trabajar de todos modos (en cuyo caso usted tiene problemas más grandes). Para lo que vale, me gusta su respuesta mejor.

La comprobación de un proceso de ejecución por el usuario actual es bastante simple en PowerShell:

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

Get-WMIObject obviamente obtiene un objeto de WMI, en este caso win32_process. La tubería que en la Where-Object y el filtro no es igual a nada foo.exe. Entonces el bucle a través de cada objeto y ejecutar el GetOwner() método. Finalmente, el filtro de cualquier nombre de usuario no es igual para el usuario actual.

Voy a agregar un retorno después de las tuberías para mejorar la legibilidad (válido también en una secuencia de comandos), pero se puede recortar con algunos alias demasiado y se adhieren a una línea:

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

PowerShell es amable y no muerden. Usted no necesita ser un buen scripter para obtener lo que necesita de ella, para no alejarse de intentar utilizarla.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: