Solução de problemas

Question 1

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

Visão geral do experimento

Pergunta:O que está fazendo com que a CPU dos laptops HP aumente em intervalos frequentes, especificamente o 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 é instalado.
2. Veja se a CPU para de aumentar 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ários testes para garantir resultados precisos
Resultados:HPWA está causando uso extremo da CPU
Conclusão:Você deve desinstalar o HPWA, pois não faz nada de útil

Informações básicas

Quando comprei meu laptop HP Pavillion dm4t, percebi que a CPU frequentemente atingia até 50% de uso, quase a cada segundo. Isso estava esgotando a vida útil da bateria e aquecendo o laptop; praticamente os mesmos sintomas que Sathya experimentou. Apenas olhando para o Monitor de Recursos do Windows 7, pude ver que o WmiPrvSE.exeproblema era o processo.

CPU, nome, nome

Uma rápida pesquisa no Google confirmou minha suposição de que este era oInstrumentação de gerenciamento do Windows(WMI) processo host. Resumindo, 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.exenão foi o culpado, foi simplesmente um intermediário.

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

explorador de processos

Infelizmente, não consegui descobrir qual processo estava fazendo todas as consultas, mas como isolei isso como a origem dos picos de CPU e sabia que era um serviço, fui ao gerenciador de serviços para ver qual os serviços dependiam do WMI, pensando que isso poderia me levar a outra pista.

serviços nom nom

Achei que não seria um serviço interno do Windows que estava causando o problema, então, eliminando-os, decidi analisar a lista e tentar desabilitar cada serviço e ver se o problema persistia. Bem no topo da lista estava o HP Wireless Assistant Service. Voltei ao menu de serviços e desativei esse serviço. Olhando para trás no gerenciador de tarefas, vi que o uso da CPU havia diminuído para quase nada. Reativei o serviço HPWA. O uso da CPU voltou a disparar. Agora eu tinha dados suficientes para formar minha teoria. Desinstalei o serviço HPWA e nunca mais tive problema.

Verificando a hipótese

Vários meses depois, Sathya faz esta pergunta. Decidi provar de uma vez por todas que a culpa era da HPWA. Reinstalei o HP Wireless Assistant, que não instalava há meses. Imediatamente, o uso do processador disparou. Em seguida, realizei o experimento descrito acima.

Primeiramente isolei o processo responsável pelo serviço HPWA no Monitor de Recursos. HPWA_Service.exee HPWA_Main.exesão os dois. Aqui está a aparência do uso da CPU com ambos os processos em execução:

gerenciador de tarefas com hpwa em execução

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

gerenciador de tarefas sem hpwa em execução

Ativei os processos novamente para ver se o uso voltaria a aumentar. Aconteceu:

gerenciador de tarefas acabou de ativar o hpwa
^{O primeiro pico ao habilitar o HPWA}

gerenciador de tarefas depois de ativar o hpwa
^{Um pouco depois de ativar o HPWA}

A suspensão dos processos novamente resultou na diminuição do uso da CPU:

menor uso da CPU após desativar o hpwa

Testei isso em mais uma iteração e, na terceira tentativa, exatamente a mesma coisa aconteceu novamente. Considerei esta evidência suficiente para mostrar que o HP Wireless Assistant estava causando o problema e, posteriormente, desativei o serviço e agora irei desinstalá-lo.

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

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

centro de mobilidade de janelas

De acordo comuma discussãonos Fóruns de Suporte HP, o problema foi corrigido em versões mais recentes do HP Wireless Assistant. Se o seu laptop precisa do HPWA para usar o botão liga / desliga do wifi, você pode baixar a 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 wifi, ainda parece não haver valor agregado em ter este software instalado.

Answer

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

Visão geral do experimento

Pergunta:O que está fazendo com que a CPU dos laptops HP aumente em intervalos frequentes, especificamente o 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 é instalado.
2. Veja se a CPU para de aumentar 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ários testes para garantir resultados precisos
Resultados:HPWA está causando uso extremo da CPU
Conclusão:Você deve desinstalar o HPWA, pois não faz nada de útil

Informações básicas

