Fehlersuche

1. Laden Sie ProcDump von Microsoft Sysinternals herunter.

2. Lassen Sie es einen Dump einmal die WmiPrvSE nehmen.EXE trifft 25% für 1 Sekunde:

   procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
   

   Dadurch wird ein Speicherauszug in Ihrem Benutzerordner erstellt.

   Fühlen Sie sich frei, dies noch 1-2 Mal zu wiederholen, damit Sie mehr Dumps haben und sicher sein können, dass die Ursache abgeladen wird und nicht ein anderes normaleres Ereignis.

3. Analysieren Sie Ihre dump(en) online und teilen Sie es optional auf SpeedyShare.

   Alternative: WinDbg könnte mit dem Befehl !analyze -v verwendet werden, stellen Sie sicher, dass Symbole.

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

Vielleicht googeln Sie einige der obersten Prozeduren des Stapels, um eine bessere Vorstellung davon zu bekommen, was sie tun.
Wenn sie nicht helfen, benötigen Sie möglicherweise eine erweiterte Analyse. Siehe meine nächste 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:

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

4. Drücken Sie ENTER sobald, um den Befehl zu starten, müssen Sie jetzt warten, bis der Spike aufgetreten ist.

5. Gleich nach deiner Spitze gehst du zur Konsole und drücken Sie ENTER.
6. Nach einiger Zeit eine Protokolldatei myTrace warten.etl wird in Ihrem Benutzerordner erstellt.

7. Führen Sie den folgenden Befehl aus, um die Datei anzuzeigen und zu analysieren (WinDbg/Symbole erforderlich):

   xperf %HOMEPATH%\myTrace.etl
   

Wenn du willst, dass ich es mir ansehe:

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

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

Analyse von Dump 1: Die Zeilen 94-115 zeigen einen Remote Procedure Call an.
Analyse von Dump 2: Die Zeilen 84-105 zeigen einen Remote Procedure Call an.

Im Kernel wird ein neuer Thread gestartet , um eine Remote-Prozedur zu verarbeiten Rufen Sie stub auf, bei dem es sich im Wesentlichen um eine Abfrageanforderung handelt, die der WMI-Anbieter ausführt und darauf antwortet. Dies führt zu einer hohen CPU-Aktivität aufgrund des Lesens der Registrierungs-und / oder Leistungsinformationen.

Da ein Dump eine Erfassung 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 anzuzeigen, der den RPC ausführt.

Oder, wenn Sie RPC-Statusinformationen aktivieren, Sie kann rpcdbg verwenden, um zu sehen, wer den Anruf 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 legt einen Haltepunkt für den RPC fest, sodass Sie sehen können, wer ihn in der zweiten Stapelzeile ausführt. Es ist jedoch unwahrscheinlich, dass das Festlegen eines Haltepunkts beim ersten Anruf (bitte beachten Sie, dass dies ein Live-Debugging ist) Ihnen hilft, jedes Mal zu sehen, wer den WMI-Anbieter anruft...

Es gibt viel mehr Informationen in diesem Artikel über RPC-Statusinformationen, die helfen könnten, aber es ist nicht für schwache Nerven wie uns, all das zu durchlaufen, wenn wir stattdessen nur XPerf verwenden könnten. :-)

Wie wir jetzt über die innere Funktionsweise des RPC wissen, können wir auch API Monitor:

1. API Monitor herunterladen, installieren und starten. _{(zweimal wenn Sie 64 Bit haben: einmal x86, einmal x64)}
2. Gehe zu Datei --> Als Administrator ausführen

3. Legen Sie die API-Erfassung fest Filtern Sie nach dem Modul Rpcrt4.dll.

   

4. Ähnlich wie beim Haltepunkt möchten wir wissen, wer die Funktionen RpcServerUseProtSeq aufruft:

   

