Fehlerbehebung

Question 1

Wie Sathya in seiner Frage erwähnt hat, hatte ich bereits Erfahrung mit diesem Problem auf meinem ähnlichen HP-Laptop und habe nun mithilfe 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 ihn vielleicht bald nennen werde.

Überblick über das Experiment

Frage:Was verursacht die CPU auf HP Laptops, in regelmäßigen Abständen zu spitzen, insbesondere die WmiPrvSE.exe Verfahren?
Hypothese:Der HP Wireless Assistant (HPWA) verursacht das Problem
Methode:
1. Überprüfen Sie, ob das Problem nach der Installation der HPWA auftritt.
2. Überprüfen Sie, ob die CPU-Auslastung aufhört und der WmiPrvSE.exeProzess nicht mehr mehr als 20 % der CPU-Leistung nutzt, wenn der HPWA-Prozess angehalten wird.
3. Überprüfen Sie, ob die CPU-Leistung wieder zunimmt, wenn der HPWA-Prozess erneut aktiviert wird.
4. Wiederholen Sie die Schritte 2 und 3 für mehrere Versuche, um genaue Ergebnisse sicherzustellen
Ergebnisse:HPWA verursacht eine extreme CPU-Auslastung
Abschluss:Sie sollten HPWA deinstallieren, da es nichts Nützliches tut

Hintergrundinformation

Als ich meinen HP Pavillion dm4t-Laptop bekam, bemerkte ich, dass die CPU-Auslastung häufig auf bis zu 50 % anstieg, fast jede zweite Sekunde. Dies verkürzte die Akkulaufzeit und erhitzte den Laptop; ungefähr dieselben Symptome, die Sathya erlebt hat. Allein durch einen Blick auf den Ressourcenmonitor in Windows 7 konnte ich erkennen, dass der Prozess WmiPrvSE.exeschuld war.

CPU-Nennwert

Eine schnelle Google-Suche bestätigte meine Annahme, dass dies derWindows-Verwaltungsinstrumentation(WMI) Hostprozess. Kurz gesagt kann WMI verwendet werden, um Systeminformationen abzufragen, wie Prozessorauslastung, laufende Prozesse, wer angemeldet ist und alle möglichen anderen Informationen. Der WMI-Hostprozess führt WMI-Abfragen für jeden anderen Prozess aus, der sie stellt, WmiPrvSE.exewar also nicht selbst der Schuldige, sondern lediglich ein Vermittler.

Um herauszufinden, welcher spezifische Prozess dieses Problem verursachte, habe ichSystinternals Prozess-Explorer. Ich habe herausgefunden, welche Instanz des WmiPrvSE.exeProzesses besonders viel CPU-Leistung verbraucht hat, und habe darauf geklickt, um ausführliche Informationen zu öffnen.

Process Explorer

Leider konnte ich keine Möglichkeit erkennen, herauszufinden, welcher Prozess all diese Abfragen durchführte. Da ich diesen Prozess jedoch als Ursache der CPU-Spitzen isoliert hatte und wusste, dass es sich um einen Dienst handelte, ging ich zum Dienste-Manager, um nachzusehen, welche Dienste von WMI abhängig waren. Ich dachte, dass mich das vielleicht zu einer weiteren Spur führen könnte.

Dienstleistungen nom nom

Ich nahm an, dass das Problem nicht durch einen integrierten Windows-Dienst verursacht wurde, also schloss ich diese aus und beschloss, die Liste durchzugehen und zu versuchen, jeden Dienst zu deaktivieren, um 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 Taskmanager zurückschaute, sah ich, dass die CPU-Auslastung fast auf Null gesunken war. Ich schaltete den HPWA-Dienst wieder ein. Die CPU-Auslastung schoss wieder hoch. Ich hatte jetzt genug Daten, um meine Theorie zu bilden. Ich deinstallierte den HPWA-Dienst und hatte das Problem nie wieder.

Überprüfung der Hypothese

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

Zuerst habe ich den Prozess, der für den HPWA-Dienst verantwortlich ist, im Ressourcenmonitor isoliert. HPWA_Service.exeund HPWA_Main.exedas sind die beiden. So sah die CPU-Auslastung aus, wenn beide Prozesse ausgeführt wurden:

