Hohe CPU aus ntoskrnl.exe im Leerlauf bei GetStackLimits

1678
Martin Jensen

Ich habe einen seltsamen Fehler in Windows 10.

Nach 5 Minuten Leerlauf geht meine CPU hoch. Ich habe Win Performance Analyzer verwendet und festgestellt, dass dies in der Datei ntoskrnl.exe im Thread GetStackLimits vorkommt.

Ich habe alle Treiber aktualisiert und alles funktioniert. Alle Aufgaben im Leerlauf werden deaktiviert und gelöscht. Ich habe auch sfc / scannow und chkdsk ohne Fehler ausgeführt.

Wie soll ich den Fehler finden, wenn er sich im Kernel befindet ?!

3

3 Antworten auf die Frage

2
Martin Jensen

Ich habe vor langer Zeit die Antwort auf mein Problem gefunden, habe es aber vergessen, es hier hinzuzufügen.

Es war die Wartungsfunktion in Windows 10:

RunFullMemoryDiagnostic

Gefunden unter:

\ Microsoft \ Windows \ MemoryDiagnostic

Nach dem Deaktivieren dieser Funktion können meine Wartungsaufgaben abgeschlossen werden, anstatt nur die CPU für diese Aufgabe zu verwenden.

Ich habe in letzter Zeit keine Speicherprobleme oder BSODs, aber ich habe 32 GB Speicher, was möglicherweise dazu beiträgt, dass diese Aufgabe abgeschlossen wird.

Ich habe es einige Stunden laufen lassen, aber es ist noch nie zu Ende gegangen, also geht es mir viel besser ohne.

Vielen Dank für die Hilfe!

0
Dan Randolph

Martin, in meinem Fall war dies darauf zurückzuführen, dass Hyper-V aktiviert war (vor dem Upgrade von Windows 8.1 auf 10) und wahrscheinlich überbrückte Netzwerkverbindungen verwendet wurden, die nicht mit dem Controller Realtek PCIe GBE (Ethernet) kompatibel waren, der mit meinem Desktopsystem geliefert wurde hatte ursprünglich Windows 8.0 installiert. Der einzige Grund, warum ich Hyper-V verwendete, war für die Entwicklung von Windows Phone 8. Ich habe das seit Jahren nicht mehr verwendet, aber das Netzwerk lief überbrückte Verbindungen, und ich könnte es niemals ohne die Bridge schaffen. Ich weiß nichts davon. Das Visual Studio-Installationsprogramm hat alle Einstellungen für Hyper-V und das virtuelle Netzwerk vorgenommen.

Um das Problem zu beheben, habe ich Hyper-V im Dialogfeld "Windows-Funktionen ein- oder ausschalten" entfernt und die Brückenverbindungen automatisch entfernt. Dann verbrachte ich einige Stunden damit, meine direkte Ethernet-Verbindung wieder zum Laufen zu bringen. Die Diagnose war dabei keine Hilfe. Ich griff schließlich auf den alten Trick des Austauschs des Verbindungsports des Routers durch einen anderen (von vier) zurück, und Windows konnte die anderen Computer in meinem Heimnetzwerk endlich wieder sehen.

Um das Problem zu diagnostizieren, habe ich die xperf-Cmd-Konfiguration von MagicAndre1981 verwendet, um eine etl zu generieren. (Siehe Installieren des WPT .) Ich öffnete diese Datei dann in "Windows Performance Analyzer" und fügte die Spalte "Stapel" hinzu, wie im Beispiel von MagicAndre1981. Die Modulnamen unter der Systemwurzel gaben mir den Hinweis, dass es sich vermutlich um die Hyper-V handeln könnte, wie ich schon immer vermutete.

Ich denke, Sie haben Recht, dass das RealTek GBE-Ethernet-Gerät der Schuldige ist, und ich habe nie gedacht, dass Hyper-V Einfluss hat. Ich benutze es auch, aber für Virtualbox, aber wenn es meine Maschine so instabil macht, würde ich es lieber ausschalten. Allerdings bin ich jetzt für eine kleine Woche zu Win7 zurückgekehrt und habe überhaupt keine Probleme. Hatte auch BSOD auf Win10, was mich dazu brachte, es fallen zu lassen. Ich habe versucht, Xperf mit Symbolen und allem zu verwenden, aber es gräbt sich ständig in den Kernel ein. Ich werde dies trotzdem als Antwort akzeptieren, da dies die aufwendigste Lösung ist. Martin Jensen vor 9 Jahren 0
0
Dvj

Ich weiß leider nicht, ob dieses Verhalten aufhört, wenn die Leerlaufbedingungen nicht mehr gegeben sind. Es ist jedoch normal, dass das mpengine (Microsofts AV-Zeug) das MRT-Tool ausführt und wie verrückt scannt, was für einige Zeit zu einem hohen CPU-Verbrauch führt Das Tool muss seine Scans ausführen, nachdem der Benutzer nach einer kurzen Leerlaufzeit im Leerlauf war.

Wenn die CPU-Nutzung wieder normal wird, nachdem Sie die Maus bewegt oder eine Taste berührt haben, geschieht dies wahrscheinlich.

Ich finde das am einfachsten mit Process Explorer zu sehen.

Wenn die Aktivität hoch bleibt, wenn die Leerlaufbedingungen aufhören, ist dies etwas anderes.