2011-02-02 12:36:08 +0000 2011-02-02 12:36:08 +0000
88
88

Dlaczego WMI Provider Host (WmiPrvSE.exe) zachować spiking mój procesor?

Ogólnie trzymam mój laptop na 24x7, a pod koniec dnia to jest naprawdę irytujące mieć moje uda spalone, bo przegrzanie.

Przegrzanie wydaje się być wynikiem WMI Provider Host (WmiPrvSE.exe) spiking wykorzystanie procesora do 25% co kilka minut. Dlaczego tak się dzieje?

Mam HP Envy 14 (z dołączonym HP badziewiem) uruchomiony na Windows 7 Home Premium.

(Uwaga: Na podstawie @nhinkle’s poprzednie obserwacje , wydaje się, że HP Wireless Manager może być winny, czy jest jakiś sposób, aby to potwierdzić? )

This question was a * Super User Question of the Week . Read the Feb 28, 2011 * blog entry for more details or * submit your own ** Question of the Week.

Odpowiedzi (6)

110
110
110
2011-02-05 23:05:12 +0000

Jak wspomniał Sathya w swoim pytaniu, miałem wcześniejsze doświadczenia z tym problemem na moim podobnym laptopie HP, a teraz potwierdziłem przy użyciu metody naukowej, że skokowe zmiany CPU na laptopach HP są spowodowane przez HP Wireless Assistant. Albo, HP CPU Assassin, jak mogę zacząć go nazywać.

Overview of the Experiment

  • Question : Co powoduje, że procesor w laptopie HP skręca w częstych odstępach czasu, a konkretnie proces WmiPrvSE.exe procesu?

  • Hipoteza : Asystent HP Wireless Assistant (HPWA) powoduje problem

  • Metoda :

  • Wyniki : HPWA powoduje ekstremalne zużycie procesora

  • Włączenie : Powinieneś odinstalować HPWA, ponieważ nie robi ono nic użytecznego

Background information

Kiedy dostałem mojego laptopa HP Pavillion dm4t, zauważyłem, że procesor często skakał aż do 50% zużycia, prawie co drugą sekundę. Było to wyczerpanie baterii i rozgrzanie laptopa; wiele takich samych objawów jak Sathya. Wystarczyło spojrzeć na Resource Monitor w Windows 7, byłem w stanie zobaczyć, że proces WmiPrvSE.exe był wadliwy.

Szybkie wyszukiwanie google potwierdziło moje założenie, że był to Windows Management Instrumentation (WMI) proces hosta. Krótko mówiąc, WMI może być używany do wyszukiwania informacji systemowych, takich jak użycie procesora, uruchomione procesy, kto jest zalogowany, i wszelkiego rodzaju innych informacji. Proces hosta WMI uruchamia zapytania WMI dla każdego innego procesu, który je wykonuje, więc WmiPrvSE.exe sam nie był winowajcą, był po prostu pośrednikiem.

W celu odszukania, który konkretny proces powodował ten problem, użyłem Systinternals Process Explorer . Znalazłem, która instancja procesu WmiPrvSE.exe wykorzystywała dużą ilość procesora i kliknąłem na nią, aby otworzyć szczegółowe informacje.

Niestety nie widziałem żadnego sposobu, aby dowiedzieć się, jaki proces wykonywał wszystkie zapytania, ale ponieważ wyizolowałem to jako źródło skoków procesora i wiedziałem, że to usługa, poszedłem do menedżera usług, aby zobaczyć, które usługi zależą od WMI, myśląc, że może to doprowadzić mnie do innej wskazówki.

Pomyślałem, że to nie będzie wbudowana usługa Windows powodująca problem, więc eliminując te, postanowiłem pracować w dół listy i spróbować wyłączyć każdą usługę, i zobaczyć, czy problem się utrzymuje. Bezpośrednio na szczycie listy znajdowała się usługa HP Wireless Assistant Service. Wróciłem do menu usług i wyłączyłem tę usługę. Spoglądając wstecz na menedżera zadań, zobaczyłem, że wykorzystanie procesora poszło prawie na marne. Wróciłem do usługi HPWA. Zużycie procesora spadło. Miałem teraz wystarczająco dużo danych, by stworzyć swoją teorię. Odinstalowałem usługę HPWA i już nigdy nie miałem tego problemu.

Verifying the Hypothesis

Kilka miesięcy później Sathya zadał mi to pytanie. Postanowiłem udowodnić raz na zawsze, że to była wina HPWA. Ponownie zainstalowałem Asystenta HP Wireless Assistant, którego nie miałem zainstalowanego od miesięcy. Zaraz, użycie procesora wystrzeliło. Następnie przeprowadziłem eksperyment opisany powyżej.

Najpierw wyizolowałem proces odpowiedzialny za usługę HPWA w Resource Monitor. HPWA_Service.exe i HPWA_Main.exe to dwa. Oto jak wyglądało wykorzystanie procesora przy uruchomieniu obu tych procesorów:

Następnie zawiesiłem oba procesy. Zużycie procesora od razu spadło; oto jak wyglądało po kilku chwilach poprzedniego zużycia procesora na wykresie, aby wyczyścić:

Włączyłem procesy ponownie, aby sprawdzić, czy zużycie wróci do góry. Tak było:

Pierwszy skok po włączeniu HPWA

A little while after I enabled HPWA

