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

Warum bringt der WMI-Provider-Host (WmiPrvSE.exe) meine CPU immer wieder auf Hochtouren?

Ich halte meinen Laptop in der Regel rund um die Uhr in Betrieb, und am Ende des Tages ist es wirklich ärgerlich, wenn ich mir wegen Überhitzung die Oberschenkel verbrannt habe.

Die Überhitzung scheint eine Folge davon zu sein, dass der WMI-Provider-Host (WmiPrvSE.exe) die CPU-Auslastung alle paar Minuten auf 25% erhöht. Warum passiert das?

Ich habe einen HP Envy 14 (mit dem HP gebündelten Mist), der unter Windows 7 Home Premium läuft.

(Hinweis: Basierend auf @nhinkle’s vergangene Beobachtungen scheint HP Wireless Manager der Übeltäter zu sein, gibt es eine Möglichkeit, dies zu bestätigen? )

Diese Frage war eine * Super User Question of the Week . Lesen Sie den 28 Feb 28, 2011 * blog entry für weitere Details oder * submit your own ** Question of the Week.

Antworten (6)

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

Wie Sathya in seiner Frage erwähnte, habe ich bereits Erfahrungen mit diesem Problem auf meinem ähnlichen HP-Laptop gemacht, und ich habe jetzt mit der wissenschaftlichen Methode bestätigt, dass die CPU-Spitzen auf HP-Laptops durch den HP Wireless Assistant verursacht werden. Oder, HP CPU Assassin, wie ich es nennen möchte.

Überblick über das Experiment

  • Frage : Was verursacht die CPU auf HP-Laptops in häufigen Abständen, insbesondere den_ WmiPrvSE.exe Prozess?

  • Hypothese : Der HP Wireless Assistant (HPWA) verursacht das Problem

  • Methode :

  • Ergebnisse : HPWA verursacht eine extreme CPU-Auslastung

  • Schlussfolgerung : HPWA verursacht das Problem

  • Schlussfolgerung : Sie sollten HPWA deinstallieren, da es nichts Nützliches tut

Hintergrundinformationen

Als ich meinen HP Pavillion dm4t Laptop bekam, bemerkte ich, daß die CPU häufig auf bis zu 50% Auslastung anstieg, fast jede zweite Sekunde. Dies führte zu einer Verkürzung der Akkulaufzeit und zu einer Erwärmung des Laptops; die gleichen Symptome wie bei Sathya. Allein durch einen Blick auf den Ressourcenmonitor in Windows 7 konnte ich erkennen, dass der Prozess WmiPrvSE.exe fehlerhaft war.

Eine schnelle Google-Suche bestätigte meine Vermutung, dass es sich um den Windows Management Instrumentation (WMI)-Host-Prozess handelte. Kurz gesagt, WMI kann verwendet werden, um Systeminformationen abzufragen, wie Prozessorauslastung, laufende Prozesse, wer angemeldet ist, und alle möglichen anderen Informationen. Der WMI-Host-Prozess führt WMI-Abfragen für jeden anderen Prozess aus, der sie ausführt, so dass WmiPrvSE.exe nicht selbst der Schuldige war, sondern nur ein Vermittler.

Um herauszufinden, welcher bestimmte Prozess dieses Problem verursacht hat, habe ich Systinternals Process Explorer verwendet. Ich fand heraus, welche Instanz des Prozesses WmiPrvSE.exe eine große Menge an CPU verbrauchte, und klickte darauf, um detaillierte Informationen zu erhalten.

Leider konnte ich keine Möglichkeit sehen, herauszufinden, welcher Prozess alle Anfragen stellte, aber da ich diesen als Quelle der CPU-Spitzen isoliert hatte und wusste, dass es sich um einen Dienst handelte, ging ich zum Dienstmanager, um zu sehen, welche Dienste von WMI abhingen, und dachte, das könnte mich zu einem weiteren Hinweis führen.

