Como Sathya referiu na sua pergunta, já tive experiência anterior com este problema no meu portátil HP semelhante, e confirmei agora, utilizando o método científico, que os picos de CPU nos computadores portáteis HP são causados pelo Assistente sem fios HP. Ou, Assassin CPU HP, como lhe posso começar a chamar.

Overview of the Experiment

• Question : O que está a causar o pico do CPU do portátil HP a intervalos frequentes, especificamente o WmiPrvSE.exe process?

• Hypothesis* : O Assistente sem fios HP (HPWA) está a causar o problema_

• Método :

• Resultados : HPWA está a causar uma utilização extrema de CPU

• Conclusão* : Você deve desinstalar o HPWA, pois ele não faz nada de útil

Informação de fundo

Quando recebi o meu laptop HP Pavillion dm4t, notei que o CPU chegava frequentemente a atingir 50% de utilização, quase a cada dois segundos. Isto estava a esgotar a autonomia da bateria e a aquecer o computador portátil; muitos dos mesmos sintomas que o Sathya tem experimentado. Só de olhar para o Monitor de Recursos no Windows 7, pude ver que o processo WmiPrvSE.exe estava em falha.

Uma pesquisa rápida no Google confirmou a minha suposição de que este era o Windows Management Instrumentation (WMI) host process. Em suma, a WMI pode ser usada para consultar informações do sistema, como a utilização do processador, processos em execução, quem está ligado, e todo o tipo de outras informações. O processo anfitrião da WMI executa consultas da WMI para qualquer outro processo que as faça, pelo que o WmiPrvSE.exe não foi ele próprio o culpado, foi simplesmente um intermediário.

A fim de procurar qual o processo específico que estava a causar este problema, utilizei Systinternals Process Explorer . Descobri qual dos processos WmiPrvSE.exe estava a utilizar uma grande quantidade de CPU e cliquei nele para abrir informações detalhadas.

Infelizmente, não consegui descobrir que processo estava a fazer todas as perguntas, mas como tinha isolado isto como fonte dos picos de CPU e sabia que se tratava de um serviço, fui ao gestor de serviços para ver quais os serviços que dependiam da WMI, pensando que isso me poderia levar a outra pista.

Pensei que não seria um serviço Windows incorporado que causasse o problema, eliminando-os, decidi trabalhar para baixo na lista e tentar desactivar cada serviço, e ver se o problema persistia. Mesmo no topo da lista estava o HP Wireless Assistant Service. Voltei ao menu de serviços, e desabilitei esse serviço. Olhando para trás no gestor de tarefas, vi que a utilização de CPU tinha ido para quase nada. Eu, o serviço HPWA, voltei a funcionar. A utilização de CPU voltou a aumentar. Agora eu tinha dados suficientes para formar a minha teoria. Desinstalei o serviço HPWA, e nunca mais tive o problema.

Verificando a Hipótese

Vários meses depois, Sathya faz esta pergunta. Decidi provar de uma vez por todas que a culpa era do HPWA. Reinstalei o Assistente sem fios HP, que não tinha instalado há meses. Imediatamente, o uso do processador disparou. Depois passei à experiência acima descrita.

Primeiro, isolei o processo responsável pelo serviço HPWA no Monitor de Recursos. HPWA_Service.exe e HPWA_Main.exe são os dois. Eis como era a utilização da CPU com ambos os processos em execução:

Depois, suspendi ambos os processos. A utilização do CPU desceu imediatamente; aqui está o que parecia após alguns momentos para a utilização anterior do CPU no gráfico para limpar:

Activei novamente os processos para ver se a utilização voltava a subir. Fez:

Suspender os processos novamente resultou na diminuição da utilização do CPU:

Testei isto para mais uma iteração, e no terceiro teste, aconteceu exactamente a mesma coisa de novo. Considerei esta prova suficiente para mostrar que o HP Wireless Assistant estava a causar o problema, e subsequentemente desactivou o serviço, e irá agora desinstalá-lo.