Zawieszenie procesów ponownie spowodowało cofnięcie się wykorzystania procesora:

Przetestowałem to jeszcze raz iteracja, a podczas trzeciej próby, ta sama dokładna rzecz zdarzyła się ponownie. Uznałem to za wystarczający dowód na to, że HP Wireless Assistant spowodował problem, a następnie wyłączył usługę, a teraz odinstaluje ją.

Wszystko, co HPWA wydaje się robić, to poinformować użytkownika, gdy ich bezprzewodowy jest włączony lub wyłączony, i gobble CPU. Nie ma nic, czego nie można zrobić z wbudowanymi narzędziami do zarządzania połączeniami bezprzewodowymi, więc radzę, abyś usunął to oprogramowanie, jeśli masz je zainstalowane.


Uwaga: Przynajmniej jedna osoba zgłosiła, że odinstalowanie HPWA spowodowało, że ich przełącznik bezprzewodowy na klawiaturze przestał działać. W moim laptopie, po odinstalowaniu HPWA działało ono nadal dobrze, ale w przypadku, gdy Twoje przestanie działać, zawsze możesz wyłączyć kartę bezprzewodową z wnętrza Windows. Naciśnij

+x, aby otworzyć Windows Mobility Center, a następnie kliknij przycisk Turn Wireless Off.

  • *

Według dyskusji na forum pomocy technicznej HP, problem został rozwiązany w nowszych wersjach Asystenta bezprzewodowego HP. Jeśli Twój laptop potrzebuje HPWA, aby korzystać z wifi on/off możesz pobrać najnowszą wersję ze strony internetowej sterowników HP, i prawdopodobnie nie będziesz miał już tego problemu. Niemniej jednak, jeśli nie potrzebujesz go do przycisku wifi on/off, nadal wydaje się, że nie ma żadnej wartości dodanej z posiadania tego oprogramowania zainstalowanego.

38
38
38
2011-02-02 13:11:14 +0000

Troubleshooting

  1. Download ProcDump van Microsoft Sysinternals.

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

    1. Analyseer uw dump(s) online en deel deze desgewenst op SpeedyShare .
  3. 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:

    1. Druk op ENTER once om de opdracht te starten, nu moet u wachten tot de piek is opgetreden.
  4. Rechts na de spike gaat u naar de console en drukt u op ENTER.

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

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

13
13
13
2011-02-06 19:14:14 +0000

Wpis na blogu Microsoftu Is WMIprvse a real villain? _ pokazuje jak znaleźć proces, który jest odpowiedzialny za procesor, którego używa WmiPrvSE.exe.

Metoda używa opcji Event viewer “Show Analytic and Debug Logs”, aby śledzić całą aktywność WMI, dzięki czemu proces staje się niewinny.

7
7
7
2014-11-14 08:17:34 +0000

Po prostu dodaj to dla wszystkich innych w tej samej łodzi, ta strona jest cała w Google. Miałem ten sam problem z procesorem WmiProvderHost z procesorem skokowym do 50% i rozładowującym baterię na moim Lenovo Yoga2 Pro w systemie Windows 8.1.

Po zapoznaniu się z kilkoma doskonałymi poradami dotyczącymi badania, odkryłem, że problemem dla mnie było właściwie GoPro Studio (darmowe oprogramowanie do edycji wideo, które jest dostarczane z kamerami GoPro). Instaluje ono usługę monitoringu, która czeka na Ciebie, aby podłączyć kamerę, a dla mnie był to winowajca.

4
4
4
2015-08-02 16:07:23 +0000

Aby go debugować, użyj xperf z Windows Performance toolkit i uruchom ten plik 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

Otwórz wygenerowany WMItracing.etl w WPA.exe i grag & drop the “Generic Events” graph from the left side to the analysis pane.

Teraz filtruj tylko do zdarzeń Microsoft-Windows-WMI-Activity i wyszukaj operacje WMI oraz ClientProcessId.

W moim przykładzie ten CLientProcessId należy do narzędzia o nazwie Veeam ONE Monitor Server. Stopping it, fixed the CPU usage issue .

And second example is shown here:

HEre you see reocurring calls of a Process with PID of 1924 which belongs to the Intel ProSet Monitoring service.

Here the CPU usage is also shown in the CPU sampling callstacks:

So, the Intel tool does WMI notification queries too often and this causes the problems. Zatrzymanie go, naprawienie problemu.

1
1
1
2011-02-02 13:36:08 +0000

Próbowałeś zobaczyć, czy to wirus? Niektóre wirusy naprawdę lubią paradować, jak serwisy Windows takie jak ten. Upewnij się, że proces WmiPrvSE.exe znajduje się w katalogu c:\windows\system32\wbem. Jeśli nie, możesz uruchomić ogólne programy wykrywające oprogramowanie szpiegujące. Jeśli nie jest to oprogramowanie szpiegujące, może to być inna usługa, która je wywołuje. Wiem, że mam kilka szybkich gadżetów działających na moim komputerze, i jak na ironię gadżet monitora wydajnościowego czasami sprawia, że mój procesor trochę przyspiesza. Ponadto, może to być inna usługa, która co jakiś czas wciska ten gaz. Na przykład, bloatware z HP, Dell, itp.

Poza tym, druga odpowiedź od TomWij wydaje się całkiem miła dla rozwiązywania problemów!