Geralmente mantenho meu laptop 24 horas por dia, 7 dias por semana, e no final do dia é realmente irritante ter minhas coxas queimadas por superaquecimento.

O superaquecimento parece ser o resultado do host do provedor WMI (WmiPrvSE.exe) aumentando a utilização da CPU para 25% a cada poucos minutos. Por que isso acontece?

Eu tenho um HP Envy 14 (com a porcaria incluída na HP) em execução no Windows 7 Home Premium.

(Nota: Com base nas observações anteriores de @ nhinkle , parece que o HP Wireless Manager pode ser o culpado, existe alguma maneira de confirmar isso?)

Esta pergunta foi uma pergunta da semana para superusuários .
Leia a entrada do blog de 28 de fevereiro de 2011 para obter mais detalhes ou envie sua própria pergunta da semana.

Como Sathya mencionou em sua pergunta, eu já tive experiência anterior com esse problema em meu laptop HP semelhante e agora confirmei usando o método científico que o pico de CPU nos laptops HP é causado pelo HP Wireless Assistant. Ou, HP CPU Assassin, como posso começar a chamá-lo.

Visão geral da experiência

• Pergunta : O que está causando o pico da CPU nos laptops da HP em intervalos frequentes, especificamente no WmiPrvSE.exe processo?

• Hipótese : O HP Wireless Assistant (HPWA) está causando o problema

• Método :

  1. Veja se o problema começa a ocorrer quando o HPWA está instalado.
  2. Veja se a CPU para de acelerar e o WmiPrvSE.exeprocesso para de usar> 20% da CPU quando o processo HPWA é suspenso.
  3. Veja se a CPU começa a disparar novamente quando o processo HPWA é reativado
  4. Repita as etapas 2 e 3 para várias tentativas para garantir resultados precisos
      

• Resultados : O HPWA está causando um uso extremo da CPU

• Conclusão : você deve desinstalar o HPWA, pois isso não é útil

Informações básicas

Quando adquiri meu laptop HP Pavillion dm4t, notei que a CPU frequentemente aumentava em até 50% de uso, quase a cada segundo. Isso consumia a bateria e aquecia o laptop; os mesmos sintomas que Sathya experimentou. Apenas olhando para o Monitor de Recursos no Windows 7, pude ver que o processo WmiPrvSE.exeestava com falha.

Uma rápida pesquisa no Google confirmou minha suposição de que esse era o processo de host da WMI ( Instrumentação de Gerenciamento do Windows ). Em resumo, o WMI pode ser usado para consultar informações do sistema, como uso do processador, processos em execução, quem está conectado e todo tipo de outras informações. O processo host WMI executa consultas WMI para qualquer outro processo que as faça; portanto, WmiPrvSE.exeele não era o culpado, era simplesmente um intermediário.

Para descobrir qual processo específico estava causando esse problema, usei o Systinternals Process Explorer . Eu descobri qual instância do WmiPrvSE.exeprocesso estava usando uma grande quantidade de CPU e cliquei nela para abrir informações detalhadas.

Infelizmente, não consegui encontrar nenhuma maneira de descobrir qual processo estava fazendo todas as consultas, mas como eu o havia isolado como a fonte dos picos de CPU e sabia que era um serviço, fui ao gerente de serviços para ver quais os serviços dependiam do WMI, pensando que isso poderia me levar a outra pista.

Achei que não seria um serviço interno do Windows que estava causando o problema, então, eliminando-os, resolvi trabalhar na lista e tentar desabilitar cada serviço e ver se o problema persistia. 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 gerenciador de tarefas, vi que o uso da CPU havia quase dado quase nada. Eu serviço HPWA novamente. Uso da CPU disparado novamente. Agora eu tinha dados suficientes para formar minha teoria. Desinstalei o serviço HPWA e nunca mais tive o problema.

Verificando a hipótese

Vários meses depois, Sathya faz essa pergunta. Decidi provar de uma vez por todas que isso era culpa da HPWA. Reinstalei o HP Wireless Assistant, que não instalava há meses. Imediatamente, o uso do processador aumentou rapidamente. Eu então continuei com o experimento descrito acima.

Primeiro, eu isolei o processo responsável pelo serviço HPWA no Monitor de Recursos. HPWA_Service.exee HPWA_Main.exesão os dois. Aqui está como era o uso da CPU com as duas processadas em execução:

Então, suspendi os dois processos. O uso da CPU caiu imediatamente; aqui está o que parecia depois de alguns momentos para o uso anterior da CPU no gráfico esclarecer:

