Fehlerbehebung bei hoher CPU-Auslastung durch den" System " - Prozess

Einführung

Eine hohe CPU-Auslastung durch den" System " - Prozess kann häufig durch ein Hardwaretreiberproblem (Fehler, alte Version, Inkompatibilität usw.) verursacht werden.

Der Systemprozess lädt (oder hostet) mehrere Hardwaretreiber verschiedener Hersteller, die einen höheren Speicherzugriff erfordern. Aus diesem Grund kann die Diagnose des spezifischen Schuldigen ein wenig Detektivarbeit erfordern, wie unten beschrieben.

Diagnose des Problems

Zur Diagnose der CPU Ausnutzungsprobleme, sollten Sie Event Tracing für Windows (ETW) verwenden, um CPU-Sampling-Daten / Profil zu erfassen.

Um die Daten zu erfassen, installieren Sie das Windows Performance Toolkit, das Teil des [[47]}Windows SDK ist.

Windows 10 WPT-können verwendet werden auf Windows 8/Server 2012 Windows 8.1/Server 2012R2 und Windows 10/Server 2016. Wenn Sie weiterhin Windows 7 verwenden, verwenden Sie das SDK/WPT mit Build 15086.

^{(alle anderen Einträge können nicht ausgewählt)}

Führen Sie nun WPRUI.exe aus, wählen Sie First Level aus, wählen Sie unter Resource select CPU usage und klicken Sie auf start.

Erfassen Sie nun 1 Minute der CPU-Auslastung. Klicken Sie nach 1 Minute auf Save.

Analysieren Sie nun die generierte ETL-Datei mit dem Windows Performance Analyzer , indem Sie das Diagramm CPU Usage (sampled) in das Diagramm analysis pane ziehen und ablegen und die Spalten wie in der picture:

Innerhalb von WPA, laden Sie die Debug-Symbole und erweitern Stapel des Systemprozesses. In dieser Demo stammt die CPU-Auslastung vom nVIDIA-Treiber.

In der folgenden Demo stammt die CPU-Auslastung vom Realtek NIC-Treiber:

Wenn Sie Anrufe wie ntoskrnl sehen.exe-Datei!ViKeTrimWorkerThreadRoutine, ntoskrnl.exe-Datei!MmÜberprüferTrimMemory, ntoskrnl.exe-Datei!VerifierKeLeaveCriticalRegion, dies bedeutet, dass Sie Driver Verifier aktiviert haben. Dies schadet auch der Leistung sehr und verursacht eine hohe Systemnutzung. Treiberverifier deaktivieren und neu starten.

In dieser Demo verursacht der Treiber iai2ce.sys (Intel Serial IO GPIO Controller driver) Folgendes:

In diesem Beispiel stammt die CPU-Auslastung aus der Datei rtsuvc.sys, die die Realtek UVC webcam Driver

Diese Demo zeigt, dass Bitdefender Treiber ignis.sys

Im folgenden Beispiel wird die CPU-Auslastung durch den Broadcom-Netzwerktreiber bcmwl664.sys

Wenn Sie ntoskrnl.exe!MiZeroWorkerPages als Ursache sehen, ist es schwieriger. Dies bedeutet, dass die Funktion des Kernels, die den Speicher nullt, bevor er erneut verwendet werden kann, die hohe CPU verursacht Verwendung:

Es gibt keine wirkliche Möglichkeit zu erkennen, welcher Prozess ihn verursacht, aber ich weiß, dass Chrome ihn verursachen kann, wenn in Chrome die Hardwarebeschleunigung aktiviert ist. Wenn Sie dies sehen und Chrome verwenden, deaktivieren Sie die Hardwarebeschleunigung in Chrome.

Wenn Sie diese sehen ntoskrnl.exe-Datei!RtlpGenericRandomPatternWorker, ntoskrnl.exe-Datei!RtlpTestMemoryRandomUp ruft

Die CPU-Auslastung kommt vom Kernel um Speicher auf Probleme zu testen (memtest). Diese Nutzung wird über die Idle Maintenance Task von Windows 8.1/10 ausgelöst. Sie können den Taskplaner verwenden, um die Leerlaufaufgabe zu deaktivieren.

In Windows 10 heißt die Aufgabe RunFullMemoryDiagnostics unter Microsoft > Windows > MemoryDiagnostic > RunFullMemoryDiagnostic.

