Como Sathya mencionó en su pregunta, he tenido experiencias previas con este problema en mi similar portátil de HP, y ahora he confirmado usando el método científico que los picos de la CPU en los portátiles de HP son causados por el HP Wireless Assistant. O, el Asesino de la CPU de HP, como puedo empezar a llamarlo.

Descripción del experimento

• Pregunta : ¿Qué está causando que la CPU de los portátiles de HP se dispare a intervalos frecuentes, específicamente el WmiPrvSE.exe proceso?

• Hipótesis : El Asistente Inalámbrico de HP (HPWA) está causando el problema…

• Método :

• Resultados : El HPWA está causando un uso extremo de la CPU_

• Conclusión : Debería desinstalar HPWA ya que no hace nada útil_

Información de fondo

Cuando conseguí mi portátil HP Pavillion dm4t, me di cuenta de que la CPU frecuentemente se disparaba hasta el 50% de uso, casi cada dos segundos. Esto agotaba la vida de la batería y calentaba el portátil, muy parecido a los síntomas que Sathya ha experimentado. Con sólo mirar el Monitor de Recursos en Windows 7, fui capaz de ver que el proceso WmiPrvSE.exe estaba en falla.

Una rápida búsqueda en Google confirmó mi suposición de que este era el Instrumento de Administración de Windows (WMI) proceso host. En resumen, WMI puede ser usado para consultar información del sistema, como el uso del procesador, procesos en ejecución, quién está conectado, y todo tipo de información. El proceso anfitrión de WMI ejecuta consultas WMI para cualquier otro proceso que las haga, así que WmiPrvSE.exe no fue el culpable en sí mismo, fue simplemente un intermediario.

Para buscar qué proceso específico estaba causando este problema, utilicé Explorador de Procesos de Systinternals . Encontré qué instancia del proceso WmiPrvSE.exe estaba usando una gran cantidad de CPU, y hice clic en él para abrir información detallada.

Desafortunadamente, no pude ver ninguna manera de averiguar qué proceso estaba haciendo todas las consultas, pero como había aislado esto como la fuente de los picos de CPU, y sabía que era un servicio, fui al gerente de servicios para ver qué servicios dependían de WMI, pensando que eso podría llevarme a otra pista.

Me imaginé que no sería un servicio de Windows incorporado el que causara el problema, así que eliminando esos, decidí trabajar en la lista y tratar de deshabilitar cada servicio, y ver si el problema persistía. Justo en la parte superior de la lista estaba el Servicio de Asistente Inalámbrico de HP. Volví al menú de servicios, y deshabilité ese servicio. Mirando hacia atrás en el administrador de tareas, vi que el uso de la CPU se había reducido a casi nada. Volví a activar el servicio HPWA. El uso de la CPU se disparó de nuevo. Ahora tenía suficientes datos para formar mi teoría. Desinstalé el servicio HPWA, y nunca más tuve el problema.

Verificando la Hipótesis

Varios meses después, Sathya hace esta pregunta. Decidí probar de una vez por todas que era culpa de la HPWA. Reinstalé el HP Wireless Assistant, que no había instalado en meses. De inmediato, el uso del procesador se disparó. Entonces hice el experimento descrito anteriormente.

Primero, aislé el proceso responsable del servicio de HPWA en el Monitor de Recursos. HPWA_Service.exe y HPWA_Main.exe son los dos. Así es como se veía el uso de la CPU con ambos procesos funcionando:

Luego, suspendí ambos procesos. El uso de la CPU bajó inmediatamente; así es como se veía después de unos momentos para que el uso previo de la CPU en el gráfico se despejara:

Habilité los procesos de nuevo para ver si el uso volvía a subir. Lo hizo:

Suspender los procesos de nuevo resultó en que el uso de la CPU volviera a bajar:

Probé esto para una iteración más, y en la tercera prueba, volvió a suceder exactamente lo mismo. Consideré esta evidencia suficiente para demostrar que el HP Wireless Assistant estaba causando el problema, y subsecuentemente deshabilitó el servicio, y ahora lo desinstalará.

Todo lo que parece hacer el HPWA es informar al usuario cuando su inalámbrico se enciende o se apaga, y engulle la CPU. No hay nada que pueda hacer con él que no pueda hacer con las herramientas de administración de la red inalámbrica incorporadas, así que le aconsejo que si tiene este software instalado, lo elimine.