Ich dachte mir, dass es kein eingebauter Windows-Dienst sein würde, der das Problem verursacht, also beseitigte ich diese und entschied mich, die Liste abzuarbeiten und zu versuchen, jeden Dienst zu deaktivieren und zu sehen, ob das Problem weiterhin bestand. Ganz oben auf der Liste stand der HP Wireless Assistant Service. Ich ging zurück zum Menü Dienste und deaktivierte diesen Dienst. Als ich im Task-Manager zurückblickte, sah ich, dass die CPU-Auslastung fast auf Null gesunken war. Ich schaltete den HPWA-Dienst wieder ein. Die CPU-Auslastung schoss wieder in die Höhe. Ich hatte jetzt genug Daten für meine Theorie. Ich deinstallierte den HPWA-Dienst und hatte das Problem nie wieder.

Verifizieren der Hypothese

Einige Monate später stellt Sathya diese Frage. Ich beschloss, ein für allemal zu beweisen, dass dies die Schuld von HPWA war. Ich installierte den HP Wireless Assistant neu, den ich seit Monaten nicht mehr installiert hatte. Sofort schoss die Prozessorauslastung in die Höhe. Dann führte ich das oben skizzierte Experiment durch.

Zunächst isolierte ich den für den HPWA-Dienst verantwortlichen Prozess im Ressourcenmonitor. HPWA_Service.exe und HPWA_Main.exe sind die beiden. So sah die CPU-Auslastung aus, wenn beide Prozesse liefen:

Dann setzte ich beide Prozesse aus. Die CPU-Auslastung ging sofort zurück; so sah es nach einigen Augenblicken aus, wenn die vorherige CPU-Auslastung in der Grafik deutlich wurde:

Ich ließ die Prozesse wieder laufen, um zu sehen, ob die Auslastung wieder steigen würde. Das tat es:

Die erste Spitze, als ich HPWA aktivierte,

Kurz nachdem ich HPWA

aktiviert hatte, führte ein erneutes Aussetzen der Prozesse dazu, dass die CPU-Auslastung wieder zurückging:

Ich testete dies für eine weitere Iteration, und beim dritten Versuch passierte genau dasselbe noch einmal. Ich betrachtete dies als ausreichenden Beweis, um zu zeigen, dass der HP Wireless Assistant das Problem verursachte, und deaktivierte daraufhin den Dienst und wird ihn nun deinstallieren.

Der HPWA scheint den Benutzer nur zu informieren, wenn sein Drahtlosgerät ein- oder ausgeschaltet wird, und verschlingt die CPU. Es gibt nichts, was Sie damit tun können, was Sie nicht auch mit den eingebauten drahtlosen Management-Tools tun können, daher würde ich Ihnen raten, diese Software zu entfernen, wenn Sie sie installiert haben.


Hinweis: Mindestens eine Person hat berichtet, dass die Deinstallation von HPWA dazu geführt hat, dass ihr drahtloser Schalter auf der Tastatur nicht mehr funktioniert. Auf meinem Laptop funktionierte er nach der Deinstallation von HPWA weiterhin einwandfrei, aber für den Fall, dass Ihrer doch nicht mehr funktioniert, können Sie die Drahtloskarte jederzeit von Windows aus deaktivieren. Drücken Sie

+x, um das Windows-Mobilitätscenter zu öffnen, und klicken Sie dann auf die Schaltfläche Turn Wireless Off.


Laut einer Diskussion in den HP Support-Foren wurde das Problem in neueren Versionen des HP Wireless Assistant behoben. Wenn Ihr Laptop HPWA benötigt, um die Wifi-Funktion ein-/auszuschalten Schaltfläche können Sie die neueste Version von der HP-Treiber-Website herunterladen und werden dieses Problem wahrscheinlich nicht mehr haben. Wenn Sie sie jedoch nicht für die Wifi-Ein-/Ausschalttaste benötigen, scheint es immer noch keinen Mehrwert zu bringen, diese Software installiert zu haben.

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

Fehlerbehebung

  1. Laden Sie ProcDump von Microsoft Sysinternals herunter.

  2. Lassen Sie es einen Speicherauszug machen, sobald WmiPrvSE.EXE 1 Sekunde lang 25 % erreicht:

  3. Analysieren Sie Ihr(e) Dump(s) online und geben Sie es optional auf SpeedyShare .

  4. Der angezeigte Stack-Trace sollte die Prozedur enthalten, die dies verursacht.

