Zoals Sathya in zijn vraag aangaf, heb ik al eerder ervaring opgedaan met dit probleem op mijn soortgelijke HP laptop, en ik heb nu met behulp van de wetenschappelijke methode bevestigd dat de CPU-pieken op HP laptops veroorzaakt worden door de HP Wireless Assistant. Of, HP CPU Assassin, zoals ik het mag gaan noemen.

Overview of the Experiment

• Question : Wat veroorzaakt de CPU op HP laptops met frequente tussenpozen, met name het WmiPrvSE.exe _proces? _

• Hypothese : De HP Wireless Assistant (HPWA) veroorzaakt het probleem

• Methode :

• Resultaten : HPWA veroorzaakt extreem CPU-gebruik

• Conclusie : Je moet HPWA verwijderen omdat het niets nuttigs doet

Achtergrondinformatie

Toen ik mijn HP Pavillion dm4t laptop kreeg, merkte ik dat de CPU vaak tot 50% gebruik piekerde, bijna elke andere seconde. Dit was het leeglopen van de batterij en het opwarmen van de laptop; veel van dezelfde symptomen als Sathya heeft ondervonden. Alleen al door naar de Resource Monitor in Windows 7 te kijken, kon ik zien dat het proces WmiPrvSE.exe fout was.

Een snelle zoekopdracht bevestigde mijn veronderstelling dat dit het [ Windows Management Instrumentation ](http://msdn.microsoft.com/en-us/library/aa394582(v=vs.85).aspx] (WMI) hostproces was. Kortom, WMI kan worden gebruikt om te zoeken naar systeeminformatie, zoals processorgebruik, lopende processen, wie is ingelogd en allerlei andere informatie. Het WMI hostproces draait WMI-vragen voor elk ander proces waardoor ze worden gemaakt, dus WmiPrvSE.exe was zelf niet de boosdoener, het was gewoon een tussenpersoon.

Om te achterhalen welk specifiek proces dit probleem veroorzaakte, gebruikte ik Systinternals Process Explorer . Ik vond welke instantie van het WmiPrvSE.exe proces een grote hoeveelheid CPU gebruikte, en klikte erop om gedetailleerde informatie te openen.

Helaas kon ik geen enkele manier zien om erachter te komen welk proces alle queries maakte, maar omdat ik dit had geïsoleerd als de bron van de CPU-pieken, en wist dat het een service was, ging ik naar de services manager om te zien welke services afhankelijk waren van WMI, denkend dat dit mij naar een andere aanwijzing zou kunnen leiden.

Verificatie van de hypothese

Enkele maanden later stelt Sathya deze vraag. Ik besloot om eens en voor altijd te bewijzen dat dit de fout van HPWA was. Ik heb de HP Wireless Assistant opnieuw geïnstalleerd, die ik in maanden niet had geïnstalleerd. Het gebruik van de processor schoot meteen omhoog. Vervolgens ging ik door met het hierboven beschreven experiment.

Eerst isoleerde ik het proces dat verantwoordelijk is voor de HPWA-service in de Resource Monitor. HPWA_Service.exe en HPWA_Main.exe zijn de twee. Hier is hoe het CPU-gebruik eruitzag met beide verwerkte processen:

Vervolgens heb ik beide processen opgeschort. Het CPU gebruik ging meteen naar beneden; hier is hoe het er na een paar momenten uitzag voor het vorige CPU gebruik op de grafiek om te wissen:

Ik stelde de processen weer in staat om te zien of het gebruik weer omhoog zou gaan. Dat deed het:

had aangezet tot het opnieuw opschorten van de processen resulteerde in een terugval van het CPU gebruik:

Ik testte dit nog een keer voor een iteratie, en bij de derde trial gebeurde precies hetzelfde. Ik beschouwde dit als voldoende bewijs om aan te tonen dat de HP Wireless Assistant het probleem veroorzaakte, en schakelde vervolgens de service uit, en zal deze nu verwijderen.

Het enige wat de HPWA lijkt te doen is de gebruiker te informeren wanneer hun wireless aan of uit wordt gezet, en de CPU op te slurpen. Er is niets wat je er niet mee kunt doen dat je niet kunt doen met de ingebouwde draadloze beheertools, dus ik raad je aan om deze software te verwijderen als je deze hebt geïnstalleerd.

• *

Aanwijzing: Ten minste één persoon heeft gemeld dat het verwijderen van HPWA ervoor heeft gezorgd dat hun draadloze schakelaar op het toetsenbord is gestopt met werken. Op mijn laptop bleef het prima werken na het verwijderen van HPWA, maar in het geval dat de jouwe wel stopt met werken, kun je de draadloze kaart altijd uitschakelen vanuit Windows. Druk op

• *

Volgens een discussie op de HP Support Forums is het probleem opgelost in recentere versies van de HP Wireless Assistant. Als uw laptop HPWA nodig heeft om de wifi aan/uit te gebruiken knop, kunt u de laatste versie downloaden van HP’s drivers website, en zal waarschijnlijk dit probleem niet meer hebben. Als u het echter niet nodig heeft voor de wifi aan/uit-knop, lijkt het nog steeds geen toegevoegde waarde te hebben om deze software te laten installeren.

Troubleshooting

1. Download ProcDump van Microsoft Sysinternals.

2. Laat het een dump nemen zodra de WmiPrvSE.EXE 25% voor 1 seconde raakt:

3. 1. Analyseer uw dump(s) online en deel deze desgewenst op SpeedyShare .

4. De stapel die wordt weergegeven moet de procedure bevatten die dit veroorzaakt.

Misschien google je een paar van de topprocedures van de stapel om een beter idee te krijgen wat ze doen. Als ze je niet helpen, heb je misschien een geavanceerdere analyse nodig. Zie mijn volgende sectie:

• *

1. Download de setup van Windows Performance Analysis Tools voor uw Windows versie.
2. 2. Installeer de software op uw systeem.

3. Download de software van Windows Performance Analysis Tools voor uw Windows versie. 3. Open een opdrachtprompt ** als beheerder** , en kopieer de volgende opdracht:

4. 1. Druk op ENTER once om de opdracht te starten, nu moet u wachten tot de piek is opgetreden.

5. Rechts na de spike gaat u naar de console en drukt u op ENTER.

6. Na enige tijd te hebben gewacht wordt er een logbestand myTrace.etl aangemaakt in uw gebruikersmap.

7. Voer het volgende commando uit om het bestand te tonen en te analyseren WinDBG Symbolen vereist):