In diesem Fall scheint die CPU-Auslastung von der Funktion Data Deduplication (dedup.sys!DdpPostCreate) von Windows zu stammen Server:

In dieser Demo wird die CPU-Auslastung durch den WLAN-Kartentreiber verursacht athrx.sys

Suchen Sie nach einem Treiberupdate, wenn Sie dies sehen.

In der folgenden Demo ist ein Citrix-Treiber beteiligt:

Wenden Sie sich daher an Ihre IT, um Citrix-Probleme zu lösen.

In dieser Demo verursacht die Funktion usbhub.sys!UsbhPortRecycle die CPU Verwendung:

Das Ändern von USB2. 0-Anschlüssen in 1.1 speed oder das Anschließen von USB-Laufwerken an andere USB 2.0-Anschlüsse haben einigen Benutzern geholfen.

In diesem Fall kommt eine geringe Systemauslastung vom Acronis-Treiber tdrpm251.sys:

In dieser Demo, die CPU-Auslastung ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc und ntoskrnl.exe!KeReleaseSpinLock.

Ein Treiber verwendet also SpinLocks sehr stark. Deaktivieren Sie einige geräte / Treiber, bis Sie eine sehen, die es verursacht.

In diesem Fall wird die CPU-Auslastung durch den Treiber L1C62x64.sys

Dies ist der qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet Treiber. Aktualisieren Sie also den Treiber, wenn Sie ihn im Stapel sehen.

Hier kommt die CPU-Auslastung vom Scannen der Hostdatei (netbt.sys!DelayedScanLmHostFile)

Stellen Sie sicher, dass Ihre Hosts-Datei nicht zu groß ist, um diese Verwendung zu vermeiden.

In in diesem Fall stammt die CPU-Auslastung von SRTSP64.SYS von symantec.

Aktualisieren Sie Ihr verwendetes Symantec-Produkt auf die neueste Version.

Hier kommt die CPU-Auslastung vom AMD GPU Treiber (atikmdag.sys)

Wenn Sie dies sehen, gehen Sie zur AMD-Website und holen Sie sich den neuesten Treiber für Ihre AMD-Karte.

Hier sind die Treiber TMXPFlt.sys und VsapiNt.sys verursachen die hohe CPU Nutzung.

Soweit ich sehe, sind diese Dateien Teil der Trend Micro AV Suite. Aktualisieren Sie das Tool oder entfernen Sie es.

In diesem Beispiel stammt die CPU-Auslastung von der Funktion ntoskrnl.exe!MmGetPageFileInformation

Diese Funktion erhält Informationen über die Auslagerungsdatei.

Routine Beschreibung: Diese Routine gibt Informationen über das aktuell aktive Paging zurück Datei.

Deaktivieren Sie die pagefile, starten Sie es neu und aktivieren Sie es erneut und prüfen Sie, ob dies es behebt. Außerdem scheint das Entfernen von Intel-Diensten (z. B. Intel Content Protection HECI Service) dies für einen Benutzer behoben zu haben.

Hier können Sie sehen, dass der Treiber Netwtw04.sys (Intel Wifi driver) die Funktion flushCompleteAllPendingFlushRequests aufruft und dies eine hohe CPU-Auslastung verursacht.

Da die Debug-Symbole geladen werden, wird der Windows Inbox-Treiber verwendet. Nur hier können wir Debug-Symbole erhalten, um den Callstack zu sehen mit dem Funktionsnamen flushCompleteAllPendingFlushRequests.

Hier sollten Sie den neuesten Treiber von Intel installieren, um das Problem zu beheben.

Der komplizierteste Fall der Systemnutzung ist ACPI.sys-Nutzung im Callstack:

Line #, DPC/ISR, Module, Stack, Count, Process, Weight (in view) (ms), TimeStamp (s), % Weight
6, , ,   |    |- ACPI.sys!ACPIWorkerThread, 40246, , 39.992,941063, , 4,13
7, , ,   |    |    ACPI.sys!RestartCtxtPassive, 40246, , 39.992,941063, , 4,13
8, , ,   |    |    ACPI.sys!InsertReadyQueue, 40246, , 39.992,941063, , 4,13
9, , ,   |    |    ACPI.sys!RunContext, 40246, , 39.992,941063, , 4,13
10, , ,   |    |    ntoskrnl.exe!KeReleaseSpinLock, 40246, , 39.992,941063, , 4,13
11, , ,   |    |    ntoskrnl.exe!KiDpcInterrupt, 40246, , 39.992,941063, , 4,13
12, , ,   |    |    ntoskrnl.exe!KiDispatchInterruptContinue, 40246, , 39.992,941063, , 4,13
13, , ,   |    |    ntoskrnl.exe!KxRetireDpcList, 40246, , 39.992,941063, , 4,13
14, , ,   |    |    ntoskrnl.exe!KiRetireDpcList, 40246, , 39.992,941063, , 4,13
15, , ,   |    |    |- ntoskrnl.exe!KiExecuteAllDpcs, 40198, , 39.945,173325, , 4,13
16, , ,   |    |    |    |- ACPI.sys!ACPIInterruptDispatchEventDpc, 27565, , 27.408,930428, , 2,83
17, , ,   |    |    |    |    |- ACPI.sys!ACPIGpeEnableDisableEvents, 24525, , 24.384,921620, , 2,52
18, , ,   |    |    |    |    |    ACPI.sys!ACPIWriteGpeEnableRegister, 24525, , 24.384,921620, , 2,52
19, , ,   |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWrite, 24421, , 24.281,015516, , 2,51
20, , ,   |    |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWritePort, 24166, , 24.027,316013, , 2,48

Dies ist extrem schwierig zu debuggen. In einem sysinternals-Thema habe ich einige Ratschläge aufgelistet:

• stellen Sie sicher, dass die CPU nicht wegen Staub im CPU-Lüfter überhitzt
• update oder re-flash die (gleiche) BIOS/UEFI
• Standard-BIOS/UEFI-Einstellungen laden
• stellen Sie sicher, dass der Akku nicht beschädigt ist, entfernen Sie den Akku aus dem Notebook oder deaktivieren Sie den Akku im Geräte-Manager.
• jumper wechseln auf HDD Caddy wenn Sie das DVD/Blue-Ray-Laufwerk durch einen Caddy ersetzt haben, um eine SSD neben Ihrer alten Festplatte zu installieren

• deaktivieren Sie einige Geräte wie von diesem Benutzer empfohlen
• wenn Sie ein Intel-chipsatz, versuchen zu installieren Intel Rapid storage Technology (RST) zu ersetzen die standard AHCI fahrer von Windows. Dies scheint auch zu helfen.
• der Benutzer Shayna habe herausgefunden, dass mit Process Hacker (als admin gestartet) die Threads des ACPI angehalten werden.sys Probleme "behebt" das Problem für ihn. Versuchen Sie also seine Problemumgehung, wenn alle anderen Schritte dies nicht für Sie beheben.

In der folgenden demo, die Intel HD Treiber igdkmd64.sys in der version .4574 für die Intel HD 630 verursacht das Problem:

Die Lösung besteht darin, auf den Treiber mit mindestens einer Version zu aktualisieren .4590.

Im folgenden Fall wird die CPU-Auslastung des Systemprozesses durch den Treiber stdriverx64.sys

Dies scheint ein Audio-Streaming-Treiber zu sein. Aktualisieren Sie diese Software / diesen Treiber, wenn Sie dies in WPA sehen.

Wenn Sie siehe einen Treiber namens risdxc64.sys im Callstack des SYSTEMS, der die hohe CPU-Auslastung verursacht, aktualisieren Sie den Treiber für PCIe SDXC/MMC Host Controller oder deaktivieren Sie den SD-Kartenleser im Geräte-Manager, wenn kein Treiberupdate dies behebt.

Dieser SD-Kartenleser scheint für viele Lenovo-Geräte eingebaut zu sein.

Der Benutzer @stevemidgley zeigte ein neues Problem mit höherer CPU-Auslastung mit Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk

Hier sehen Sie ein Treiber UDE.sys verursacht wird.

In Symbol Nabe

Ich kann sehen, dass es zum Modemtreiber gehört und PNP-Daten der Trace zeigen Fibocom L850-GL (LTE-Modem) als mögliches Gerät an:

Und die Lösung besteht darin, das Modem und das USB-Verbundgerät im Geräte-Manager zu deaktivieren.

Dies kann durch einen fehlerhaften Treiber oder ein anderes vom System geladenes Modul verursacht werden. Um in den Systemprozess zu schauen, können Sie ein Tool wie Process Explorer.