Quando comprei meu laptop HP Pavillion dm4t, percebi que a CPU frequentemente atingia até 50% de uso, quase a cada segundo. Isso estava esgotando a vida útil da bateria e aquecendo o laptop; praticamente os mesmos sintomas que Sathya experimentou. Apenas olhando para o Monitor de Recursos do Windows 7, pude ver que o WmiPrvSE.exeproblema era o processo.

CPU, nome, nome

Uma rápida pesquisa no Google confirmou minha suposição de que este era oInstrumentação de gerenciamento do Windows(WMI) processo host. Resumindo, 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.exenão foi o culpado, foi simplesmente um intermediário.

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

explorador de processos

Infelizmente, não consegui descobrir qual processo estava fazendo todas as consultas, mas como isolei isso como a origem dos picos de CPU e sabia que era um serviço, fui ao gerenciador de serviços para ver qual os serviços dependiam do WMI, pensando que isso poderia me levar a outra pista.

serviços nom nom

Achei que não seria um serviço interno do Windows que estava causando o problema, então, eliminando-os, decidi analisar a lista e tentar desabilitar cada serviço e ver se o problema persistia. Bem no topo da lista estava o HP Wireless Assistant Service. Voltei ao menu de serviços e desativei esse serviço. Olhando para trás no gerenciador de tarefas, vi que o uso da CPU havia diminuído para quase nada. Reativei o serviço HPWA. O uso da CPU voltou a disparar. Agora eu tinha dados suficientes para formar minha teoria. Desinstalei o serviço HPWA e nunca mais tive problema.

Verificando a hipótese

Vários meses depois, Sathya faz esta pergunta. Decidi provar de uma vez por todas que a culpa era da HPWA. Reinstalei o HP Wireless Assistant, que não instalava há meses. Imediatamente, o uso do processador disparou. Em seguida, realizei o experimento descrito acima.

Primeiramente isolei o processo responsável pelo serviço HPWA no Monitor de Recursos. HPWA_Service.exee HPWA_Main.exesão os dois. Aqui está a aparência do uso da CPU com ambos os processos em execução:

gerenciador de tarefas com hpwa em execução

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

gerenciador de tarefas sem hpwa em execução

Ativei os processos novamente para ver se o uso voltaria a aumentar. Aconteceu:

gerenciador de tarefas acabou de ativar o hpwa
^{O primeiro pico ao habilitar o HPWA}

gerenciador de tarefas depois de ativar o hpwa
^{Um pouco depois de ativar o HPWA}

A suspensão dos processos novamente resultou na diminuição do uso da CPU:

menor uso da CPU após desativar o hpwa

Testei isso em mais uma iteração e, na terceira tentativa, exatamente a mesma coisa aconteceu novamente. Considerei esta evidência suficiente para mostrar que o HP Wireless Assistant estava causando o problema e, posteriormente, desativei o serviço e agora irei desinstalá-lo.

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

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

centro de mobilidade de janelas

De acordo comuma discussãonos Fóruns de Suporte HP, o problema foi corrigido em versões mais recentes do HP Wireless Assistant. Se o seu laptop precisa do HPWA para usar o botão liga / desliga do wifi, você pode baixar a 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 wifi, ainda parece não haver valor agregado em ter este software instalado.

Question 2

Solução de problemas

DownloadProcDumpda Microsoft Sysinternals.
Deixe-o fazer um dump 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 de usuário.

Sinta-se à vontade para repetir isso mais 1 a 2 vezes para ter mais lixões e ter certeza de que a causa foi descartada e não outro evento mais normal.
Analise seu(s) despejo(s)on-linee, opcionalmente, compartilhe-o emSpeedyShare.

Alternativa:WinDBGpoderia ser usado com o comando !analyze -v, certifique-se dedefinir símbolos.
O rastreamento de pilha mostrado deve incluir o procedimento que causa isso.

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

Baixe a configuração emFerramentas de análise de desempenho do Windowspara sua versão do Windows.
Instale o software em seu sistema.

Abra um prompt de comandocomo administradore copie e cole o próximo comando:

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

ImprensaENTER uma vezpara iniciar o comando, agora você terá que esperar até que o pico ocorra.
Logo após o seu picovocê vai para o console e pressiona ENTER.
Depois de esperar algum tempo, um arquivo de log myTrace.etl será produzido em sua pasta de usuário.
Execute o seguinte comando para mostrar o arquivo e analisá-lo (WinDBG/Símbolosobrigatório):
```
xperf %HOMEPATH%\myTrace.etl
```