Eu habilitei os processos novamente para ver se o uso voltaria. Ele fez:

^{O primeiro pico ao ativar o HPWA}

^{Um pouco depois de ativar o HPWA}

Suspender os processos novamente resultou no uso da CPU voltando para baixo:

Eu testei isso para mais uma iteração e, no terceiro teste, a mesma coisa exata aconteceu novamente. Eu considerei essa evidência suficiente para mostrar que o HP Wireless Assistant estava causando o problema e, posteriormente, desabilitei o serviço e agora o desinstalará.

Tudo o que a HPWA parece fazer é informar o usuário quando a rede sem fio está ligada ou desligada e devorar a CPU. Não há nada que você possa fazer com isso que não possa fazer com as ferramentas de gerenciamento sem fio integradas, por isso aconselho que, se você tiver esse software instalado, remova-o.

Nota: Pelo menos uma pessoa relatou que a desinstalação do HPWA fez com que o comutador sem fio no teclado parasse de funcionar. No meu laptop, ele continuou funcionando bem após a desinstalação do HPWA, mas caso o seu pare de funcionar, você sempre pode desativar a placa sem fio no Windows. Pressione + xpara abrir o Windows Mobility Center e clique no Turn Wireless Offbotão.

De acordo com uma discussão nos Fóruns de suporte HP, o problema foi corrigido nas versões mais recentes do HP Wireless Assistant. Se o seu laptop precisar do HPWA para usar o botão ligar / desligar do wifi, você poderá fazer o download da versão mais recente no site de drivers da HP e provavelmente não terá mais esse problema. No entanto, se você não precisar dele para o botão liga / desliga do Wi-Fi, ainda não parece haver valor agregado ao instalar este software.

Solução de problemas

1. Faça o download do ProcDump no Microsoft Sysinternals.

2. Deixe o lixo cair quando o WmiPrvSE.EXE atingir 25% por 1 segundo:

   procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
   

   Isso criará um despejo na sua pasta Usuário.

   Sinta-se à vontade para repetir isso 1-2 vezes mais, para ter mais lixões e ter certeza de que a causa foi lixada e não outro evento mais normal.

3. Analise seus despejos online e, opcionalmente, compartilhe-os no SpeedyShare .

   Alternativa : WinDBG pode ser usado com o comando !analyze -v, certifique-se de definir símbolos .

4. O rastreamento de pilha que mostra deve incluir o procedimento que causa isso.

Talvez pesquise no Google alguns dos principais procedimentos da pilha para ter uma idéia melhor do que eles fazem.
Se eles não ajudarem, você pode precisar de uma análise mais avançada. Veja minha próxima seção:

1. Baixe a instalação do Windows Performance Analysis Tools para sua versão do Windows.
2. Instale o software no seu sistema.

3. Abra um prompt de comando como administrador e copie e cole o próximo comando:

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

4. Pressione ENTER uma vez para iniciar o comando, agora você terá que esperar até que o pico ocorra.

5. Logo após o seu pico, você vai ao console e pressiona ENTER.
6. Depois de esperar algum tempo, um arquivo de log myTrace.etl será produzido na sua pasta de usuário.

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

   xperf %HOMEPATH%\myTrace.etl
   

Se você quer que eu olhe para ele:

8. Compacte myTrace.etl da sua Pasta do Usuário para um arquivo zip.
9. Compartilhe o arquivo zip compactado no SpeedyShare .
10. Compartilhe o link aqui, tentarei encontrar e mostrar a causa do seu problema.

Como o WmiPrvSE.EXE é um host para executar consultas WMI no repositório CAPI, talvez você não consiga encontrar a causa, mesmo com o XPerf devido ao IPC , outra solução que acabei de encontrar seria habilitar o log WMI e verificar os logs conforme descrito aqui , o ClientProcessId seria o PID do processo que fez a consulta WMI. Esse PID pode ser rastreado de volta ao processo adicionando uma coluna PID ao Gerenciador de Tarefas ou ao Process Explorer , ou tasklist /FI "PID eq X"onde X é o PID que você encontrou ...

A análise do despejo 1 : as linhas 94-115 indicam uma chamada de procedimento remoto .
Análise do Dump 2 : As linhas 84-105 indicam uma Chamada de Procedimento Remoto .

