Solución de problemas

Question 1

Como Sathya mencionó en su pregunta, tuve experiencia previa con este problema en mi computadora portátil HP similar, y ahora he confirmado utilizando el método científico que los picos de CPU en las computadoras portátiles HP son causados por el Asistente inalámbrico HP. O HP CPU Assassin, como puedo empezar a llamarlo.

Descripción general del experimento

Pregunta:¿Qué está causando que la CPU de las computadoras portátiles HP aumente a intervalos frecuentes, específicamente el WmiPrvSE.exe ¿proceso?
Hipótesis:El Asistente inalámbrico HP (HPWA) está causando el problema
Método:
1. Vea si el problema comienza a ocurrir cuando se instala HPWA.
2. Vea si la CPU deja de aumentar y el WmiPrvSE.exeproceso deja de usar >20% de CPU cuando se suspende el proceso HPWA.
3. Vea si la CPU comienza a aumentar nuevamente cuando se vuelve a habilitar el proceso HPWA
4. Repita los pasos 2 y 3 para varias pruebas para garantizar resultados precisos.
Resultados:HPWA está provocando un uso extremo de la CPU
Conclusión:Deberías desinstalar HPWA ya que no hace nada útil.

Información de contexto

Cuando compré mi computadora portátil HP Pavillion dm4t, noté que el uso de la CPU con frecuencia alcanzaba hasta el 50%, casi cada dos segundos. Esto agotaba la duración de la batería y calentaba la computadora portátil; Los mismos síntomas que Sathya ha experimentado. Con solo mirar el Monitor de recursos en Windows 7, pude ver que el proceso WmiPrvSE.exetenía fallas.

CPU nom nom

Una búsqueda rápida en Google confirmó mi suposición de que este era elInstrumentación de Administración Windows(WMI) proceso de host. En resumen, WMI se puede utilizar para consultar información del sistema, como el uso del procesador, los procesos en ejecución, quién ha iniciado sesión y todo tipo de información. El proceso host WMI ejecuta consultas WMI para cualquier otro proceso que las realice, por lo que WmiPrvSE.exeno fue el culpable, fue simplemente un intermediario.

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

explorador de procesos

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

servicios nom nom

Pensé que no sería un servicio integrado de Windows el que causaba el problema, así que eliminándolos, decidí trabajar en la lista e intentar deshabilitar cada servicio y ver si el problema persistía. Justo en la parte superior de la lista estaba el servicio HP Wireless Assistant. Regresé al menú de servicios y desactivé ese servicio. Mirando hacia atrás en el administrador de tareas, vi que el uso de la CPU se había reducido casi a nada. Vuelvo a activar el servicio HPWA. El uso de la CPU se disparó nuevamente. Ahora tenía suficientes datos para formar mi teoría. Desinstalé el servicio HPWA y nunca volví a tener el problema.

Verificando la hipótesis

Varios meses después, Sathya hace esta pregunta. Decidí demostrar de una vez por todas que esto era culpa de HPWA. Reinstalé el Asistente inalámbrico de HP, que no había instalado en meses. De inmediato, el uso del procesador se disparó. Luego realicé el experimento descrito anteriormente.

Primero, aislé el proceso responsable del servicio HPWA en Resource Monitor. HPWA_Service.exey HPWA_Main.exeson los dos. Así es como se veía el uso de la CPU con ambos procesados en ejecución:

administrador de tareas con hpwa ejecutándose

Entonces suspendí ambos procesos. El uso de la CPU disminuyó inmediatamente; Así es como se veía después de unos momentos para que se borrara el uso anterior de la CPU en el gráfico:

administrador de tareas sin hpwa ejecutándose

Habilité los procesos nuevamente para ver si el uso volvía a aumentar. Lo hizo:

el administrador de tareas acaba de habilitar hpwa
^{El primer pico cuando habilito HPWA}

administrador de tareas después de habilitar hpwa
^{Un poco después de habilitar HPWA}

La suspensión de los procesos nuevamente provocó que el uso de la CPU volviera a disminuir:

menor uso de CPU después de deshabilitar hpwa

Probé esto durante una iteración más y, en la tercera prueba, volvió a suceder exactamente lo mismo. Consideré que esta evidencia era suficiente para demostrar que el Asistente inalámbrico de HP estaba causando el problema y posteriormente desactivé el servicio y ahora lo desinstalaré.