Se você quiser que eu dê uma olhada nisso:

Compacte myTrace.etl da sua pasta de usuário em um arquivo zip.
Compartilhe o arquivo zip compactado emSpeedyShare.
Compartilhe o link aqui, tentarei encontrar e mostrar a causa do seu problema.

Como WmiPrvSE.EXE é um host para execução de consultas WMI no armazenamento CAPI, talvez você não consiga encontrar a causa mesmo com XPerf devido aCIP, outra solução que acabei de encontrar seria habilitar o log do WMI e verificar os logs conforme descritoaqui, o ClientProcessId seria o PID do Processo que fez a consulta WMI. Este PID pode ser rastreado até o processo adicionando uma coluna PID ao Gerenciador de Tarefas ouExplorador de processos, ou com tasklist /FI "PID eq X"onde X é o PID que você encontrou...

Análise deDespejar 1:As linhas 94-115 indicam umChamada de procedimento remoto.
Análise deDespejo 2:As linhas 84-105 indicam umChamada de procedimento remoto.

No Kernel, um novo thread é iniciadopara lidar com um stub de chamada de procedimento remoto, que em essência é uma solicitação de consulta que o provedor WMI executará e responderá. Isso resulta em uma alta atividade da CPU devido à leitura das informações de registro e/ou desempenho.

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

Ou, se vocêativar informações de estado RPC, você pode usarrpcdbgpara 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 esta é uma depuração ao vivo) ajudará você a ver quem liga para o provedor WMI todas as vezes...

Há muito mais informações nesse artigo sobreInformações de estado RPCisso pode ajudar, mas não é para os tímidos como nós passar por tudo isso quando poderíamos simplesmente usar o XPerf. :-)

Como agora sabemos sobre o funcionamento interno do RPC, poderíamos também usarMonitor de API:

Baixe, instale e inicie o API Monitor. _{(duas vezesse você tiver 64 bits: uma vez x86, uma vez x64)}
Vá paraArquivo-->Executar como administrador
Colocou oFiltro de captura de APIpara o Rpcrt4.dllmódulo.
Semelhante ao breakpoint, queremos saber quem chama as RpcServerUseProtSeqfunções:
Enganche cada umProcesso em execuçãoexceto aqueles com PID baixo (para evitar travamentos).
Ideal, você não quer enganchar dwm.exe/ winlogon.exeou abaixar.
Você também pode tentar processos únicos e desconectá-los mais tarde doProcessos viciadosjanela...

Embora... eu tentei e poderia me envolver em qualquer processo.
Se tudo correr bem, oProcesso viciadoque faz a chamada RPC conterá threads.
E ao clicar nesses tópicos, você verá um monte de chamadas.
Se fizer isso, você encontrou o processo que está causando o problema!

Solução

Manter seu computador atualizado é importante, instalarHPWA4.0.10.0resolve isso!;-)

Answer

Solução de problemas

DownloadProcDumpda Microsoft Sysinternals.
Deixe-o fazer um dump 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 de usuário.

Sinta-se à vontade para repetir isso mais 1 a 2 vezes para ter mais lixões e ter certeza de que a causa foi descartada e não outro evento mais normal.
Analise seu(s) despejo(s)on-linee, opcionalmente, compartilhe-o emSpeedyShare.

Alternativa:WinDBGpoderia ser usado com o comando !analyze -v, certifique-se dedefinir símbolos.
O rastreamento de pilha mostrado deve incluir o procedimento que causa isso.

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

Baixe a configuração emFerramentas de análise de desempenho do Windowspara sua versão do Windows.
Instale o software em seu sistema.

Abra um prompt de comandocomo administradore copie e cole o próximo comando:

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

ImprensaENTER uma vezpara iniciar o comando, agora você terá que esperar até que o pico ocorra.
Logo após o seu picovocê vai para o console e pressiona ENTER.
Depois de esperar algum tempo, um arquivo de log myTrace.etl será produzido em sua pasta de usuário.
Execute o seguinte comando para mostrar o arquivo e analisá-lo (WinDBG/Símbolosobrigatório):
```
xperf %HOMEPATH%\myTrace.etl
```