Vielleicht googeln Sie ein paar der obersten Prozeduren des Stacks, um eine bessere Vorstellung davon zu bekommen, was sie tun. Wenn sie nicht helfen, brauchen Sie vielleicht eine weitergehende Analyse. Siehe meinen nächsten Abschnitt:


  1. Laden Sie das Setup von Windows Performance Analysis Tools für Ihre Windows-Version herunter.
  2. Installieren Sie die Software auf Ihrem System.
  3. Öffnen Sie eine Eingabeaufforderung als Administrator , und kopieren Sie den nächsten Befehl:

  4. Drücken Sie ENTER einmal , um den Befehl zu starten, jetzt müssen Sie warten, bis die Spitze aufgetreten ist:

  5. Direkt nach dem Spike gehen Sie zur Konsole und drücken ENTER:

  6. Nachdem Sie einige Zeit gewartet haben, wird eine Protokolldatei myTrace.etl in Ihrem Benutzerordner erzeugt.

  7. führen Sie folgenden Befehl aus, um die Datei anzuzeigen und zu analysieren WinDBG Symbole erforderlich):

Wenn Sie möchten, daß ich mir die Datei ansehe:

  1. Komprimieren Sie myTrace.etl aus Ihrem Benutzerordner in eine Zip-Datei:
  2. Geben Sie die komprimierte Zip-Datei auf SpeedyShare .
  3. Geben Sie den Link hier weiter, ich werde versuchen, die Ursache Ihres Problems zu finden und Ihnen zu zeigen.

Als WmiPrvSE. EXE ein Host zum Ausführen von WMI-Abfragen gegen den CAPI-Speicher ist, können Sie die Ursache selbst mit XPerf aufgrund von IPC möglicherweise nicht finden. Eine andere Lösung, die ich gerade gefunden habe, wäre die Aktivierung der WMI-Protokollierung und Überprüfung der Protokolle wie beschrieben hier , die ClientProcessId wäre die PID des Prozesses, der die WMI-Abfrage gestellt hat. Diese PID kann zum Prozess zurückverfolgt werden, indem eine PID-Spalte zum Task-Manager oder Prozess-Explorer hinzugefügt wird, oder mit tasklist /FI "PID eq X", wobei X die gefundene PID ist…


Analysis of Dump 1 : Zeilen 94-115 zeigen einen Remote Procedure Call an.
Analysis of Dump 2 : Zeilen 84-105 deuten auf einen Remote Procedure Call hin.

Im Kernel wird ein neuer Thread gestartet zur Behandlung eines Remote Procedure Call stub , bei dem es sich im Wesentlichen um eine Anfrage handelt, die der WMI-Provider ausführen und beantworten wird. Dies führt zu einer hohen CPU-Aktivität aufgrund des Lesens der Registrierungs- und/oder Leistungsinformationen.

Da ein Dump eine Aufzeichnung eines einzelnen Moments ist, können Sie nicht sehen, welcher Prozess den RPC ausgeführt hat. Sie benötigen also ein Programm, das wie XPerf verfolgt, um den vorherigen Thread zu sehen, der den RPC ausführen würde.

Oder, wenn Sie RPC-Statusinformationen aktivieren, können Sie rpcdbg verwenden, um zu sehen, wer den Aufruf initiiert hat.

Beispiel:

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]

Das obige Beispiel setzt einen Haltepunkt auf der RPC, so dass Sie in der zweiten Zeile des Stacks sehen können, wer sie ausführt. Aber gut, es ist unwahrscheinlich, dass das Setzen eines Breakpoints beim ersten Aufruf (bitte beachten Sie, dass es sich hier um Live-Debugging handelt) Ihnen helfen wird, jedes Mal zu sehen, wer den WMI-Provider anruft…

In diesem Artikel gibt es noch viel mehr Informationen über RPC State Information , die helfen könnten, aber es ist nichts für schwache Nerven wie uns, all das durchzumachen, wenn wir stattdessen einfach XPerf verwenden könnten :-)