Nota: Al menos una persona ha informado que la desinstalación de HPWA provocó que su interruptor inalámbrico en el teclado dejara de funcionar. En mi portátil, siguió funcionando bien después de desinstalar HPWA, pero en caso de que el tuyo deje de funcionar, siempre puedes deshabilitar la tarjeta inalámbrica desde dentro de Windows. Presione

De acuerdo con una discusión en los foros de soporte de HP, el problema se ha solucionado en versiones más recientes del HP Wireless Assistant. Si tu portátil necesita que HPWA use el wifi on/off puede descargar la última versión desde el sitio web de controladores de HP, y probablemente ya no tendrá este problema. Sin embargo, si no lo necesitas para el botón de encendido/apagado de la wifi, parece que no hay ningún valor añadido por tener este software instalado.

Solución de problemas

1. Descargue ProcDump de Microsoft Sysinternals.

2. Deje que haga un volcado una vez que el WmiPrvSE.EXE llegue al 25% durante 1 segundo:

3. Analice su(s) vertedero(s) en línea y opcionalmente compártalo(s) en SpeedyShare .

4. El rastro de la pila que se muestra debería incluir el procedimiento que causa esto.

Tal vez busque en Google algunos de los procedimientos superiores de la pila para tener una mejor idea de lo que hacen. Si no ayudan puede necesitar un análisis más avanzado. Vea mi siguiente sección:

• *

1. Descargue la configuración de Herramientas de Análisis de Rendimiento de Windows para su versión de Windows.
2. Instale el software en su sistema.

3. Abra un símbolo del sistema como administrador , y copie y pegue el siguiente comando:

4. Presiona ENTER una vez para iniciar el comando, ahora tendrás que esperar hasta que el pico se haya producido.

5. Justo después del pico vas a la consola y presionas ENTER.

6. Después de esperar un tiempo se producirá un archivo de registro myTrace.etl en su carpeta de usuario.

7. Ejecute el siguiente comando para mostrar el archivo y analizarlo WinDBG Símbolos requerido):

Si quiere que lo analice:

1. Comprime myTrace.etl desde tu carpeta de usuario a un archivo zip.
2. Comparte el archivo zip comprimido en SpeedyShare .
3. Comparte el enlace aquí, haré un intento de encontrar y mostrarte la causa de tu problema.

Como WmiPrvSE. EXE es un host para ejecutar consultas WMI contra la tienda CAPI, puede que no puedas encontrar la causa incluso con XPerf debido a IPC , otra solución que acabo de encontrar sería habilitar el registro de WMI y comprobar los registros como se describe aquí , el ClientProcessId sería el PID del Proceso que hizo la consulta WMI. Este PID puede ser rastreado hasta el proceso añadiendo una columna PID al Administrador de Tareas o al Process Explorer , o con tasklist /FI "PID eq X" donde X es el PID que encontraste…

Análisis de Dump 1 : Las líneas 94-115 indican una Remote Procedure Call .
Análisis de Vertedero 2 : Las líneas 84-105 indican un Remote Procedure Call .

En el Kernel, se inicia un nuevo hilo para manejar un talón de Remote Procedure Call , que en esencia es una solicitud de consulta que el Proveedor de WMI ejecutará y responderá. Esto resulta en una alta actividad de la CPU debido a la lectura de la información del Registro y/o del Rendimiento.

Como un volcado es una captura de un solo momento no podrás ver qué proceso realizó el RPC. Por lo tanto, necesitas un programa que rastree como XPerf para ver el hilo anterior que estaría haciendo el RPC.

O, si habilitas la información de estado de la RPC , puedes usar rpcdbg para ver quién inició la llamada.

Ejemplo:

0:000> bp rpcrt4!RpcServerUseProtseqEpA
0:000> g
Breakpoint 0 hit
eax=00452000 ebx=7ffd5000 ecx=00452008 edx=00000014 esi=00d5f55c edi=7c911970
eip=77e97a0b esp=0012ff3c ebp=0012ff6c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
RPCRT4!RpcServerUseProtseqEpA:
77e97a0b 8bff mov edi,edi
0:000> kb
ChildEBP RetAddr Args to Child
0012ff38 00401046 00452000 00000014 00452008 RPCRT4!RpcServerUseProtseqEpA
0012ff6c 00401e37 00000001 003330a0 00333120 hellos!main+0x46 [e:\projects\hello\hellos.c @ 21]

El ejemplo anterior establece un punto de interrupción en la RPC, para que puedas ver quién la ejecuta en la segunda línea de la pila. Pero bueno, es poco probable que establecer un punto de ruptura en la primera llamada (por favor, tened en cuenta que esto es depuración en vivo) os ayude a ver quién llama al proveedor de WMI cada vez…