Se você quiser que eu dê uma olhada nisso:

Compacte myTrace.etl da sua pasta de usuário em um arquivo zip.
Compartilhe o arquivo zip compactado emSpeedyShare.
Compartilhe o link aqui, tentarei encontrar e mostrar a causa do seu problema.

Como WmiPrvSE.EXE é um host para execução de consultas WMI no armazenamento CAPI, talvez você não consiga encontrar a causa mesmo com XPerf devido aCIP, outra solução que acabei de encontrar seria habilitar o log do WMI e verificar os logs conforme descritoaqui, o ClientProcessId seria o PID do Processo que fez a consulta WMI. Este PID pode ser rastreado até o processo adicionando uma coluna PID ao Gerenciador de Tarefas ouExplorador de processos, ou com tasklist /FI "PID eq X"onde X é o PID que você encontrou...

Análise deDespejar 1:As linhas 94-115 indicam umChamada de procedimento remoto.
Análise deDespejo 2:As linhas 84-105 indicam umChamada de procedimento remoto.

No Kernel, um novo thread é iniciadopara lidar com um stub de chamada de procedimento remoto, que em essência é uma solicitação de consulta que o provedor WMI executará e responderá. Isso resulta em uma alta atividade da CPU devido à leitura das informações de registro e/ou desempenho.

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

Ou, se vocêativar informações de estado RPC, você pode usarrpcdbgpara 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 esta é uma depuração ao vivo) ajudará você a ver quem liga para o provedor WMI todas as vezes...

Há muito mais informações nesse artigo sobreInformações de estado RPCisso pode ajudar, mas não é para os tímidos como nós passar por tudo isso quando poderíamos simplesmente usar o XPerf. :-)

Como agora sabemos sobre o funcionamento interno do RPC, poderíamos também usarMonitor de API:

Baixe, instale e inicie o API Monitor. _{(duas vezesse você tiver 64 bits: uma vez x86, uma vez x64)}
Vá paraArquivo-->Executar como administrador
Colocou oFiltro de captura de APIpara o Rpcrt4.dllmódulo.
Semelhante ao breakpoint, queremos saber quem chama as RpcServerUseProtSeqfunções:
Enganche cada umProcesso em execuçãoexceto aqueles com PID baixo (para evitar travamentos).
Ideal, você não quer enganchar dwm.exe/ winlogon.exeou abaixar.
Você também pode tentar processos únicos e desconectá-los mais tarde doProcessos viciadosjanela...

Embora... eu tentei e poderia me envolver em qualquer processo.
Se tudo correr bem, oProcesso viciadoque faz a chamada RPC conterá threads.
E ao clicar nesses tópicos, você verá um monte de chamadas.
Se fizer isso, você encontrou o processo que está causando o problema!

Solução

Manter seu computador atualizado é importante, instalarHPWA4.0.10.0resolve isso!;-)

Question 3

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

O método usa a opção do visualizador de eventos de "Mostrar logs analíticos e de depuração" para rastrear todas as atividades do WMI, obtendo assim o ID do processo culpado.

Answer

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

O método usa a opção do visualizador de eventos de "Mostrar logs analíticos e de depuração" para rastrear todas as atividades do WMI, obtendo assim o ID do processo culpado.

Question 4

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

Agora filtre paraAtividade WMI do Microsoft-Windowssomente eventos e procure operações WMI e o ClientProcessId.

No meu exemplo, este CLIentProcessId pertence a uma ferramenta chamadaServidor de monitoramento Veeam ONE.Pará-lo corrigiu o problema de uso da CPU.

E o segundo exemplo é mostrado aqui:

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 problemas.Pará-lo resolveu o problema.

Answer

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

Agora filtre paraAtividade WMI do Microsoft-Windowssomente eventos e procure operações WMI e o ClientProcessId.

No meu exemplo, este CLIentProcessId pertence a uma ferramenta chamadaServidor de monitoramento Veeam ONE.Pará-lo corrigiu o problema de uso da CPU.

E o segundo exemplo é mostrado aqui:

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 problemas.Pará-lo resolveu o problema.

Solução de problemas

Responder1

Visão geral do experimento

Informações básicas

Verificando a hipótese

Responder2

Solução de problemas

Solução

Responder3

Responder4

informação relacionada