Taskmanager mit laufendem hpwa

Dann habe ich beide Prozesse angehalten. Die CPU-Auslastung ging sofort zurück. So sah es nach ein paar Augenblicken aus, bis die vorherige CPU-Auslastung im Diagramm gelöscht war:

Taskmanager ohne ausgeführtes HPWA

Ich habe die Prozesse erneut aktiviert, um zu sehen, ob die Nutzung wieder ansteigen würde. Das ist passiert:

Der Task-Manager hat gerade HPWA aktiviert.
^{Der erste Anstieg, wenn ich HPWA aktiviere}

Task-Manager nach der Aktivierung von hpwa
^{Kurz nachdem ich HPWA aktiviert hatte}

Das erneute Anhalten der Prozesse führte dazu, dass die CPU-Auslastung wieder sank:

geringere CPU-Auslastung nach dem Deaktivieren von hpwa

Ich habe dies noch einmal getestet und beim dritten Versuch ist genau das Gleiche wieder passiert. Ich hielt dies für ausreichenden Beweis dafür, dass der HP Wireless Assistant das Problem verursachte, und habe den Dienst daraufhin deaktiviert. Ich werde ihn jetzt deinstallieren.

Alles, was HPWA zu tun scheint, ist, den Benutzer zu informieren, wenn sein WLAN ein- oder ausgeschaltet wird, und die CPU zu belasten. Sie können damit nichts tun, was Sie nicht auch mit den integrierten Tools zur WLAN-Verwaltung tun können. Ich rate Ihnen daher, diese Software zu entfernen, falls Sie sie installiert haben.

Notiz:Mindestens eine Person hat berichtet, dass der WLAN-Schalter auf der Tastatur nach der Deinstallation von HPWA nicht mehr funktionierte. Auf meinem Laptop funktionierte er nach der Deinstallation von HPWA weiterhin einwandfrei. Sollte Ihr Laptop jedoch nicht mehr funktionieren, können Sie die WLAN-Karte jederzeit in Windows deaktivieren. Drücken Sie + x, um das Windows-Mobilitätscenter zu öffnen, und klicken Sie dann auf die Turn Wireless OffSchaltfläche.

Windows-Mobilitätscenter

Entsprechendeine Diskussionin den HP Support-Foren wurde das Problem in neueren Versionen des HP Wireless Assistant behoben. Wenn Ihr Laptop HPWA benötigt, um den WLAN-Ein-/Ausschalter zu verwenden, können Sie die neueste Version von der Treiber-Website von HP herunterladen und dieses Problem wahrscheinlich nicht mehr haben. Wenn Sie es jedoch nicht für den WLAN-Ein-/Ausschalter benötigen, scheint die Installation dieser Software keinen Mehrwert zu bieten.

Answer

Wie Sathya in seiner Frage erwähnt hat, hatte ich bereits Erfahrung mit diesem Problem auf meinem ähnlichen HP-Laptop und habe nun mithilfe 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 ihn vielleicht bald nennen werde.

Überblick über das Experiment

Frage:Was verursacht die CPU auf HP Laptops, in regelmäßigen Abständen zu spitzen, insbesondere die WmiPrvSE.exe Verfahren?
Hypothese:Der HP Wireless Assistant (HPWA) verursacht das Problem
Methode:
1. Überprüfen Sie, ob das Problem nach der Installation der HPWA auftritt.
2. Überprüfen Sie, ob die CPU-Auslastung aufhört und der WmiPrvSE.exeProzess nicht mehr mehr als 20 % der CPU-Leistung nutzt, wenn der HPWA-Prozess angehalten wird.
3. Überprüfen Sie, ob die CPU-Leistung wieder zunimmt, wenn der HPWA-Prozess erneut aktiviert wird.
4. Wiederholen Sie die Schritte 2 und 3 für mehrere Versuche, um genaue Ergebnisse sicherzustellen
Ergebnisse:HPWA verursacht eine extreme CPU-Auslastung
Abschluss:Sie sollten HPWA deinstallieren, da es nichts Nützliches tut

Hintergrundinformation