Hay mucha más información en ese artículo sobre Información de estado de RPC que podría ayudar, pero no es para los pusilánimes como nosotros el pasar por todo eso cuando podríamos usar XPerf en su lugar. :-)

Como ahora sabemos sobre el funcionamiento interno de cómo funciona el RPC, también podríamos usar Monitor API :

1. Descargue, instale e inicie el Monitor API. ( dos veces si tienes 64 bit: una vez x86, una vez x64)
2. Ir a Archivo –> Ejecutar como administrador

3. Poner el Filtro de Captura de API en el módulo Rpcrt4.dll.

4. Similar al punto de interrupción, queremos saber quién llama a las funciones de RpcServerUseProtSeq:

5. Enganchar cada Proceso en ejecución excepto aquellos con un PID bajo (para evitar caídas). Ideal, no quieres enganchar dwm.exe/winlogon.exe o más bajo. También podrías probar procesos individuales y desengancharlos más tarde de la ventana de Procesos enganchados…

6. Si todo va bien, el Proceso Enganchado que hace la llamada RPC contendrá hilos. Y al hacer clic en estos hilos, deberías ver un montón de llamadas. Si lo haces, ¡has encontrado el proceso que causa el problema!

Solución

Mantener tu ordenador actualizado es importante, instalar HPWA 4.0.10.0 resuelve esto! ;-)

La entrada del blog de Microsoft ¿Es WMIprvse un verdadero villano? _ muestra cómo encontrar qué proceso es responsable de la CPU que WmiPrvSE.exe está usando.

El método utiliza la opción del visor de eventos de “Mostrar registros analíticos y de depuración” para rastrear toda la actividad de WMI, consiguiendo así la identificación del proceso culpable.

Sólo agregando esto para cualquier otra persona en el mismo barco, esta página está en todo Google. Tuve el mismo problema con el WmiProvderHost aumentando la CPU hasta un 50% y agotando la batería de mi Lenovo Yoga2 Pro en Windows 8.1.

Siguiendo algunos de los excelentes consejos de la investigación anterior, descubrí que el problema para mí era en realidad GoPro Studio (software de edición de vídeo gratuito que viene con las cámaras GoPro). Instala un servicio de monitoreo que espera a que conectes tu cámara y para mí este fue el culpable.

Para depurarlo, usa xperf del Windows Performance toolkit y ejecuta este archivo cmd:

xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DISPATCHER -stackwalk profile -BufferSize 1024 -MaxFile 256 -FileMode Circular -f Kernel.etl
xperf -start WMILogger -on Microsoft-Windows-WMI-Activity::0xff -BufferSize 1024 -f WMI.etl

echo Please capture about 30s of the WMI activity.

pause

xperf -stop
xperf -stop WMILogger
xperf -merge WMI.etl kernel.etl WMItracing.etl

del WMI.etl
del kernel.etl

Abre el WMItracing.etl generado en WPA.exe y grag & suelta el gráfico de “Eventos genéricos” del lado izquierdo al panel de análisis.

Ahora filtra a Microsoft-Windows-WMI-Activity eventos solamente, y busca las operaciones WMI y el ClientProcessId.

En mi ejemplo este CLientProcessId pertenece a una herramienta llamada Veeam ONE Monitor Server. Deteniéndolo, arreglado el problema de uso de CPU.

Y el segundo ejemplo se muestra aquí:

HEre se ven llamadas recurrentes de un Proceso con PID de 1924 que pertenece al servicio Intel ProSet Monitoring.

Aquí el uso de CPU también se muestra en las llamadas de muestreo de CPU:

Entonces, la herramienta Intel hace consultas de notificación WMI demasiado a menudo y esto causa los problemas. Deteniéndolo, arreglado el problema.

¿Has probado a ver si es un virus? A algunos virus les gusta desfilar por los servicios de Windows de esa manera. Asegúrate de que el proceso WmiPrvSE.exe se encuentra en el directorio c:\windows\system32\wbem. Si no es así, es posible que quieras ejecutar programas generales de detección de spyware. Si no es spyware, es posible que sea otro servicio el que lo llame. Sé que tengo unos cuantos gadgets rápidos ejecutándose en mi equipo e, irónicamente, el gadget del monitor de rendimiento a veces hace que mi CPU se dispare un poco. Además, podría ser otro servicio que presiona ese gas de vez en cuando. Por ejemplo, el bloatware de HP, Dell, etc.

Aparte de eso, la otra respuesta de TomWij parece bastante buena para solucionar los problemas.