Laden Sie es herunter und führen Sie es aus, wählen Sie den Systemprozess aus, klicken Sie mit der rechten Maustaste und wählen Sie Eigenschaften aus:

Wechseln Sie zur Registerkarte Threads (ignorieren Sie das Dialogfeld mit den Symbolen):

Dies zeigt an, welche Datei die übermäßige CPU-Auslastung verwendet, von der aus Sie dann versuchen können diagnostizieren Sie es.

Wie andere in den Kommentaren gesagt haben, müssen Sie sich jedoch so schnell wie möglich von den Vorschauversionen entfernen!

Ein Hinweis zum Laden von Debugging-Symbolen zum Hinzufügen zu magicandre1981 ' s ausgezeichneter Antwort: Wenn das Laden der Symbole in Windows Performance Analyzer korrekt funktioniert, sollten Sie nach dem Ankreuzen von Trace > Load Symbols oben einen Fortschrittsbalken mit Loading symbols sehen, der die Dateinamen daneben anzeigt und einige Minuten dauert. Außerdem sollten Sie viele Zeilen wie die folgenden in der Diagnosekonsole sehen:

SYMSRV:  File: Accessibility.ni.pdb

SYMSRV:  Notifies the client application that a proxy has been detected.
SYMSRV:  Connecting to the Server: http://msdl.microsoft.com/download/symbols.
SYMSRV:  Successfully connected to the Server.
SYMSRV:  Sending the information request to the server.
SYMSRV:  Successfully sent the information request to the server.
SYMSRV:  Waiting for the server to respond to a request.
SYMSRV:  Successfully received a response from the server.
SYMSRV:  Closing the connection to the Server.
SYMSRV:  Successfully closed the connection to the Server.
SYMSRV:  Get File Path: /download/symbols/Accessibility.ni.pdb/7B46178957827CDAB7EE4C86EDEE1DAE1/Accessibility.ni.pdb

Wenn Sie nicht sehen, entweder von diesen, be - debug-Symbole haben wahrscheinlich nicht funktioniert und Sie können Ihren Trace nicht richtig interpretieren.

In meinem Fall funktionierte das Laden von Debug-Symbolen zunächst nicht. Ich habe es behoben, indem ich diese Anweisungen befolgt habe:

1. Finden Sie heraus, ob Sie die x86-oder x64-Version des Windows Performance Toolkits verwenden.

   Dies ist einfach auf x86-builds von Windows. Auf x64 Builds können Sie überprüfen der Task-Manager für das * 32-Tag. Wenn es nicht da ist, dann bist du laufen der x64-version.

   Beachten Sie, dass WPT immer in Programmdateien (x86) installiert wird, unabhängig von Architektur.

2. Kopieren Sie die Dateien dbghelp.dll und symsrv.dll aus dem richtigen Debugger-Verzeichnis in das Windows Performance Toolkit-Verzeichnis. Auf mein System, die relevanten Verzeichnisse sind:

   C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 und C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit

3. Starten Sie Windows Performance Analyzer so, dass die richtige Version von dbghelp.dll wird abgeholt.

Mein Problem war, dass die CPU-Auslastung beim Herunterladen von etwas lächerlich hoch war (bis zu 4 GHz). Ich habe einen Predator Helios 300 mit einer Killer-WLAN-Karte, daher war der Killer-Treiber vorinstalliert. Ich habe Process Explorer verwendet, um in die Registerkarte Eigenschaften → Threads von System zu wechseln, und festgestellt, dass "kfeco10x64.sys " verursachte die hohe CPU-Auslastung. Seit "kfeco10x64.sys " war Teil des Killer-Netzwerkdienstes, ich habe es deaktiviert, indem ich msconfig ausgeführt und jeden Dienst von "Killer Networks"deaktiviert habe.

Nach ein Neustart, das Problem ging für mich weg. Vor allem scheint es beim Herunterladen keine Geschwindigkeitsreduzierung zu geben. Ich hoffe, das hilft jedem, der vor dem gleichen Problem steht.