Todo lo que HPWA parece hacer es informar al usuario cuando su conexión inalámbrica está encendida o apagada y devorar la CPU. No hay nada que pueda hacer con él que no pueda hacer con las herramientas de administración inalámbrica integradas, por lo que le recomendaría que si tiene este software instalado, lo elimine.

Nota:Al menos una persona informó que la desinstalación de HPWA provocó que el interruptor inalámbrico del teclado dejara de funcionar. En mi computadora portátil, siguió funcionando bien después de desinstalar HPWA, pero en caso de que la tuya deje de funcionar, siempre puedes desactivar la tarjeta inalámbrica desde Windows. Presione + xpara abrir el Centro de movilidad de Windows, luego haga clic en el Turn Wireless Offbotón.

centro de movilidad windows

De acuerdo auna discusiónEn los foros de soporte de HP, el problema se solucionó en versiones más recientes del Asistente inalámbrico de HP. Si su computadora portátil necesita HPWA para usar el botón de encendido/apagado de wifi, 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 necesita para el botón de encendido/apagado de wifi, parece que todavía no hay ningún valor añadido al tener este software instalado.

Answer

Como Sathya mencionó en su pregunta, tuve experiencia previa con este problema en mi computadora portátil HP similar, y ahora he confirmado utilizando el método científico que los picos de CPU en las computadoras portátiles HP son causados por el Asistente inalámbrico HP. O HP CPU Assassin, como puedo empezar a llamarlo.

Descripción general del experimento

Pregunta:¿Qué está causando que la CPU de las computadoras portátiles HP aumente a intervalos frecuentes, específicamente el WmiPrvSE.exe ¿proceso?
Hipótesis:El Asistente inalámbrico HP (HPWA) está causando el problema
Método:
1. Vea si el problema comienza a ocurrir cuando se instala HPWA.
2. Vea si la CPU deja de aumentar y el WmiPrvSE.exeproceso deja de usar >20% de CPU cuando se suspende el proceso HPWA.
3. Vea si la CPU comienza a aumentar nuevamente cuando se vuelve a habilitar el proceso HPWA
4. Repita los pasos 2 y 3 para varias pruebas para garantizar resultados precisos.
Resultados:HPWA está provocando un uso extremo de la CPU
Conclusión:Deberías desinstalar HPWA ya que no hace nada útil.

Información de contexto

Cuando compré mi computadora portátil HP Pavillion dm4t, noté que el uso de la CPU con frecuencia alcanzaba hasta el 50%, casi cada dos segundos. Esto agotaba la duración de la batería y calentaba la computadora portátil; Los mismos síntomas que Sathya ha experimentado. Con solo mirar el Monitor de recursos en Windows 7, pude ver que el proceso WmiPrvSE.exetenía fallas.

CPU nom nom

Una búsqueda rápida en Google confirmó mi suposición de que este era elInstrumentación de Administración Windows(WMI) proceso de host. En resumen, WMI se puede utilizar para consultar información del sistema, como el uso del procesador, los procesos en ejecución, quién ha iniciado sesión y todo tipo de información. El proceso host WMI ejecuta consultas WMI para cualquier otro proceso que las realice, por lo que WmiPrvSE.exeno fue el culpable, fue simplemente un intermediario.

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

explorador de procesos

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

servicios nom nom

Pensé que no sería un servicio integrado de Windows el que causaba el problema, así que eliminándolos, decidí trabajar en la lista e intentar deshabilitar cada servicio y ver si el problema persistía. Justo en la parte superior de la lista estaba el servicio HP Wireless Assistant. Regresé al menú de servicios y desactivé ese servicio. Mirando hacia atrás en el administrador de tareas, vi que el uso de la CPU se había reducido casi a nada. Vuelvo a activar el servicio HPWA. El uso de la CPU se disparó nuevamente. Ahora tenía suficientes datos para formar mi teoría. Desinstalé el servicio HPWA y nunca volví a tener el problema.

Verificando la hipótesis

Varios meses después, Sathya hace esta pregunta. Decidí demostrar de una vez por todas que esto era culpa de HPWA. Reinstalé el Asistente inalámbrico de HP, que no había instalado en meses. De inmediato, el uso del procesador se disparó. Luego realicé el experimento descrito anteriormente.

Primero, aislé el proceso responsable del servicio HPWA en Resource Monitor. HPWA_Service.exey HPWA_Main.exeson los dos. Así es como se veía el uso de la CPU con ambos procesados en ejecución:

administrador de tareas con hpwa ejecutándose

Entonces suspendí ambos procesos. El uso de la CPU disminuyó inmediatamente; Así es como se veía después de unos momentos para que se borrara el uso anterior de la CPU en el gráfico:

administrador de tareas sin hpwa ejecutándose

Habilité los procesos nuevamente para ver si el uso volvía a aumentar. Lo hizo:

el administrador de tareas acaba de habilitar hpwa
^{El primer pico cuando habilito HPWA}

administrador de tareas después de habilitar hpwa
^{Un poco después de habilitar HPWA}

La suspensión de los procesos nuevamente provocó que el uso de la CPU volviera a disminuir:

menor uso de CPU después de deshabilitar hpwa

Probé esto durante una iteración más y, en la tercera prueba, volvió a suceder exactamente lo mismo. Consideré que esta evidencia era suficiente para demostrar que el Asistente inalámbrico de HP estaba causando el problema y posteriormente desactivé el servicio y ahora lo desinstalaré.

Todo lo que HPWA parece hacer es informar al usuario cuando su conexión inalámbrica está encendida o apagada y devorar la CPU. No hay nada que pueda hacer con él que no pueda hacer con las herramientas de administración inalámbrica integradas, por lo que le recomendaría que si tiene este software instalado, lo elimine.

Nota:Al menos una persona informó que la desinstalación de HPWA provocó que el interruptor inalámbrico del teclado dejara de funcionar. En mi computadora portátil, siguió funcionando bien después de desinstalar HPWA, pero en caso de que la tuya deje de funcionar, siempre puedes desactivar la tarjeta inalámbrica desde Windows. Presione + xpara abrir el Centro de movilidad de Windows, luego haga clic en el Turn Wireless Offbotón.

centro de movilidad windows

De acuerdo auna discusiónEn los foros de soporte de HP, el problema se solucionó en versiones más recientes del Asistente inalámbrico de HP. Si su computadora portátil necesita HPWA para usar el botón de encendido/apagado de wifi, 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 necesita para el botón de encendido/apagado de wifi, parece que todavía no hay ningún valor añadido al tener este software instalado.

Question 2

Solución de problemas

DescargarProcDumpde Microsoft Sysinternals.
Deje que se descargue una vez que WmiPrvSE.EXE alcance el 25% durante 1 segundo:
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
Esto creará un volcado en su carpeta de Usuario.

Siéntase libre de repetir esto 1 o 2 veces más para tener más volcados y estar seguro de que la causa es el volcado y no otro evento más normal.
Analiza tu(s) volcado(s)en líneay opcionalmente compartirlo enSpeedyCompartir.

Alternativa:WinDBGpodría usarse con el comando !analyze -v, asegúrese deestablecer símbolos.
El seguimiento de la pila que se muestra debe incluir el procedimiento que causa esto.

Quizás busque en Google algunos de los procedimientos principales de la pila para tener una mejor idea de lo que hacen.
Si no le ayudan, es posible que necesite un análisis más avanzado. Vea mi siguiente sección:

Descargue la configuración desdeHerramientas de análisis de rendimiento de Windowspara su versión de Windows.
Instale el software en su sistema.

Abrir un símbolo del sistemacomo administradory copie y pegue el siguiente comando:

xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etl

PrensaENTER una vezpara iniciar el comando, ahora tendrás que esperar hasta que se haya producido el pico.
Justo después de tu picovas a la consola y presionas ENTER.
Después de esperar un tiempo, se generará un archivo de registro myTrace.etl en su carpeta de usuario.
Ejecute el siguiente comando para mostrar el archivo y analizarlo (WinDBG/Símbolosrequerido):
```
xperf %HOMEPATH%\myTrace.etl
```

Si quieres que lo investigue:

Comprima myTrace.etl desde su carpeta de usuario a un archivo zip.
Comparta el archivo zip comprimido enSpeedyCompartir.
Comparta el enlace aquí, intentaré encontrar y mostrarle la causa de su problema.

Como WmiPrvSE.EXE es un host para ejecutar consultas WMI en el almacén CAPI, es posible que no pueda encontrar la causa incluso con XPerf debido aIPC, otra solución que acabo de encontrar sería habilitar el registro WMI y verificar los registros como se describeaquí, ClientProcessId sería el PID del proceso que realizó la consulta WMI. Este PID se puede rastrear hasta el proceso agregando una columna PID al Administrador de tareas oExplorador de procesos, o tasklist /FI "PID eq X"donde X es el PID que encontraste...