Als u wilt dat ik er naar kijk:

1. 1. Druk myTrace.etl uit uw gebruikersmap naar een zip-bestand.
2. 2. Deel het gecomprimeerde zip-bestand op SpeedyShare .
3. 3. Deel de link hier, ik zal proberen de oorzaak van je probleem te vinden en te laten zien.

• *

Als WmiPrvSE. EXE is een host voor het uitvoeren van WMI-query’s tegen de CAPI-winkel, kunt u misschien de oorzaak niet vinden, zelfs niet met XPerf vanwege IPC , een andere oplossing die ik net heb gevonden zou zijn om WMI-logging mogelijk te maken en de logs te controleren zoals beschreven hier , de ClientProcessId zou het PID van het proces zijn dat de WMI-query heeft gemaakt. Dit PID kan worden teruggevoerd naar het proces door een PID-kolom toe te voegen aan Taakbeheer of Procesverkenner , of met tasklist /FI "PID eq X" waarbij X het PID is dat u hebt gevonden…

• *

Analyse van Dump 1 : Lijnen 94-115 geven een Remote Procedure Call aan.
Analyse van Dump 2: De lijnen 84-105 geven een [ Remote Procedure Call ](http://technet.microsoft.com/en-us/library/cc738291(WS.10).

In de Kernel wordt een nieuwe draad gestart om een Remote Procedure Call stub .aspx) te behandelen, wat in wezen een vraag is die de WMI-provider zal uitvoeren en beantwoorden. Dit resulteert in een hoge CPU-activiteit vanwege het lezen van de register- en/of prestatie-informatie.

Als een dump is een opname van een enkel moment zul je niet in staat zijn om te zien welk proces de RPC heeft uitgevoerd. Dus, je hebt een programma nodig dat trackteren zoals XPerf om de vorige thread te zien die de RPC zou doen.

Of, als u RPC State Information inschakelt, kunt u rpcdbg gebruiken om te zien wie de oproep heeft geïnitieerd.

Voorbeeld:

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]