Antwort hinzugefügt von @magicandre1981 ist der Schlüssel zur Lösung eines Problems. Mein Fall wurde dort nicht aufgeführt, aber ich habe ein ähnliches Wort im Stapel gefunden, das im Abschnitt The most complicated case of SYSTEM usage is ACPI.sys usage in the callstack: beschrieben ist. In meinem Fall wurde die Installation des Treibers Intel Rapid Storage unterstützt. Ich habe das nicht erwartet, soweit alle ohne diesen Treiber und ohne CPU-Probleme viel Zeit gearbeitet haben. Ich habe meinen Stapel hier abgelegt, wahrscheinlich wird jemand diese Antwort mit ähnlichen Schlüsselwörtern gefunden.

Line #, Process, Stack, Count, Weight (in view) (ms), TimeStamp (s), % Weight
3, , [Root], 45104, 45,300.439000, , 16.21
4, ,   ntoskrnl.exe!KiStartSystemThread, 45104, 45,300.439000, , 16.21
5, ,   ntoskrnl.exe!PspSystemThreadStartup, 45104, 45,300.439000, , 16.21
6, ,   |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread, 38830, 38,997.540000, , 13.95
7, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry, 38708, 38,874.943400, , 13.91
8, ,   |    |    |- ntoskrnl.exe!memcpy, 33888, 34,032.390100, , 12.18
9, ,   |    |    |    |- ntoskrnl.exe!memcpy<itself>, 33655, 33,795.069100, , 12.09
10, ,   |    |    |    |- ntoskrnl.exe!KiDpcInterrupt, 228, 232.331300, , 0.08
11, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatchNoLockNoEtw, 4, 3.989700, , 0.00
12, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatch, 1, 1.000000, , 0.00
13, ,   |    |    |- ntoskrnl.exe!RtlCompressBuffer, 2571, 2,585.541600, , 0.93
14, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessReadyQueue, 2015, 2,022.554900, , 0.72
15, ,   |    |    |- ntoskrnl.exe!MmBuildMdlForNonPagedPool, 129, 129.294600, , 0.05
16, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry<itself>, 63, 62.901700, , 0.02
17, ,   |    |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 31, 31.208200, , 0.01
18, ,   |    |    |- ntoskrnl.exe!MetroHash64::Hash, 10, 10.033100, , 0.00
19, ,   |    |    |- ntoskrnl.exe!KiDpcInterrupt, 1, 1.019200, , 0.00
20, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread<itself>, 78, 78.477100, , 0.03
21, ,   |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 39, 39.068100, , 0.01
22, ,   |    |- ntoskrnl.exe!KeWaitForSingleObject, 5, 5.051400, , 0.00
23, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStWorkerThread, 5420, 5,445.923200, , 1.95
24, ,   |- ntoskrnl.exe!SmKmStoreHelperWorker, 495, 496.265200, , 0.18
25, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStReadThread, 359, 360.710600, , 0.13
26, , n/a, 16760, 16,773.871200, , 6.00

Update: Leider kam das Problem zurück. Nach dem Neustart funktioniert der PC einige Zeit einwandfrei, aber dann wird dasselbe CPU-Leck mit demselben Stapel angezeigt

Ich hatte das gleiche Problem, es verschwand, als ich eines der RAM-Module entfernte. Es scheint, es war fehlerhaft. Unter Windows 7, 32-bit.

Erstens ist die Überprüfung und die bereitgestellten Informationen sehr informativ, aber Sie können dies normalerweise mit viel weniger Intelligenz herausfinden! Ich habe einfach MSCOFIG verwendet.EXE und eine binäre Suche, um den beleidigenden Dienst zu isolieren. Ich habe festgestellt, dass die meisten Probleme wie diese durch Intel-Software verursacht werden. Ich beginne damit, jeden Dienst zu deaktivieren, der keinen Firmennamen hat. Dann beginne ich mit Intel-Diensten. Dann die vollständige binäre Suche. Normalerweise dauert es höchstens eine Stunde, um das Problem in jemandes PC zu beheben. Intel war nie eine gute Computerfirma, und ihre Software zeigt es. Seien wir ehrlich, die Pentium-Architektur war ein Jahrzehnt alt, als sie veröffentlicht wurde. Wer hätte in den Tagen von VAX eine Computerarchitektur mit ausgelagertem Speicher gebaut? Nun, ich werde dich nicht mit der Geschichte langweilen. Nicht, dass ich bin fan von AMD oder Microsoft entweder. Vielleicht werden wir eines Tages wieder echte Computer bauen.