Come ha detto Sathya nella sua domanda, ho avuto precedenti esperienze con questo problema sul mio simile portatile HP, e ora ho confermato con il metodo scientifico che i picchi di CPU sui portatili HP sono causati dall'assistente HP Wireless Assistant. Oppure, HP CPU Assassin, come potrei iniziare a chiamarlo.

Panoramica dell'esperimento

• Questione : Che cosa sta causando il picco di CPU sui portatili HP a intervalli frequenti, in particolare il processo WmiPrvSE.exe _

• Ipotesi : L'assistente HP Wireless Assistant (HPWA) sta causando il problema_

• Metodo :

• Risultati : HPWA sta causando un utilizzo estremo della CPU

• Conclusione : Si dovrebbe disinstallare HPWA perché non fa nulla di utile

Informazioni di base

Quando ho ricevuto il mio portatile HP Pavillion dm4t, ho notato che la CPU spesso raggiungeva un picco di utilizzo fino al 50%, quasi ogni secondo. Questo prosciugava la durata della batteria e riscaldava il portatile; più o meno gli stessi sintomi di Sathya. Semplicemente guardando il Resource Monitor in Windows 7, sono stato in grado di vedere che il processo WmiPrvSE.exe era in difetto.

Una rapida ricerca su Google ha confermato la mia ipotesi che questo fosse il processo host Windows Management Instrumentation (WMI). In breve, WMI può essere usato per cercare informazioni sul sistema, come l'utilizzo del processore, i processi in esecuzione, chi è connesso e ogni sorta di altre informazioni. Il processo host WMI esegue query WMI per qualsiasi altro processo che le produca, quindi WmiPrvSE.exe non era in sé il colpevole, era semplicemente un intermediario.

Per cercare quale specifico processo stava causando questo problema, ho usato Systinternals Process Explorer . Ho trovato quale istanza del processo WmiPrvSE.exe stava usando una grande quantità di CPU, e ho cliccato su di essa per aprire informazioni dettagliate.

Sfortunatamente, non riuscivo a vedere alcun modo per scoprire quale processo stava facendo tutte le query, ma siccome avevo isolato questo come fonte dei picchi della CPU, e sapevo che era un servizio, sono andato al responsabile dei servizi per vedere quali servizi dipendevano da WMI, pensando che questo potesse condurmi ad un altro indizio. Ho pensato che non sarebbe stato un servizio Windows integrato a causare il problema, quindi, eliminando questi, ho deciso di lavorare sulla lista e provare a disabilitare ogni servizio, e vedere se il problema persisteva. Proprio in cima alla lista c'era il servizio di assistenza wireless HP. Sono tornato al menu dei servizi e ho disabilitato quel servizio. Guardando indietro nel task manager, ho visto che l'utilizzo della CPU era arrivato quasi a zero. Ho riattivato il servizio HPWA. L'utilizzo della CPU è stato ripristinato. Ora avevo abbastanza dati per formulare la mia teoria. Ho disinstallato il servizio HPWA e non ho più avuto il problema.

Verifica dell'ipotesi

Diversi mesi dopo, Sathya fa questa domanda. Decisi di dimostrare una volta per tutte che era colpa di HPWA. Ho reinstallato l'assistente HP Wireless Assistant, che non avevo installato da mesi. Subito, l'utilizzo del processore è aumentato. Ho poi portato avanti l'esperimento sopra descritto.

Innanzitutto, ho isolato il processo responsabile del servizio HPWA nel Resource Monitor. HPWA_Service.exe e HPWA_Main.exe sono i due. Ecco com'era l'utilizzo della CPU con entrambi i processi in esecuzione:

Poi, ho sospeso entrambi i processi. L'utilizzo della CPU è sceso immediatamente; ecco come è sembrato dopo pochi istanti il precedente utilizzo della CPU sul grafico per cancellare:

Ho riattivato i processi per vedere se l'utilizzo sarebbe risalito. È successo:

, la sospensione dei processi ha fatto sì che l'utilizzo della CPU tornasse a scendere:

&004 &004

Ho testato questo per un'altra iterazione, e alla terza prova, la stessa identica cosa è successa di nuovo. Ho considerato questa prova sufficiente a dimostrare che l'assistente HP Wireless Assistant stava causando il problema, e successivamente ha disabilitato il servizio, e ora lo disinstallerà.

Tutto ciò che l'HPWA sembra fare è informare l'utente quando il suo wireless è acceso o spento, e trangugiare la CPU. Non c'è niente che non si possa fare con gli strumenti di gestione wireless incorporati, quindi vi consiglio di rimuoverlo se avete installato questo software.