Análisis deVolcado 1:Las líneas 94-115 indican unaLlamada a procedimiento remoto.
Análisis deVolcado 2:Las líneas 84-105 indican unaLlamada a procedimiento remoto.

En el Kernel se inicia un nuevo hilo.para manejar un código auxiliar de llamada a procedimiento remoto, que en esencia es una solicitud de consulta que el proveedor WMI ejecutará y responderá. Esto da como resultado una alta actividad de la CPU debido a la lectura del Registro y/o la información de Rendimiento.

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

O, si tuhabilitar la información de estado de RPC, puedes usarrpcdbgpara 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 el RPC, por lo que puedes ver quién lo ejecuta en la segunda línea de la pila. Pero bueno, es poco probable que establecer un punto de interrupción en la primera llamada (tenga en cuenta que esto es depuración en vivo) le ayudará a ver quién llama al proveedor WMI cada vez...

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

Como ahora sabemos sobre el funcionamiento interno de RPC, también podríamos usarMonitor de API:

Descargue, instale e inicie API Monitor. _{(dos vecessi tienes 64 bits: una vez x86, una vez x64)}
Ir aArchivo-->Ejecutar como administrador
Selecciona elFiltro de captura APIal Rpcrt4.dllmódulo.
De manera similar al punto de interrupción, queremos saber quién llama a las RpcServerUseProtSeqfunciones:
Enganche cada unoProceso en ejecuciónexcepto aquellos con un PID bajo (para evitar accidentes).
Ideal, no quieres enganchar dwm.exe/ winlogon.exeo bajar.
También puedes probar procesos individuales y desengancharlos más tarde delProcesos enganchadosventana...

Aunque... lo he probado y podría engancharme con cualquier proceso.
Si todo va bien, elProceso enganchadoque realiza la llamada RPC contendrá hilos.
Y al hacer clic en estos hilos, debería ver un montón de llamadas.
Si lo hace, ¡ha encontrado el proceso que causa el problema!

Solución

Mantener su computadora actualizada es importante, instalarHPWA 4.0.10.0resuelve esto!;-)

Answer

Solución de problemas

DescargarProcDumpde Microsoft Sysinternals.
Deje que se descargue una vez que WmiPrvSE.EXE alcance el 25% durante 1 segundo:
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
Esto creará un volcado en su carpeta de Usuario.

Siéntase libre de repetir esto 1 o 2 veces más para tener más volcados y estar seguro de que la causa es el volcado y no otro evento más normal.
Analiza tu(s) volcado(s)en líneay opcionalmente compartirlo enSpeedyCompartir.

Alternativa:WinDBGpodría usarse con el comando !analyze -v, asegúrese deestablecer símbolos.
El seguimiento de la pila que se muestra debe incluir el procedimiento que causa esto.

Quizás busque en Google algunos de los procedimientos principales de la pila para tener una mejor idea de lo que hacen.
Si no le ayudan, es posible que necesite un análisis más avanzado. Vea mi siguiente sección:

Descargue la configuración desdeHerramientas de análisis de rendimiento de Windowspara su versión de Windows.
Instale el software en su sistema.

Abrir un símbolo del sistemacomo administradory copie y pegue el siguiente comando:

xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etl

PrensaENTER una vezpara iniciar el comando, ahora tendrás que esperar hasta que se haya producido el pico.
Justo después de tu picovas a la consola y presionas ENTER.
Después de esperar un tiempo, se generará un archivo de registro myTrace.etl en su carpeta de usuario.
Ejecute el siguiente comando para mostrar el archivo y analizarlo (WinDBG/Símbolosrequerido):
```
xperf %HOMEPATH%\myTrace.etl
```

Si quieres que lo investigue:

Comprima myTrace.etl desde su carpeta de usuario a un archivo zip.
Comparta el archivo zip comprimido enSpeedyCompartir.
Comparta el enlace aquí, intentaré encontrar y mostrarle la causa de su problema.

Como WmiPrvSE.EXE es un host para ejecutar consultas WMI en el almacén CAPI, es posible que no pueda encontrar la causa incluso con XPerf debido aIPC, otra solución que acabo de encontrar sería habilitar el registro WMI y verificar los registros como se describeaquí, ClientProcessId sería el PID del proceso que realizó la consulta WMI. Este PID se puede rastrear hasta el proceso agregando una columna PID al Administrador de tareas oExplorador de procesos, o tasklist /FI "PID eq X"donde X es el PID que encontraste...