Het bovenstaande voorbeeld stelt een breekpunt in op de RPC, zodat u kunt zien wie deze in de tweede regel van de stack uitvoert. Maar goed, het is onwaarschijnlijk dat het instellen van een breekpunt op de eerste oproep (let op: dit is live debugging) je zal helpen om te zien wie de WMI Provider elke keer belt…

Er staat veel meer informatie in dat artikel over RPC State Information dat zou kunnen helpen, maar het is niet voor de zwakzinnigen zoals wij om dat allemaal door te nemen als we gewoon XPerf zouden kunnen gebruiken. :-)

• *

Zoals we nu weten over de innerlijke werking van de RPC, zouden we net zo goed API Monitor :

1 kunnen gebruiken. 1. Download, installeer en start API Monitor. ( tweemaal als u 64 bit heeft: eenmaal x86, eenmaal x64) 2. 2. Ga naar File –> Run als beheerder 3. 3. Stel het API Capture Filter in op de module Rpcrt4.dll.

1. Net als bij het breekpunt willen we weten wie de RpcServerUseProtSeq-functies aanroept:

2. Haak elk Running Process aan, behalve die met een lage PID (om crashes te voorkomen). Ideaal, u wilt dwm.exe/winlogon.exe niet aanhaken of lager. U kunt ook enkele processen proberen en ze later loskoppelen uit het venster Hooked Processes…

3. Als alles goed gaat, zal het Hooked Process dat de RPC-oproep maakt, threads bevatten. En als u op deze threads klikt, zou u een heleboel oproepen moeten zien. Als u dat doet, hebt u het proces gevonden dat het probleem veroorzaakt!

Oplossing

Het up-to-date houden van uw computer is belangrijk, het installeren van [ HPWA 4.0.10.0 ]&003 lost dit op! ;-)

De Microsoft blog entry Is WMIprvse een echte schurk? _ laat zien hoe je kunt vinden welk proces verantwoordelijk is voor de CPU die WmiPrvSE.exe gebruikt.

De methode maakt gebruik van de Event viewer optie van “Show Analytic and Debug Logs” om alle WMI activiteiten te traceren, waardoor het proces-id van het schuldige proces wordt verkregen.

Als je dit voor iemand anders in hetzelfde schuitje toevoegt, staat deze pagina overal in Google. Ik had hetzelfde probleem met WmiProvderHost spiking CPU tot 50% en het leeglopen van de batterij op mijn Lenovo Yoga2 Pro op Windows 8.1.

Na een aantal van de uitstekende onderzoeksadviezen hierboven, ontdekte ik dat het probleem voor mij eigenlijk GoPro Studio (gratis videobewerkingssoftware die wordt geleverd met GoPro-camera’s) was. Het installeert een bewakingsdienst die wacht tot je je camera aansluit en voor mij was dit de boosdoener.

Om het te debuggen gebruikt u xperf uit de Windows Performance toolkit en voert u dit cmd-bestand uit:

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

Open de gegenereerde WMItracing.etl in WPA.exe en grag & drop de “Generic Events”-grafiek van de linkerzijde naar het analysevenster.

Filter nu alleen naar Microsoft-Windows-WMI-Activity events, en zoek naar WMI-bewerkingen en de ClientProcessId.

In mijn voorbeeld behoort deze CLientProcessId tot een tool genaamd Veeam ONE Monitor Server.

en tweede voorbeeld wordt hier getoond:

Hier wordt ook het CPU-gebruik getoond in de CPU-sampling callstacks:

Dus de Intel-tool doet te vaak WMI-meldingen en dit veroorzaakt de problemen. Stoppen, het probleem oplossen.

Heb je geprobeerd te zien of het een virus is? Sommige virussen houden er echt van om rond te paraderen als dergelijke Windows-services. Zorg ervoor dat het WmiPrvSE.exe proces zich in de c:\windows\system32\wbem directory bevindt. Zo niet, dan wilt u misschien algemene spyware detectieprogramma’s uitvoeren. Als het geen spyware is, kan het misschien een andere service zijn die het noemt. Ik weet dat ik snel een paar gadgets op mijn computer heb draaien, en ironisch genoeg maakt de prestatiemonitor gadget mijn CPU soms een beetje piekerig. Het zou ook een andere dienst kunnen zijn die af en toe op dat gas drukt. Bijvoorbeeld bloatware van HP, Dell, etc.

Verder lijkt het andere antwoord van TomWij aardig voor het oplossen van problemen!