Nota: Almeno una persona ha riferito che la disinstallazione dell'HPWA ha causato l'interruzione del funzionamento del suo interruttore wireless sulla tastiera. Sul mio portatile, ha continuato a funzionare bene dopo la disinstallazione di HPWA, ma nel caso in cui il vostro smetta di funzionare, potete sempre disattivare la scheda wireless dall'interno di Windows. Premere &004+x per aprire il Mobility Center di Windows, quindi fare clic sul pulsante Turn Wireless Off.

&004 &004

Secondo una discussione sui forum di supporto HP, il problema è stato risolto nelle versioni più recenti dell'Assistente HP Wireless. Se il vostro computer portatile ha bisogno di HPWA per utilizzare il wifi on/off è possibile scaricare l'ultima versione dal sito web dei driver di HP, e probabilmente non avrà più questo problema. Tuttavia, se non ne avete bisogno per il pulsante di accensione/spegnimento del wifi, sembra che non ci sia ancora alcun valore aggiunto derivante dall'installazione di questo software.

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! ;-)

La voce del blog Microsoft WMIprvse è un vero cattivo? _ mostra come trovare quale processo è responsabile della CPU che WmiPrvSE.exe sta utilizzando.

Il metodo utilizza l'opzione Event viewer di “Show Analytic and Debug Logs” per tracciare tutte le attività WMI, ottenendo così il processo-id del processo colpevole.

Aggiungendo questo per chiunque altro nella stessa barca, questa pagina è su Google. Ho avuto lo stesso problema con WmiProvderHost che aumentava la CPU fino al 50% e scaricava la batteria del mio Lenovo Yoga2 Pro su Windows 8.1.

In seguito ad alcuni degli eccellenti consigli di indagine di cui sopra, ho scoperto che il problema per me era in realtà GoPro Studio (software di editing video gratuito che viene fornito con le telecamere GoPro). Esso installa un servizio di monitoraggio che aspetta che voi colleghiate la vostra videocamera e per me questo è stato il colpevole.

Per eseguire il debug, usare xperf dal toolkit Windows Performance toolkit ed eseguire questo file 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
``` &001 


Aprire il WMItracing.etl generato in WPA.exe e grag & drop il grafico "Generic Events" dal lato sinistro al pannello di analisi. 


[![enter image description here](https://i.stack.imgur.com/fYgGF.png)](https://i.stack.imgur.com/fYgGF.png) 


Ora filtrare solo gli eventi **Microsoft-Windows-WMI-Activity**, e cercare le operazioni WMI e il ClientProcessId. 


Nel mio esempio questo CLientProcessId appartiene ad uno strumento chiamato **Veeam ONE Monitor Server**. Qui viene mostrato il secondo esempio: 


[![enter image description here](https://i.stack.imgur.com/N9HtQ.png)](https://i.stack.imgur.com/N9HtQ.png) 


HEre si vedono le chiamate ricorrenti di un Processo con PID del 1924 che appartiene al servizio Intel ProSet Monitoring. 


Qui l'uso della CPU viene mostrato anche nei calltacks di campionamento della CPU: 


[![enter image description here](https://i.stack.imgur.com/Go6h2.png)](https://i.stack.imgur.com/Go6h2.png) 



Quindi, lo strumento Intel esegue troppo spesso le query di notifica WMI e questo causa i problemi. [ Fermandolo, ha risolto il problema. ](http://forum.sysinternals.com/forum_posts.asp?TID=30521&PID=143042&title=profsvc-using-significant-cpu-wbemcoredll#143042)

Avete provato a vedere se si tratta di un virus? Ad alcuni virus piace molto sfilare in giro come servizi di Windows come questo. Assicurati che il processo WmiPrvSE.exe si trovi nella directory c:\windows\system32\wbem. In caso contrario, potreste voler eseguire programmi generali di rilevamento di spyware. Se non si tratta di spyware, potrebbe essere un altro servizio a chiamarlo. So di avere qualche gadget veloce in esecuzione sul mio computer e, ironia della sorte, il gadget per il monitoraggio delle prestazioni a volte fa aumentare un po’ la mia CPU. Inoltre, potrebbe essere un altro servizio che ogni tanto preme quel gas. Per esempio, il bloatware di HP, Dell, ecc.

A parte questo, l'altra risposta di TomWij sembra piuttosto carina per la risoluzione dei problemi!