Als ich meinen HP Pavillion dm4t-Laptop bekam, bemerkte ich, dass die CPU-Auslastung häufig auf bis zu 50 % anstieg, fast jede zweite Sekunde. Dies verkürzte die Akkulaufzeit und erhitzte den Laptop; ungefähr dieselben Symptome, die Sathya erlebt hat. Allein durch einen Blick auf den Ressourcenmonitor in Windows 7 konnte ich erkennen, dass der Prozess WmiPrvSE.exeschuld war.

CPU-Nennwert

Eine schnelle Google-Suche bestätigte meine Annahme, dass dies derWindows-Verwaltungsinstrumentation(WMI) Hostprozess. Kurz gesagt kann WMI verwendet werden, um Systeminformationen abzufragen, wie Prozessorauslastung, laufende Prozesse, wer angemeldet ist und alle möglichen anderen Informationen. Der WMI-Hostprozess führt WMI-Abfragen für jeden anderen Prozess aus, der sie stellt, WmiPrvSE.exewar also nicht selbst der Schuldige, sondern lediglich ein Vermittler.

Um herauszufinden, welcher spezifische Prozess dieses Problem verursachte, habe ichSystinternals Prozess-Explorer. Ich habe herausgefunden, welche Instanz des WmiPrvSE.exeProzesses besonders viel CPU-Leistung verbraucht hat, und habe darauf geklickt, um ausführliche Informationen zu öffnen.

Process Explorer

Leider konnte ich keine Möglichkeit erkennen, herauszufinden, welcher Prozess all diese Abfragen durchführte. Da ich diesen Prozess jedoch als Ursache der CPU-Spitzen isoliert hatte und wusste, dass es sich um einen Dienst handelte, ging ich zum Dienste-Manager, um nachzusehen, welche Dienste von WMI abhängig waren. Ich dachte, dass mich das vielleicht zu einer weiteren Spur führen könnte.

Dienstleistungen nom nom

Ich nahm an, dass das Problem nicht durch einen integrierten Windows-Dienst verursacht wurde, also schloss ich diese aus und beschloss, die Liste durchzugehen und zu versuchen, jeden Dienst zu deaktivieren, um 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 Taskmanager zurückschaute, sah ich, dass die CPU-Auslastung fast auf Null gesunken war. Ich schaltete den HPWA-Dienst wieder ein. Die CPU-Auslastung schoss wieder hoch. Ich hatte jetzt genug Daten, um meine Theorie zu bilden. Ich deinstallierte den HPWA-Dienst und hatte das Problem nie wieder.

Überprüfung der Hypothese

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

Zuerst habe ich den Prozess, der für den HPWA-Dienst verantwortlich ist, im Ressourcenmonitor isoliert. HPWA_Service.exeund HPWA_Main.exedas sind die beiden. So sah die CPU-Auslastung aus, wenn beide Prozesse ausgeführt wurden:

Taskmanager mit laufendem hpwa

Dann habe ich beide Prozesse angehalten. Die CPU-Auslastung ging sofort zurück. So sah es nach ein paar Augenblicken aus, bis die vorherige CPU-Auslastung im Diagramm gelöscht war:

Taskmanager ohne ausgeführtes HPWA

Ich habe die Prozesse erneut aktiviert, um zu sehen, ob die Nutzung wieder ansteigen würde. Das ist passiert:

Der Task-Manager hat gerade HPWA aktiviert.
^{Der erste Anstieg, wenn ich HPWA aktiviere}

Task-Manager nach der Aktivierung von hpwa
^{Kurz nachdem ich HPWA aktiviert hatte}

Das erneute Anhalten der Prozesse führte dazu, dass die CPU-Auslastung wieder sank:

geringere CPU-Auslastung nach dem Deaktivieren von hpwa

Ich habe dies noch einmal getestet und beim dritten Versuch ist genau das Gleiche wieder passiert. Ich hielt dies für ausreichenden Beweis dafür, dass der HP Wireless Assistant das Problem verursachte, und habe den Dienst daraufhin deaktiviert. Ich werde ihn jetzt deinstallieren.

Alles, was HPWA zu tun scheint, ist, den Benutzer zu informieren, wenn sein WLAN ein- oder ausgeschaltet wird, und die CPU zu belasten. Sie können damit nichts tun, was Sie nicht auch mit den integrierten Tools zur WLAN-Verwaltung tun können. Ich rate Ihnen daher, diese Software zu entfernen, falls Sie sie installiert haben.