Da wir jetzt wissen, wie die RPC von innen heraus funktioniert, könnten wir auch API Monitor :

  1. API Monitor herunterladen, installieren und starten. ( zweifach wenn Sie 64 Bit haben: einmal x86, einmal x64)
  2. Gehen Sie zu Datei –> Als Administrator ausführen
  3. Setzen Sie den API-Erfassungsfilter auf das Modul Rpcrt4.dll.

  4. Ähnlich wie beim Haltepunkt wollen wir wissen, wer die Funktionen von RpcServerUseProtSeq aufruft:

  5. Haken Sie jeden Laufenden Prozess ein, mit Ausnahme derer mit einem niedrigen PID (um Abstürze zu verhindern). Im Idealfall wollen Sie nicht dwm.exe/winlogon.exe oder niedriger einhängen. Sie könnten auch einzelne Prozesse ausprobieren und sie später aus dem Fenster gehakte Prozesse aushängen…

  6. Wenn alles gut geht, wird der gehakte Prozess, der den RPC-Aufruf macht, Threads enthalten. Und wenn Sie auf diese Threads klicken, sollten Sie einen Haufen von Aufrufen sehen. Wenn Sie das tun, haben Sie den Prozess gefunden, der das Problem verursacht!

Lösung

Es ist wichtig, Ihren Computer auf dem neuesten Stand zu halten, die Installation von HPWA 4.0.10.0 löst das! ;-)

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

Der Microsoft-Blogeintrag Ist WMIprvse ein echter Bösewicht? _ zeigt, wie man herausfindet, welcher Prozess für die CPU verantwortlich ist, die WmiPrvSE.exe verwendet.

Die Methode verwendet die Ereignisanzeige-Option “Analyse- und Debug-Protokolle anzeigen”, um alle WMI-Aktivitäten zu verfolgen und so die Prozess-ID des schuldigen Prozesses zu erhalten.

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

Wenn man dies nur für jemanden im selben Boot hinzufügt, ist diese Seite überall bei Google zu finden. Ich hatte dasselbe Problem mit WmiProvderHost, bei dem die CPU auf bis zu 50 % aufgestockt wurde und der Akku meines Lenovo Yoga2 Pro unter Windows 8.1.

entleert wurde. Nach einigen der ausgezeichneten Untersuchungshinweise oben entdeckte ich, dass das Problem für mich eigentlich GoPro Studio (kostenlose Videobearbeitungssoftware, die mit GoPro-Kameras geliefert wird) war. Es installiert einen Überwachungsdienst, der darauf wartet, dass Sie Ihre Kamera anschließen, und für mich war dies der Übeltäter.

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

Verwenden Sie zum Debuggen xperf aus dem Windows Performance toolkit und führen Sie diese cmd-Datei aus:

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

Öffnen Sie die generierte WMItracing.etl in WPA.exe und ziehen Sie das Diagramm “Generic Events” von der linken Seite in das Analysefenster.

Filtern Sie jetzt nur nach Microsoft-Windows-WMI-Activity-Ereignissen und suchen Sie nach WMI-Operationen und der ClientProcessId.

In meinem Beispiel gehört diese CLientProcessId zu einem Tool namens Veeam ONE Monitor Server. Und das zweite Beispiel wird hier gezeigt:

Hier sehen Sie wiederkehrende Aufrufe eines Prozesses mit der PID von 1924, der zum Intel ProSet Monitoring-Dienst gehört.

Hier wird die CPU-Auslastung auch in den CPU-Sampling-Callstacks angezeigt:

Das Intel-Tool führt also zu oft WMI-Benachrichtigungsabfragen durch, und das verursacht die Probleme. Es wurde gestoppt und das Problem behoben.

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

Haben Sie versucht herauszufinden, ob es sich um ein Virus handelt? Manche Viren stolzieren gerne als Windows-Dienste herum. Stellen Sie sicher, dass sich der Prozess WmiPrvSE.exe im Verzeichnis c:\windows\system32\wbem befindet. Falls nicht, möchten Sie vielleicht allgemeine Programme zur Erkennung von Spyware ausführen. Wenn es sich nicht um Spyware handelt, ist es möglicherweise ein anderer Dienst, der ihn aufruft. Ich weiß, dass ich schnell ein paar Gadgets auf meinem Computer laufen habe, und ironischerweise lässt das Gadget zur Leistungsüberwachung manchmal meine CPU ein wenig in die Höhe schnellen. Es könnte auch ein anderer Dienst sein, der von Zeit zu Zeit auf dieses Gas drückt. Zum Beispiel Bloatware von HP, Dell usw.

Abgesehen davon scheint die andere Antwort von TomWij ziemlich nett zur Fehlerbehebung zu sein!