Análisis deVolcado 1:Las líneas 94-115 indican unaLlamada a procedimiento remoto.
Análisis deVolcado 2:Las líneas 84-105 indican unaLlamada a procedimiento remoto.

En el Kernel se inicia un nuevo hilo.para manejar un código auxiliar de llamada a procedimiento remoto, que en esencia es una solicitud de consulta que el proveedor WMI ejecutará y responderá. Esto da como resultado una alta actividad de la CPU debido a la lectura del Registro y/o la información de Rendimiento.

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

O, si tuhabilitar la información de estado de RPC, puedes usarrpcdbgpara 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 el RPC, por lo que puedes ver quién lo ejecuta en la segunda línea de la pila. Pero bueno, es poco probable que establecer un punto de interrupción en la primera llamada (tenga en cuenta que esto es depuración en vivo) le ayudará a ver quién llama al proveedor WMI cada vez...

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

Como ahora sabemos sobre el funcionamiento interno de RPC, también podríamos usarMonitor de API:

Descargue, instale e inicie API Monitor. _{(dos vecessi tienes 64 bits: una vez x86, una vez x64)}
Ir aArchivo-->Ejecutar como administrador
Selecciona elFiltro de captura APIal Rpcrt4.dllmódulo.
De manera similar al punto de interrupción, queremos saber quién llama a las RpcServerUseProtSeqfunciones:
Enganche cada unoProceso en ejecuciónexcepto aquellos con un PID bajo (para evitar accidentes).
Ideal, no quieres enganchar dwm.exe/ winlogon.exeo bajar.
También puedes probar procesos individuales y desengancharlos más tarde delProcesos enganchadosventana...

Aunque... lo he probado y podría engancharme con cualquier proceso.
Si todo va bien, elProceso enganchadoque realiza la llamada RPC contendrá hilos.
Y al hacer clic en estos hilos, debería ver un montón de llamadas.
Si lo hace, ¡ha encontrado el proceso que causa el problema!

Solución

Mantener su computadora actualizada es importante, instalarHPWA 4.0.10.0resuelve esto!;-)

Question 3

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

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, obteniendo así la identificación del proceso culpable.

Answer

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

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, obteniendo así la identificación del proceso culpable.

Question 4

Para depurarlo, use xperf delKit de herramientas de rendimiento de Windowsy 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

Abra el WMItracing.etl generado en WPA.exe y agarre y suelte el gráfico "Eventos genéricos" desde el lado izquierdo del panel de análisis.

Ahora filtra aActividad de Microsoft-Windows-WMIsolo eventos y busque operaciones WMI y ClientProcessId.

En mi ejemplo, este CLientProcessId pertenece a una herramienta llamadaServidor de monitorización Veeam ONE.Al detenerlo, se solucionó el problema de uso de la CPU..

Y el segundo ejemplo se muestra aquí:

Aquí puede ver llamadas recurrentes de un Proceso con PID de 1924 que pertenece al servicio Intel ProSet Monitoring.

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

Entonces, la herramienta Intel realiza consultas de notificación WMI con demasiada frecuencia y esto causa problemas.Al detenerlo, se solucionó el problema.

Answer

Para depurarlo, use xperf delKit de herramientas de rendimiento de Windowsy 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

Abra el WMItracing.etl generado en WPA.exe y agarre y suelte el gráfico "Eventos genéricos" desde el lado izquierdo del panel de análisis.

Ahora filtra aActividad de Microsoft-Windows-WMIsolo eventos y busque operaciones WMI y ClientProcessId.

En mi ejemplo, este CLientProcessId pertenece a una herramienta llamadaServidor de monitorización Veeam ONE.Al detenerlo, se solucionó el problema de uso de la CPU..

Y el segundo ejemplo se muestra aquí:

Aquí puede ver llamadas recurrentes de un Proceso con PID de 1924 que pertenece al servicio Intel ProSet Monitoring.

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

Entonces, la herramienta Intel realiza consultas de notificación WMI con demasiada frecuencia y esto causa problemas.Al detenerlo, se solucionó el problema.

Solución de problemas

Respuesta1

Descripción general del experimento

Información de contexto

Verificando la hipótesis

Respuesta2

Solución de problemas

Solución

Respuesta3

Respuesta4

información relacionada