Notiz:Mindestens eine Person hat berichtet, dass der WLAN-Schalter auf der Tastatur nach der Deinstallation von HPWA nicht mehr funktionierte. Auf meinem Laptop funktionierte er nach der Deinstallation von HPWA weiterhin einwandfrei. Sollte Ihr Laptop jedoch nicht mehr funktionieren, können Sie die WLAN-Karte jederzeit in Windows deaktivieren. Drücken Sie + x, um das Windows-Mobilitätscenter zu öffnen, und klicken Sie dann auf die Turn Wireless OffSchaltfläche.

Windows-Mobilitätscenter

Entsprechendeine Diskussionin den HP Support-Foren wurde das Problem in neueren Versionen des HP Wireless Assistant behoben. Wenn Ihr Laptop HPWA benötigt, um den WLAN-Ein-/Ausschalter zu verwenden, können Sie die neueste Version von der Treiber-Website von HP herunterladen und dieses Problem wahrscheinlich nicht mehr haben. Wenn Sie es jedoch nicht für den WLAN-Ein-/Ausschalter benötigen, scheint die Installation dieser Software keinen Mehrwert zu bieten.

Question 2

Fehlerbehebung

HerunterladenProcDumpvon Microsoft Sysinternals.
Lassen Sie es einen Dump durchführen, sobald WmiPrvSE.EXE 1 Sekunde lang 25 % erreicht:
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
Dadurch wird ein Dump in Ihrem Benutzerordner erstellt.

Sie können dies ruhig noch 1 bis 2 Mal wiederholen, damit Sie weitere Dumps erhalten und sicher sein können, dass die Ursache behoben wurde und es sich nicht um ein weiteres, normaleres Ereignis handelt.
Analysieren Sie Ihre Dumpsonlineund teilen Sie es optional aufSpeedyShare.

Alternative:WinDBGmit dem Befehl verwendet werden könnte !analyze -v, achten Sie darauf,Symbole festlegen.
Der angezeigte Stapelüberwachungsbericht sollte die Prozedur enthalten, die dies verursacht.

Vielleicht googeln Sie ein paar der wichtigsten Prozeduren des Stacks, um eine bessere Vorstellung davon zu bekommen, was sie bewirken.
Wenn sie nicht helfen, benötigen Sie möglicherweise eine weiterführende Analyse. Siehe meinen nächsten Abschnitt:

Laden Sie das Setup herunter vonWindows-Leistungsanalysetoolsfür Ihre Windows-Version.
Installieren Sie die Software auf Ihrem System.

Öffnen Sie eine Eingabeaufforderungals Administrator, und kopieren Sie den nächsten Befehl:

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

Drücken SieENTER einmalum den Befehl zu starten, müssen Sie jetzt warten, bis der Spike aufgetreten ist.
Gleich nach deinem SpikeSie gehen zur Konsole und drücken ENTER.
Nach einiger Wartezeit wird in Ihrem Benutzerordner eine Protokolldatei myTrace.etl erstellt.
Führen Sie den folgenden Befehl aus, um die Datei anzuzeigen und zu analysieren (WinDBG/Symboleerforderlich):
```
xperf %HOMEPATH%\myTrace.etl
```

Wenn Sie möchten, dass ich der Sache nachgehe:

Komprimieren Sie myTrace.etl aus Ihrem Benutzerordner in eine ZIP-Datei.
Teilen Sie die komprimierte ZIP-Datei aufSpeedyShare.
Teilen Sie den Link hier. Ich werde versuchen, die Ursache Ihres Problems zu finden und Ihnen zu zeigen.

Da WmiPrvSE.EXE ein Host zum Ausführen von WMI-Abfragen an den CAPI-Speicher ist, können Sie die Ursache möglicherweise auch mit XPerf nicht finden, daIPC, eine andere Lösung, die ich gerade gefunden habe, wäre, die WMI-Protokollierung zu aktivieren und die Protokolle wie beschrieben zu überprüfenHier, wäre die ClientProcessId die PID des Prozesses, der die WMI-Abfrage durchgeführt hat. Diese PID kann zum Prozess zurückverfolgt werden, indem dem Task-Manager eine PID-Spalte hinzugefügt wird oderProcess Explorer, oder mit tasklist /FI "PID eq X"wobei X die gefundene PID ist ...