No Kernel, um novo thread é iniciado para lidar com um stub de Chamada de Procedimento Remoto , que é essencialmente uma solicitação de consulta à qual o Provedor WMI executará e responderá. Isso resulta em uma alta atividade da CPU devido à leitura das informações do Registro e / ou Desempenho.

Como um dump é uma captura de um único momento, você não poderá ver qual processo executou o RPC.
Portanto, você precisa de um programa que rastreie como XPerf para ver o encadeamento anterior que estaria executando o RPC.

Ou, se você habilitar as informações do estado de RPC , poderá usar o 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 define um ponto de interrupção no RPC, para que você possa ver quem o executa na segunda linha da pilha. Mas bem, é improvável que definir um ponto de interrupção na primeira chamada (observe que isso é depuração ao vivo) o ajudará a ver quem liga sempre para o provedor WMI ...

Há muito mais informações nesse artigo sobre as informações do estado de RPC que podem ajudar, mas não é para os fracos como nós passar por tudo isso quando poderíamos usar o XPerf. :-)

Como agora sabemos sobre o trabalho interno de como a RPC funciona, também podemos usar o API Monitor :

1. Baixe, instale e inicie o API Monitor. _{( duas vezes se você tiver 64 bits: uma vez x86, uma vez x64)}
2. Vá para Arquivo -> Executar como administrador

3. Defina o API Capture Filter como o Rpcrt4.dllmódulo.

   

4. Semelhante ao ponto de interrupção, queremos saber quem chama as RpcServerUseProtSeqfunções:

   

5. Ligue cada processo em execução, exceto aqueles com um PID baixo (para evitar falhas).
   Ideal, você não quer enganchar dwm.exe/ winlogon.exeou abaixar.
   Você também pode tentar processos únicos e soltá-los mais tarde na janela Processos Hooked ...

   Embora ... eu tentei e poderia ligar sobre qualquer processo.

6. Se tudo correr bem, o Processo Conectado que faz a chamada RPC conterá threads.
   E ao clicar nesses tópicos, você verá várias chamadas.
   Se o fizer, você encontrou o processo que está causando o problema!

Solução

Manter o computador atualizado é importante, a instalação do HPWA 4.0.10.0 resolve isso! ;-)

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

O método usa a opção Visualizador de eventos de "Mostrar logs analíticos e de depuração" para rastrear toda a atividade WMI, obtendo assim a identificação do processo culpado.

Adicionando isso a qualquer outra pessoa no mesmo barco, esta página está em todo o Google. Eu tive o mesmo problema com o WmiProvderHost, aumentando a CPU em até 50% e esgotando a bateria no meu Lenovo Yoga2 Pro no Windows 8.1.

Seguindo alguns dos excelentes conselhos de investigação acima, descobri que o problema era, na verdade, o GoPro Studio (software gratuito de edição de vídeo fornecido com as câmeras GoPro). Ele instala um serviço de monitoramento que espera você conectar sua câmera e, para mim, esse foi o culpado.

Para depurá-lo, use xperf no kit de ferramentas de desempenho do Windows 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 no WPA.exe e resista e solte o gráfico "Eventos genéricos" do lado esquerdo para o painel de análise.

Agora filtre apenas aos eventos Microsoft-Windows-WMI-Activity e procure operações WMI e ClientProcessId.

No meu exemplo, este CLientProcessId pertence a uma ferramenta chamada Veeam ONE Monitor Server . Parando, foi corrigido o problema de uso da CPU .

E o segundo exemplo é mostrado aqui:

Você vê chamadas recorrentes de um processo com PID de 1924, que pertence ao serviço Intel ProSet Monitoring.

Aqui, o uso da CPU também é mostrado nas pilhas de chamadas de amostragem da CPU:

Portanto, a ferramenta Intel faz consultas de notificação WMI com muita frequência e isso causa os problemas. Parando, corrigiu o problema.

Você já tentou ver se é um vírus? Alguns vírus realmente gostam de aparecer como serviços do Windows assim. Verifique se o WmiPrvSE.exeprocesso está localizado no c:\windows\system32\wbemdiretório Caso contrário, convém executar programas gerais de detecção de spyware. Se não é spyware, pode ser outro serviço que está chamando. Sei que tenho alguns gadgets em execução no meu computador e, ironicamente, o gadget do monitor de desempenho às vezes faz minha CPU disparar um pouco. Além disso, poderia ser outro serviço que pressiona esse gás de vez em quando. Por exemplo, bloatware da HP, Dell, etc.

Fora isso, a outra resposta do TomWij parece muito boa para solucionar o problema!