Tudo o que o HPWA parece fazer é informar o utilizador quando o seu wireless está ligado ou desligado, e devorar o CPU. Não há nada que possa fazer com ele que não possa fazer com as ferramentas de gestão sem fios integradas, por isso aconselho que, se tiver este software instalado, o remova.

Nota: Pelo menos uma pessoa informou que a desinstalação do HPWA fez com que o seu interruptor sem fios no teclado parasse de funcionar. No meu portátil, continuou a funcionar bem depois de desinstalar o HPWA, mas caso o seu deixe de funcionar, pode sempre desactivar o cartão sem fios a partir do interior do Windows. Pressione

De acordo com a discussão nos Fóruns de Suporte HP, o problema foi resolvido em versões mais recentes do HP Wireless Assistant. Se o seu portátil necessita que o HPWA utilize o wifi on/off você pode baixar a última versão do site de drivers da HP, e provavelmente não terá mais este problema. No entanto, se não precisar dele para o botão wifi on/off, parece que ainda não há nenhum valor acrescentado em ter este software instalado.

Resolução de problemas

1. Download ProcDump da Microsoft Sysinternals.

2. Deixe que se despeje quando o WmiPrvSE.EXE atingir 25% durante 1 segundo:

3. Analise a(s) sua(s) lixeira(s) online e opcionalmente partilhe-as em SpeedyShare .

4. O stack trace que mostra deve incluir o procedimento que causa isto.

Talvez pesquisar no Google alguns dos principais procedimentos da pilha para ter uma melhor ideia do que eles fazem. Se eles não o ajudarem pode precisar de uma análise mais avançada. Ver a minha próxima secção:

1. Faça o download da configuração em Windows Performance Analysis Tools para a sua versão Windows.
2. Instale o software no seu sistema.

3. Abra um prompt de comando como administrador , e copie o comando seguinte:

4. Prima ENTER once* para iniciar o comando, agora terá de esperar até o pico ocorrer.

5. 5. Após o pico*, vá até à consola e carregue em ENTER.

6. Depois de esperar algum tempo um ficheiro de log myTrace.etl será produzido na sua pasta de utilizador.

7. Execute o seguinte comando para mostrar o ficheiro e analisá-lo WinDBG Símbolos necessário):

Se quiser que eu o veja:

1. Comprima o myTrace.etl da sua pasta de utilizador para um ficheiro zip.
2. Partilhe o ficheiro zip comprimido em SpeedyShare .
3. Partilhe o link aqui, vou tentar encontrar e mostrar-lhe a causa do seu problema.

Como WmiPrvSE. EXE é um host para executar consultas WMI contra a loja CAPI, você pode não ser capaz de encontrar a causa mesmo com XPerf devido a IPC , outra solução que acabei de encontrar seria permitir o registo WMI e verificar os registos como descrito aqui , o ClientProcessId seria o PID do Processo que fez a consulta WMI. Esta PID pode ser rastreada de volta ao processo adicionando uma coluna PID ao Task Manager ou Process Explorer , ou com tasklist /FI "PID eq X" onde X é a PID que encontrou…

Análise de Dump 1 : As linhas 94-115 indicam uma Chamada de Procedimento Remoto .
Análise de Dump 2 : As linhas 84-105 indicam uma chamada de Remote Procedure Call .

No Kernel, é iniciada uma nova linha para tratar um stub de chamada de procedimento remoto , que na sua essência é um pedido de consulta que o fornecedor da WMI executará e responderá. Isto resulta numa alta actividade do CPU devido à leitura da informação do Registo e/ou Performance.

Como um dump é uma captura de um único momento não será capaz de ver qual o processo que executou o RPC. Portanto, é necessário um programa que trace como o XPerf para ver o thread anterior que estaria a fazer o RPC.

Ou, se você habilitar o RPC State Information , você pode usar rpcdbg para ver quem iniciou a chamada.

Exemplo:

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]