Analyse vonDump 1:Die Zeilen 94-115 zeigen eineRemoteprozeduraufruf.
Analyse vonDump 2:Die Zeilen 84-105 zeigen eineRemoteprozeduraufruf.

Im Kernel wird ein neuer Thread gestartetzur Handhabung eines Remote Procedure Call-Stubs, was im Wesentlichen eine Abfrageanforderung ist, die der WMI-Anbieter ausführt und beantwortet. Dies führt zu einer hohen CPU-Aktivität, da die Registrierungs- und/oder Leistungsinformationen gelesen werden.

Da ein Dump einen einzelnen Moment festhält, können Sie nicht sehen, welcher Prozess den RPC ausgeführt hat.
Sie benötigen also ein Programm wie XPerf, das den vorherigen Thread anzeigt, der den RPC ausgeführt hat.

Oder, wenn SieRPC-Statusinformationen aktivierenkönnen Sierpcdbgum zu sehen, wer den Anruf getätigt 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 dem RPC, sodass Sie sehen, wer es in der zweiten Zeile des Stapels ausführt. Aber es ist unwahrscheinlich, dass das Setzen eines Haltepunkts beim ersten Aufruf (bitte beachten Sie, dass dies Live-Debugging ist) Ihnen hilft zu sehen, wer den WMI-Anbieter jedes Mal aufruft ...

In diesem Artikel finden Sie viele weitere Informationen überRPC-Statusinformationendas könnte helfen, aber es ist nichts für schwache Nerven wie uns, das alles durchzumachen, wenn wir stattdessen einfach XPerf verwenden könnten. :-)

Da wir nun wissen, wie das RPC im Inneren funktioniert, können wir auchAPI-Monitor:

Laden Sie den API Monitor herunter, installieren und starten Sie ihn. _{(zweimalwenn Sie 64 Bit haben: einmal x86, einmal x64)}
Gehe zuDatei-->Als Administrator ausführen
Legen Sie dieAPI-Erfassungsfilterzum Rpcrt4.dllModul.
Ähnlich wie beim Breakpoint möchten wir wissen, wer die RpcServerUseProtSeqFunktionen aufruft:
Haken Sie jedesLaufender Prozessaußer denen mit niedriger PID (um Abstürze zu vermeiden).
Idealerweise sollte man dwm.exe/ winlogon.exeoder lower nicht einhängen.
Man könnte auch einzelne Prozesse ausprobieren und sie später vomAngehängte ProzesseFenster...

Obwohl ... ich habe es probiert und könnte mich an fast jeden Prozess anschließen.
Wenn alles gut geht,Hakenprozessder den RPC-Aufruf ausführt, enthält Threads.
Und wenn Sie auf diese Threads klicken, sollten Sie eine Reihe von Aufrufen sehen.
Wenn das der Fall ist, haben Sie den Prozess gefunden, der das Problem verursacht!

Lösung

Es ist wichtig, dass Sie Ihren Computer auf dem neuesten Stand halten. Installieren SieHPWA 4.0.10.0löst dieses Problem!;-)

Answer

Fehlerbehebung

HerunterladenProcDumpvon Microsoft Sysinternals.
Lassen Sie es einen Dump durchführen, sobald WmiPrvSE.EXE 1 Sekunde lang 25 % erreicht:
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
Dadurch wird ein Dump in Ihrem Benutzerordner erstellt.

Sie können dies ruhig noch 1 bis 2 Mal wiederholen, damit Sie weitere Dumps erhalten und sicher sein können, dass die Ursache behoben wurde und es sich nicht um ein weiteres, normaleres Ereignis handelt.
Analysieren Sie Ihre Dumpsonlineund teilen Sie es optional aufSpeedyShare.

Alternative:WinDBGmit dem Befehl verwendet werden könnte !analyze -v, achten Sie darauf,Symbole festlegen.
Der angezeigte Stapelüberwachungsbericht sollte die Prozedur enthalten, die dies verursacht.