5. Haken jedes Laufenden Prozess außer für diejenigen mit einem niedrigen PID (um Abstürze zu verhindern).
   Ideal, Sie wollen nicht haken dwm.exe/winlogon.exe oder niedriger.
   Sie können auch einzelne Prozesse ausprobieren und sie später aus dem Fenster Hooked Processes...

   Obwohl... Ich habe versuchte es und konnte über jeden Prozess Haken.

6. Wenn alles gut geht, enthält der mit verbundene Prozess, der den RPC-Aufruf ausführt, Threads.
   Und wenn Sie auf diese Threads klicken, sollten Sie eine Reihe von Aufrufen sehen.
   Wenn Sie dies tun, haben Sie den Prozess gefunden, der das Problem verursacht!

Lösung

Halten Sie Ihren Computer up-to-date ist wichtig, die Installation von HPWA 4.0.10.0 löst dies! ;-)

Der Microsoft Blogeintrag Ist WMIprvse ein echter Bösewicht? zeigt, wie zu finden, welcher Prozess für die CPU verantwortlich ist, dass WmiPrvSE.exe verwendet.

Die Methode verwendet die Ereignisanzeigeoption "Analyse-und Debug-Protokolle anzeigen", um alle WMI-Aktivitäten zu verfolgen und dadurch die Prozess-ID des schuldigen Prozesses abzurufen.

Wenn Sie dies nur für alle anderen im selben Boot hinzufügen, ist diese Seite überall bei Google. Ich hatte das gleiche Problem mit WmiProvderHost CPU bis zu 50% Spicken und Batterie auf meinem Lenovo Yoga2 Pro unter Windows 8.1 entleeren.

Nach einigen der ausgezeichneten Untersuchung Ratschläge oben, entdeckte ich das Problem für mich war eigentlich GoPro Studio (kostenlose Video-Editing-Software, die mit GoPro Kameras kommt). Es installiert einen Überwachungsdienst, der darauf wartet, dass Sie Ihre Kamera anschließen und auf mich dies war der Schuldige.

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 das generierte WMItracing.etl in WPA.exe und grag & drop das Diagramm "Generische Ereignisse" von der linken Seite in den Analysebereich.

Filtern Sie nun nach Microsoft-Windows-WMI-Activity - Ereignissen und suchen Sie nach WMI-Vorgängen und der ClientProcessId.

In meinem Beispiel gehört diese CLientProcessId zu einem Tool namens Veeam ONE Server überwachen. Stoppen, das Problem der CPU-Auslastung behoben.

Und das zweite Beispiel wird hier gezeigt:

Hier sehen Sie wiederkehrende Aufrufe eines Prozesses mit PID von 0, der zum Intel PROSet Monitoring Service gehört.

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

Daher führt das Intel-Tool zu oft WMI-Benachrichtigungsabfragen aus, was zu Problemen führt. Stoppen, das Problem wurde behoben.

Hast du versucht zu sehen, ob es ein Virus ist? Einige Viren wirklich gerne Parade um als Windows-Dienste wie das. Stellen Sie sicher, dass sich der Prozess WmiPrvSE.exe im Verzeichnis c:\windows\system32\wbem befindet. Wenn nicht, möchten Sie möglicherweise allgemeine Spyware-Erkennungsprogramme ausführen. Wenn es sich nicht um Spyware handelt, könnte es sich möglicherweise um einen anderen Dienst handeln, der es aufruft. Ich weiß, ich habe schnell ein paar Gadgets auf meinem Computer laufen, und ironischerweise macht die Performance Monitor Gadget manchmal meine CPU Spike ein wenig. Es könnte auch ein anderer Dienst sein das drückt hin und wieder aufs Gas. Zum Beispiel Bloatware von HP, Dell usw.

Ansonsten scheint die andere Antwort von TomWij ziemlich nett zu sein, um sie zu beheben!

Für mich war Garmin Express der Schuldige. Das Beenden der Anwendung löst das Problem.