O exemplo acima estabelece um ponto de parada no RPC, para que você possa ver quem o executa na segunda linha da pilha. Mas bem, é improvável que definir um breakpoint na primeira chamada (note que isto é depuração ao vivo) o ajude a ver quem liga para o Fornecedor da WMI sempre…

Há muito mais informação nesse artigo sobre RPC State Information que pode ajudar, mas não é para os fracos como nós passarem por tudo isso quando podíamos usar apenas XPerf :-)

Como agora sabemos sobre o funcionamento interno do RPC, também podíamos usar API Monitor :

1. Descarregar, instalar e iniciar o API Monitor. ( twice se tiver 64 bit: uma vez x86, uma vez x64)
2. Vá para Arquivo –> Executar como Administrador

3. Defina o API Capture Filter* para o módulo Rpcrt4.dll.

4. Similar ao breakpoint, queremos saber quem chama as funções do RpcServerUseProtSeq:

5. Gancho cada Processo em Execução* excepto para aqueles com um PID baixo (para evitar falhas). Ideal, não quer enganchar o dwm.exe/winlogon.exe ou baixar. Também pode tentar processos individuais e desengandá-los mais tarde da janela Processos Enganchados…

6. Se tudo correr bem, o Processo Gancho* que faz a chamada RPC irá conter fios. E ao clicar nestes fios, deverá ver um monte de chamadas. Se o fizer, já encontrou o processo que causa o problema!

Solução

A manutenção do seu computador actualizado é importante, instalar HPWA 4.0.10.0 resolve isto! ;-)

A entrada no blog da Microsoft O WMIprvse é um verdadeiro vilão? _ mostra como encontrar qual processo é responsável pelo CPU que o WmiPrvSE.exe está usando.

O método usa a opção Event viewer de “Show Analytic and Debug Logs” para rastrear toda a atividade do WMI, obtendo assim o processo-id do processo culpado.

Adicionando isto para qualquer outra pessoa no mesmo barco, esta página está em todo o Google. Tive o mesmo problema com o WmiProvderHost a aumentar o CPU até 50% e a esgotar a bateria do meu Lenovo Yoga2 Pro no Windows 8.1.

Seguindo alguns dos excelentes conselhos de investigação acima, descobri que o problema para mim era na verdade GoPro Studio (software gratuito de edição de vídeo que vem com câmaras GoPro). Ele instala um serviço de monitorização que espera por si para ligar a sua câmara e para mim este foi o culpado.

Para depurá-lo, use xperf do Windows Performance toolkit e execute este arquivo 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 o WMItracing.etl gerado em WPA.exe e pegue e solte o gráfico “Generic Events” do lado esquerdo para o painel de análise.

Agora filtre para Microsoft-Windows-WMI-Activity apenas eventos, e procure por operações WMI e o ClientProcessId.

No meu exemplo este CLientProcessId pertence a uma ferramenta chamada Veeam ONE Monitor Server. Parando, resolveu o problema da utilização do CPU .

E o segundo exemplo é mostrado aqui:

HEre você vê chamadas recorrentes de um Processo com PID de 1924 que pertence ao serviço Intel ProSet Monitoring.

Aqui a utilização do CPU também é mostrada nas chamadas de amostragem do CPU:

Assim, a ferramenta Intel faz consultas de notificação WMI com demasiada frequência e isto causa os problemas. Parar, resolver o problema.

Já tentou ver se se trata de um vírus? Alguns vírus gostam mesmo de desfilar como serviços Windows como esse. Certifique-se de que o processo WmiPrvSE.exe está localizado no directório c:\windows\system32\wbem. Caso contrário, pode querer executar programas gerais de detecção de spyware. Se não for spyware, poderá ser outro serviço que lhe esteja a chamar. Eu sei que tenho alguns gadgets rápidos a correr no meu computador, e ironicamente o gadget do monitor de desempenho às vezes faz o meu CPU disparar um pouco. Além disso, pode ser outro serviço que, de vez em quando, carrega nesse gás. Por exemplo, bloatware da HP, Dell, etc.

Fora isso, a outra resposta do TomWij parece muito boa para a resolução de problemas!