Vielleicht googeln Sie ein paar der wichtigsten Prozeduren des Stacks, um eine bessere Vorstellung davon zu bekommen, was sie bewirken.
Wenn sie nicht helfen, benötigen Sie möglicherweise eine weiterführende Analyse. Siehe meinen nächsten Abschnitt:

Laden Sie das Setup herunter vonWindows-Leistungsanalysetoolsfür Ihre Windows-Version.
Installieren Sie die Software auf Ihrem System.

Öffnen Sie eine Eingabeaufforderungals Administrator, und kopieren Sie den nächsten Befehl:

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

Drücken SieENTER einmalum den Befehl zu starten, müssen Sie jetzt warten, bis der Spike aufgetreten ist.
Gleich nach deinem SpikeSie gehen zur Konsole und drücken ENTER.
Nach einiger Wartezeit wird in Ihrem Benutzerordner eine Protokolldatei myTrace.etl erstellt.
Führen Sie den folgenden Befehl aus, um die Datei anzuzeigen und zu analysieren (WinDBG/Symboleerforderlich):
```
xperf %HOMEPATH%\myTrace.etl
```

Wenn Sie möchten, dass ich der Sache nachgehe:

Komprimieren Sie myTrace.etl aus Ihrem Benutzerordner in eine ZIP-Datei.
Teilen Sie die komprimierte ZIP-Datei aufSpeedyShare.
Teilen Sie den Link hier. Ich werde versuchen, die Ursache Ihres Problems zu finden und Ihnen zu zeigen.

Da WmiPrvSE.EXE ein Host zum Ausführen von WMI-Abfragen an den CAPI-Speicher ist, können Sie die Ursache möglicherweise auch mit XPerf nicht finden, daIPC, eine andere Lösung, die ich gerade gefunden habe, wäre, die WMI-Protokollierung zu aktivieren und die Protokolle wie beschrieben zu überprüfenHier, wäre die ClientProcessId die PID des Prozesses, der die WMI-Abfrage durchgeführt hat. Diese PID kann zum Prozess zurückverfolgt werden, indem dem Task-Manager eine PID-Spalte hinzugefügt wird oderProcess Explorer, oder mit tasklist /FI "PID eq X"wobei X die gefundene PID ist ...

Analyse vonDump 1:Die Zeilen 94-115 zeigen eineRemoteprozeduraufruf.
Analyse vonDump 2:Die Zeilen 84-105 zeigen eineRemoteprozeduraufruf.

Im Kernel wird ein neuer Thread gestartetzur Handhabung eines Remote Procedure Call-Stubs, was im Wesentlichen eine Abfrageanforderung ist, die der WMI-Anbieter ausführt und beantwortet. Dies führt zu einer hohen CPU-Aktivität, da die Registrierungs- und/oder Leistungsinformationen gelesen werden.

Da ein Dump einen einzelnen Moment festhält, können Sie nicht sehen, welcher Prozess den RPC ausgeführt hat.
Sie benötigen also ein Programm wie XPerf, das den vorherigen Thread anzeigt, der den RPC ausgeführt hat.

Oder, wenn SieRPC-Statusinformationen aktivierenkönnen Sierpcdbgum zu sehen, wer den Anruf getätigt 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 dem RPC, sodass Sie sehen, wer es in der zweiten Zeile des Stapels ausführt. Aber es ist unwahrscheinlich, dass das Setzen eines Haltepunkts beim ersten Aufruf (bitte beachten Sie, dass dies Live-Debugging ist) Ihnen hilft zu sehen, wer den WMI-Anbieter jedes Mal aufruft ...

In diesem Artikel finden Sie viele weitere Informationen überRPC-Statusinformationendas könnte helfen, aber es ist nichts für schwache Nerven wie uns, das alles durchzumachen, wenn wir stattdessen einfach XPerf verwenden könnten. :-)

Da wir nun wissen, wie das RPC im Inneren funktioniert, können wir auchAPI-Monitor:

Laden Sie den API Monitor herunter, installieren und starten Sie ihn. _{(zweimalwenn Sie 64 Bit haben: einmal x86, einmal x64)}
Gehe zuDatei-->Als Administrator ausführen
Legen Sie dieAPI-Erfassungsfilterzum Rpcrt4.dllModul.
Ähnlich wie beim Breakpoint möchten wir wissen, wer die RpcServerUseProtSeqFunktionen aufruft:
Haken Sie jedesLaufender Prozessaußer denen mit niedriger PID (um Abstürze zu vermeiden).
Idealerweise sollte man dwm.exe/ winlogon.exeoder lower nicht einhängen.
Man könnte auch einzelne Prozesse ausprobieren und sie später vomAngehängte ProzesseFenster...

Obwohl ... ich habe es probiert und könnte mich an fast jeden Prozess anschließen.
Wenn alles gut geht,Hakenprozessder den RPC-Aufruf ausführt, enthält Threads.
Und wenn Sie auf diese Threads klicken, sollten Sie eine Reihe von Aufrufen sehen.
Wenn das der Fall ist, haben Sie den Prozess gefunden, der das Problem verursacht!

Lösung

Es ist wichtig, dass Sie Ihren Computer auf dem neuesten Stand halten. Installieren SieHPWA 4.0.10.0löst dieses Problem!;-)

Question 3

Der Microsoft-BlogeintragIst WMIprvse ein echter Bösewicht?zeigt, wie Sie herausfinden, welcher Prozess für die von WmiPrvSE.exe verwendete CPU verantwortlich ist.

Die Methode verwendet die Ereignisanzeigeoption „Analyse- und Debugprotokolle anzeigen“, um alle WMI-Aktivitäten zu verfolgen und so die Prozess-ID des fehlerhaften Prozesses zu ermitteln.

Answer

Der Microsoft-BlogeintragIst WMIprvse ein echter Bösewicht?zeigt, wie Sie herausfinden, welcher Prozess für die von WmiPrvSE.exe verwendete CPU verantwortlich ist.

Die Methode verwendet die Ereignisanzeigeoption „Analyse- und Debugprotokolle anzeigen“, um alle WMI-Aktivitäten zu verfolgen und so die Prozess-ID des fehlerhaften Prozesses zu ermitteln.

Question 4

Um es zu debuggen, verwenden Sie xperf aus demWindows-Leistungstoolkitund führen Sie diese Befehlsdatei 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 Datei WMItracing.etl in WPA.exe und ziehen Sie das Diagramm „Allgemeine Ereignisse“ per Drag & Drop von der linken Seite in den Analysebereich.

Filtern Sie nun nachMicrosoft-Windows-WMI-AktivitätNur Ereignisse und suchen Sie nach WMI-Operationen und der ClientProcessId.

In meinem Beispiel gehört diese CLientProcessId zu einem Tool namensVeeam ONE Monitor Server.Durch das Stoppen wurde das Problem der CPU-Auslastung behoben.

Und hier wird ein zweites Beispiel gezeigt:

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

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

Daher führt das Intel-Tool zu häufig WMI-Benachrichtigungsabfragen durch und dies verursacht die Probleme.Durch das Stoppen wurde das Problem behoben.

Answer

Um es zu debuggen, verwenden Sie xperf aus demWindows-Leistungstoolkitund führen Sie diese Befehlsdatei 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 Datei WMItracing.etl in WPA.exe und ziehen Sie das Diagramm „Allgemeine Ereignisse“ per Drag & Drop von der linken Seite in den Analysebereich.

Filtern Sie nun nachMicrosoft-Windows-WMI-AktivitätNur Ereignisse und suchen Sie nach WMI-Operationen und der ClientProcessId.

In meinem Beispiel gehört diese CLientProcessId zu einem Tool namensVeeam ONE Monitor Server.Durch das Stoppen wurde das Problem der CPU-Auslastung behoben.

Und hier wird ein zweites Beispiel gezeigt:

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

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

Daher führt das Intel-Tool zu häufig WMI-Benachrichtigungsabfragen durch und dies verursacht die Probleme.Durch das Stoppen wurde das Problem behoben.

Fehlerbehebung

Antwort1

Überblick über das Experiment

Hintergrundinformation

Überprüfung der Hypothese

Antwort2

Fehlerbehebung

Lösung

Antwort3

Antwort4

verwandte Informationen