Windows 10: Hohe RAM-Auslastung durch ntoskrnl.exe

Heute noch ein merkwürdiges Problem in Windows 10, welches einige Nutzer trifft. Diese beklagen sich über eine hohe CPU- oder RAM-Auslastung (oder Disk I/O) durch den Prozess ntoskrnl.exe.


Anzeige

Auf das Problem bin ich erstmals bewusst in diesem Microsoft Answers-Forenthread gestoßen, wo Nutzer sich – nach der Installation des November-Updates (Windows 10 Version 1511 aka Threshold 2)  – über den Effekt beklagen.

Taskmanager benötigt der Prozess "Systemspeicher und komprimierter Speicher" ständig bis zu 99,7 % der CPU-Zeit.

In Windows 10 kommt ja eine neue Technik der Speicherkomprimierung (Compression Store) zum Einsatz: Nicht benutzte Speicherseiten im RAM werden komprimiert, um Seitenauslagerung in die Auslagerungsdatei zu minimieren. Siehe folgende Artikel:

Announcing Windows 10 Insider Preview Build 10525
Windows 10 Memory Compression
Is the new Insider build of Windows 10 taking too much of your RAM? Don't worry

Scheinbar schlägt das aber fehl, so dass die Diskauslastung bei betroffenen Maschinen durch Swapping extrem ansteigt. Trifft wohl nur einige Systeme – u.a. sind Besitzer eines Surface Pro 3 mit i5 CPU dabei.


Anzeige

Allerdings ist das Ganze nicht auf Windows 10 Version 1511 beschränkt. Ich habe Klagen über hohe Auslastung durch ntoskrnl.exe auch bei Windows 10 RTM (Build 10240) gefunden.

High Memory usage by ntoskrnl.exe System after upgrading to windows 10 home
How To Fix High RAM and CPU Usage of Windows 10 System (ntoskrnl.exe) Process
How To Fix High RAM and CPU Usage of Windows 10 System (ntoskrnl.exe) Process
Windows 10 High Ram Usage? Can't find a fix, need some guidance
Extremely high RAM usage on Windows 10…
Windows 10, 'System' process taking massive amounts of RAM

Das Ganze erinnert mich irgendwie an den alten Artikel Windows 8.1: Hohe CPU-Last durch Systemunterbrechungen (DPC), obwohl es dort um was anderes geht.

Veraltete Treiber und nicht kompatible Software

Im Web findet man verschiedene Artikel, die sich mit dem Problem befassen. Manchmal in Form von Tipps, wie hier:

How To Fix High RAM and CPU Usage of Windows 10 System (ntoskrnl.exe) Process
… Win10 users know why ntoskrnl.exe is taking up a massive 60%+ of my memory?
Top 10 Ways to Fix High RAM/CPU Memory Usage after Windows 10 Update
High Memory usage by ntoskrnl.exe System after upgrading to windows 10 home

wo Malware, nicht kompatible Software oder veraltete Treiber mit einem Memory-Leak als Ursache ausgemacht wurden. Andere Sites gehen die Analyse systematischer an, wie zum Beispiel hier:

ntoskrnl.exe!_misaligned_access eats a lot of CPU when idle
High CPU Usage by ntoskrnl.exe
Windows 10, 'System' process taking massive amounts of RAM
Need help with Ntoskrnl thread causing high CPU
How to Check Your Computer's Memory Usage in Windows

Soundkartentreiber als Ursache

Beim Durchgehen des oben verlinkten Microsoft Answers-Forenthread ist mir häufiger der Soundkartentreiber als Problemursache unter die Augen gekommen. Beim Surface Pro 3 verursacht ein älterer Intel SST Audio Devise (WDM)-Treiber (die Version 604.10135.2664.3879 scheint zu tun) die hohe CPU-Last. In diesem Thread (siehe auch) hat es geholfen, den Aufnahmepegel für das Mikro auf 0 zu setzen.

Defragmentierung deaktivieren

Andere Nutzer berichten im verlinkten Microsoft Answers-Forenthread, dass die Deaktivierung der Defragmentierung und der Windows-Wartung in der Windows-Aufgabenplanung (Aufgabenplanung -> MemoryDiagnostic -> RunFullMemoryDiagnostic) die hohe CPU-Last bereinigt habe.

Runtime Broker beenden und/oder deaktivieren

Die Runtimebroker.exe dient zur Verwaltung der Metro-Apps (Beenden, Berechtigungen prüfen etc.). Der Prozess ist bereits häufiger aufgefallen, hohe CPU-Last zu verursachen. Von Microsoft gibt es diesen Artikel, der das Beenden im Taskmanager vorschlägt. Manche Nutzer haben Erfolg, wenn Sie den Prozess komplett deaktivieren.

  1. Hierzu ist Regedit.exe mit administrativen Berechtigungen (Als Administrator ausführen) aufzurufen.
  2. Dann zum Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TimeBroker navigieren.
  3. Den DWORD-Wert Start von 2 oder 3 auf 4 setzen, um den Prozess zu deaktivieren.

Standardmäßig steht der Wert auf 2 (automatischer Start) oder 3 (manueller Start), während der Wert 4 den Prozess deaktiviert. In einem deutschen Windows heißt der Dienst "Timebroker" und kann auch über den Dienstemanager deaktiviert werden. Im Anschluss ist ein Neustart auszuführen (siehe auch und hier). Hat aber nicht immer geholfen – aber als Ursache dürften Metro-Apps verantwortlich sein. Hier macht jemand die Fotos-App bzw. deren Suche nach Fotos verantwortlich. Dort hat geholfen, die Netzwerkpfade in den Apps zu entfernen, so dass die Suche nur auf lokale Laufwerke begrenzt wird.

SuperFetch auf manuellen Start setzen

In diesem Forenthread hat auch noch jemand SuperFetch auf manuellen Start gesetzt. Dazu ist im Registrierungs-Editor zum Zweig:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SysMain

zu gehen und die Werte

"DisplayName"="Superfetch"
"Start"=dword:00000003

einzutragen.

Weitere Ursachen

In diesem Thread berichtet jemand, dass eine benutzerdefinierte Größe der Auslagerungsdatei zum Problem geführt habe. Das Aufheben der Option, so dass Windows die Größe des virtuellen Speichers bestimmt, hat Abhilfe gebracht.

Andere Nutzer berichten, dass der Chrome-Browser für die hohe CPU-Last verantwortlich war.

Das Update KB3118754 kann helfen

Die obigen Ansätze helfen nicht, da Treiber aktuell und Malware ausgeschlossen werden kann? Vor ein paar Tagen ist ja das kumulative Update KB3118754 freigegeben worden, welches die Systemstabilität verbessern soll. Laut einem Nutzer in MS Answers hat dieses Update das Problem bei ihm beseitigt.

Irgend jemand von euch betroffen? Gibt es Ursachen, die identifiziert wurden? Weitere Hinweise finden sich in den nachfolgenden Kommentaren.

Ähnliche Artikel:
Windows 10 Version 1511: Kumulatives Update KB3118754
Windows 8.1: Hohe CPU-Last durch Systemunterbrechungen (DPC)


Anzeige

Dieser Beitrag wurde unter Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

44 Antworten zu Windows 10: Hohe RAM-Auslastung durch ntoskrnl.exe

  1. Ralf sagt:

    Dieser Prozess macht seit dem November Update letzte Woche ein wenig Ärger. Nach dem Hochfahren erzeugt er so viel Schreibzugriffe auf der Festplatte, dass diese fast fünf Minuten nahezu blockiert ist. Nicht besonders schön für die anderen Prozesse, die auch beim Hochfahren gestartet bwz. für Programme, die geladen werden müssen. Das KB3118754 hat daran nichts geändert. Gibt auch keine Einträge in den Ereignisprotokollen. Nur das Hochfahren dauert jetzt fünf Minuten länger, bis man mit dem PC arbeiten kann. Besonders schön bei Updates (sei es Windows oder Fremdprogramme), die einen Neustart erfordern. Vor dem November-Update gab es damit keine Probleme.

  2. Thomas Bauer sagt:

    Ich habe keine Probleme hier. Windows fährt zügig hoch, Schreibzugriffe finden nach dem Booten kaum statt. Ich benutze aber auch nur selten Apps, sondern meist die herkömmlichen 32/64 Bit Anwendungen. Vielleicht liegt es auch an meinen 8 GB RAM, wovon nach dem Booten meist so 5,5 GB frei sind.

  3. Thomas Bauer sagt:

    Früher platzten die Foren auch aus allen Nähten als Windows Vista anfing allen verfügbaren Speicher einfach für sich zu benutzen und bei Bedarf wieder frei zu geben.
    Damals war man eben der Meinung das Speicher frei sein muss. Heute weiß man: RAM ist zum benutzen da! So ähnlich ist das jetzt bei der CPU auch. Warum sollte eine Idle CPU nicht mit 20-30% Last den Speicher komprimieren? Bei Bedarf wird ja die CPU sofort wieder frei gegeben. Im Grunde erhöht das nur die Gesamtperformance. Der Speicher müsste ja sonst auf einen Datenträger ausgelagert werden. Sicher MS muss dieses neue Feature noch etwas verfeinern. Vor allem in Hinsicht auf Tablett- und Handynutzer. Da sind die Lüftung und der Akku nicht für einen CPU Dauerlauf ausgelegt.

    • xXEragonXx sagt:

      Aber es kann ja wohl nicht sein das 8BG Ram vom PC zum speichern benutzt werden und der Speicher immer zu 89% Belegt ist… du da sind dann noch nicht einmal Programme offen

  4. André sagt:

    das ist eine neue Funktion in Windows 10 und KEIN PROBLEM. Du hast ja meinem Beitrag auf superuser.com verlinkt, wo ich alles zusammentragen habe was ich dazu gefunden habe.

    Kurz: Anstatt Daten in die Auslagerungsdatei auf der (langsamem) Platte zu packen werden die Daten komprimiert und im SYSTEM Prozess noch im RAM gehalten. Der komprimierte Speicher kann dann aber auch ausgelagert werden, wenn der RAM wirklich voll ist.

    • Günter Born sagt:

      Danke für die Ergänzung. Die Funktion an sich sehe ich auch nicht als Problem an. Und: Es ist solange kein Problem, wie nur die RAM-Auslastung hoch geht.

      Einige Nutzer beschreiben aber wohl, dass die Disk I/O- und CPU-Auslastung so hoch ist, dass die Lüfter aufdrehen oder die Maschine unbenutzbar ist. Da scheint – nach meinem Gefühl – noch was im Argen zu liegen (entweder durch Benutzerinstallationen, Treiber oder eine fehlerhafte Implementierung).

      • André sagt:

        das kommt aber dann nicht von der Funktion. Die sollen einen xperf (WPT aus Win10 SDK: https://dev.windows.com/en-us/downloads/windows-10-sdk) trace erstellen (1-2 Minuten der Auslastung) und hochladen :

        xperf -on LATENCY+DISPATCHER+FOOTPRINT+VIRT_ALLOC+
        MEMINFO+VAMAP+REFSET+MEMINFO_WS -stackwalk VirtualAlloc+VirtualFree+PROFILE+CSwitch+ReadyThread
        -buffersize 2048 -MaxFile 2048 -FileMode Circular &&
        timeout -1 && xperf -d C:HoheCPUUndRAMNutzung.etl

        • Barthel sagt:

          der Befehl für xperf scheint falsch geschrieben zu sein.

          xperf: error: NT Kernel Logger: Unzulässige Attribute (0x3ec)

          • Günter Born sagt:

            Das muss alles in eine Zeile – durch die Umformatierung im Blog kann der Fehler auftreten.

            xperf -on LATENCY+DISPATCHER+FOOTPRINT+VIRT_ALLOC+MEMINFO+VAMAP+REFSET+MEMINFO_WS -stackwalk VirtualAlloc+VirtualFree+PROFILE+CSwitch+ReadyThread -buffersize 2048 -MaxFile 2048 -FileMode Circular &&timeout -1 && xperf -d C:\HoheCPUUndRAMNutzung.etl
        • Barthel sagt:

          basierend auf dem MS-Answers-Forum habe ich, in Folge dessen das bei mir bein Ausführen von Windows-Aufgabem, wie Update und Defragmentierung hohe Datenträgerauslasutung durch ntoskrnlexe-systemspeicher-und-komprimierter verurschat werden ein experf-trace erstelt und hier:

          http://1drv.ms/1kRs1ZP

          hochgeladen.

          Rückmeldung wäre schön. Danke.

          • André sagt:

            also die CPU Nutzung kommt wirklich teilweise von der Komprimierung (ntoskrnl.exe!RtlCompressBufferXpressLzStandard). Der Grund warum das anläuft ist, dass die Modified List zu groß ist und Windows so die Daten (by design) komprimiert nachdem der BalanceManager Speicher von anderen Prozessen abgezwackt hat. Tritt das auch auf ,wenn du nicht Chrome benutzt? Der ist für einen Teil des modified Speichers verantwortlich.

            Übrigens, das Defragmentieren würde bei einer SSD entfallen. Deine aktuelle Samsung Spinpoint M8 750GBist total lahm. Sonst ist dein ASUS X550VB noch schnell genug.

            Noch ein Hinweis, lad keine KMS Cracks (C:UsersDanielDownloadsProgrammeCracksOffice2016Microsoft_Toolkit_2.6_BETA_5.rar) herunter ;)

            • Günter Born sagt:

              @André: Danke für die Hinweise – müsste mir wirklich mal wieder ein SDK/WDK auf den Rechner zerren – aber dann könnte ich mich dran halten, weil ich ständig irgend eine Entwicklungsumgebung für irgend etwas einrichten müsste.

          • Barthel sagt:

            @André: Ja tritt auch auf wenn kein Chrome verwendet wird.

            Kann man die Modified List irgendwie verkleinern oder das kompimieren abschalten?

          • André sagt:

            in dem superuser.com Link gibt es 2 Lösungen zum Abschalten. Dann schreibt Windows aber die Daten in die Auslagerungsdatei. Das ist bei der 5400er Platte aber langsam. Hol dir (zu Weihnachten) ne SSD und gut ist.

          • Barthel sagt:

            @Andre: sehe nicht wie eine SSD da helfen soll, dist hohe Datenträger-Auslastung (nicht CPU ) kommt ja fast immer vor, wenn nicht gerade im absoluten Leerlauf. Egal ob das AntiVirus läuft, Windows nach Updates suchto oder nur der Firefox aufgeht, ntkernel uses 80% Datenträger. Auch warum die Auslagerung bei deaktivierung bemüht werden soll ist mir nicht ganz klar, mein RAM ist doch groß genug.

          • André sagt:

            die Datenträgerauslastung kommt weil Windows sie im Leerlauf defragmentiert (Idle Maintenance). Dabei entsteht auch modified RAM der dann von Windows komprimiert wird.

            Bei einer SSD entfällt das ganze.

  5. Robert Brathe sagt:

    Mein Surface 3 LTE ist auch betroffen.
    40-50% CPU Last
    RAM Auslastung ist unauffällig, ca 50%

    Im Gerätemanager die System SSD ausgewählt und unter Richtlinien unten den Haken reingemacht.
    Von Windows veranlasstes……………..
    Seit dem ist wieder Ruhe.
    Hat wohl was mit dem Festplattencache zu tun, das Problem.

  6. Millenia M. sagt:

    Ich kann es nicht nachvollziehen.
    Das besagte verschwendet bei mir CPU in Promilenbereich, meistens aber =0%
    Arbeitsspeicher langweilt sich einfach bei 0,1 MB.
    Vielleicht soll man einfach lernen, das neue schöne Windows zu konfigurieren.

  7. Andres Müller sagt:

    Offenbar ist die RAM-Kompression schon seit 240 in Betrieb, der Microsoft- Chef hat die Änderung wohl zu spät in Umlauf gebracht. Hier von einem Techniker was die Kompression macht, auf Steinberg von Pete (Microsoft):

    http://www.steinberg.net/forums/viewtopic.php?f=226&t=88028&p=494333#p494229

    There are no changes to compression between 10240 and 10525. It's enabled in 10240 the same way it is in later builds.

    Memory compression takes place when pages would have been written to the pagefile, not proactively in some heuristic. Unless the system is very low on physical memory (last resort), memory compression will always occur at low CPU priority (below normal priority that all processes in Windows get by default) so it would not consume CPU that any normal process would otherwise need to consume.

    On the decompression side, the pages are decompressed when they are accessed and the app would have likely taken a hard fault from the pagefile (disk read) so the CPU latency of decompression is much faster than disk IO (even on current SSDs).

    Der Prozess sollte nur aktiv sein wenn die CPU nicht durch Anderes beschäftigt ist. ausserdem wenn nur noch sehr wenig freier Speicher da ist. Dann allerdings kann die Kompression natürlich schon den Prozessor kurzfristig auslasten, wenn auch mit niedrigerer Priorität als andere Prozesse. Die Dekompressionszeit sei kleiner als von Pagefile auf der Harddisk, auch wenn es eine SSD ist.

    Ich selbst habe bemerkt dass ein Prozess mit dem Namen winstore.mobile.exe Ärger mit Latenzen macht, aber aus einem ganz anderen Grund. Der Microsoft Store sucht nämlich ständig nach neuen App-Versionen (sehr oft war das bei mir) . Seitdem ich unter den Einstellungen des Microsoft Store (der etwas versteckt ist oben neben "suchen") die automatische Aktualisierung ausgeschaltet habe, ist zumindest dieser ärgerliche Spuk vorbei. Der Dienst installiert im Übrigen auch zuvor nicht vorhandene Apps automatisch, wenn es ihm gerade so passt. Die App "3DObjects" wurde installiert ohne dass ich danach gefragt habe, ebenso wie Skype das ich gar nicht überall auf allen Systemen installiert haben will.

    Hier der Beweis für die ärgerlichen Latenzen auf meinem Windows 10, November Version, festgehalten vom Programm "latencymon"

    Process with highest pagefault count: winstore.mobile.exe

    Total number of hard pagefaults 13155
    Hard pagefault count of hardest hit process: 4554
    Highest hard pagefault resolution time (µs): 3123003.102273
    Total time spent in hard pagefaults (%): 0.220949

    • André sagt:

      das ist der Windows Store, der Daten von der Platte laden muss weil sie nicht im RAM sind (https://de.wikipedia.org/wiki/Seitenfehler)

    • Timo sagt:

      Hi Andres,

      ich bin der, der die Diskussion bei Steinberg angestoßen hat. Das Verhalten von Windows 10 ist auf Systemen mit wenig RAM (z. B. x86-Systemen) schlicht undurchschaubar. Öffne ein großes Cubase-Projekt so dass der Prozess insgesamt ca. 1 GB Speicher benötigt. Tu nichts, belasse Cubase im Vordergrund. Warte ein paar Stunden. Prüfe im Task-Manager: Der Speicherbedarf von Cubase ist um 50% gesunken, diese Speicherblöcke wären demnach laut Petes Aussage im Pagefile gelandet. Dazu gibt es aber überhaupt keinen Anlass, es wurde keine weitere Applikation gestartet, Hintergrundprozesse wurden soweit möglich deaktiviert, es ist reichlich RAM übrig – dennoch fängt das System an zu pagen bzw. in den Compression Store zu verschieben (der ja laut Pete nur ein "besserer weil schnellerer Ersatz" für das Pagefile ist). Fakt ist: Es gibt keinen Grund für Paging, und ich mag nicht, wenn Microsoft angeblich ungenutzte Speicherinhalte auslagert, ohne dass es den geringsten Grund dafür gibt. MS verschiebt ganz offensichtlich _präventiv_ Inhalte in den Compression Store bzw. das Pagefile.

      PS: Danke für den Hinweis zum Windows-Store. Diese Probleme traten bei mir nicht auf, das mag aber daran liegen, dass ich mit einem lokalen Konto unterwegs bin und der Store auf meinem Rechner kein MS-Konto kennt.

      Gruß
      Timo

      • André sagt:

        wenn sie komprimiert sind, dann sind sie noch im RAM. Erst wenn der Speicher komplett ausgeht dann landen die komprimierten Daten in der Auslagerungsdatei auf der Platte

  8. Günter Born sagt:

    Im MS-Answers-Forenthread hat ein Nutzer folgendes geschrieben:

    Bei mir (Surface 3) war's die Soundkarte / der Treiber: 'Intel SST Audio Devise (WDM)'. Upgedatet und Ruhe….

  9. Ralf W sagt:

    Habe unter Windows 10 (32 Bit) auch das Problem, dass besagter Prozess die CPU zu fast 100% auslastet. Grund ist der Treiber für den Realtech Card Reader, neuester von der Realtech Website und angeblich Windows 10 kompatibel. Sobald ich den Card Reader deaktiviere ist das Problem weg.

  10. Siggi Raisin sagt:

    ich hatte sehr hohe I/O-Werte, die mein System insgesamt langsam gemacht haben, manchmal bis zum gefühlten Freeze. Der Tip von @Robert Brathe scheint nun zu helfen. Schöner Nebeneffekt: der Lüfter läuft nicht mehr die ganze Zeit auf Hochtouren. Danke!

  11. Richard Huber sagt:

    Nachdem ich tagelang alle möglichen Tipps fruchtlos ausprobiert habe war es letztlich der Eltron USB 3.0 Treiber, der die dauernde CPU-Last auf meinem ASRock 890 Pro 3 hervorruft. (EJ168A). Interessanterweise stieg die CPU-Last erst im Laufe von 20-30 Minuten auf die 100%. Wenn man währenddessen mit dem PC arbeitete blieb die Auslastung auch länger unten. Für den Eltron gab es leider keine aktuellen Treiber auch der Windows 10 Treiber ist schon steinalt, obwohl er offiziell auch 2015 datiert ist. Die einzige Hilfe die mögich war ist die Deaktivierung des USB 3.0 Kontrollers im Geräte-Manager. Glücklicherweise benötige ich auf dem Gerät keinen USB 3.0 Anschluss.

  12. Christow K sagt:

    Ich hatte bis dato auch das Problem (ntoskrnl.exe) gerade am zocken und die Fps-rate ging mit einmal ins Bodenlose nach ca 45min im Game.
    Ich habe mein Virtuellen Arbeitsspeicher jetzt selbst bestimmt mit 1024mb anfangsgröße und 2048 maxi . Danach ist ersmal ruhe eingekehrt bei mir.

    MfG

  13. hrochy sagt:

    Billig Tablet Trekstore7 1GB RAM
    Win10 mit allen Updates incl. KB3118754
    "systemspeicher und komprimierter speicher" verusacht bei mir eine RAM-belegung von 300MB, bischen zu viel von einem GB.
    Wie ich verstanden habe ist das wegen diesen "ntoskrnl.exe".
    Bin kein PC Experte, kann jemand eine "Easy" Einleitung schreiben, wie ich (und auch andere) diesen misstand abschalten kann?

    • André sagt:

      nochmals, das ist eine gute Funktion! Anstatt die Daten in die Auslagrungsdatei zu verschieben, blieben sie (komprimiert) im RAM. Das ist schneller.

  14. Luk sagt:

    @André:
    Zu dem "Phänomen" (damit wir uns nicht auf das Wort "Problem" versteifen) müsste es doch einen TechNet-Artikel oder ähnliches von MS geben, zumindest unsere PFEs sollten davon schon gehört haben, oder? – Nun, das kann ich bisher nicht bestätigen…(Ich irre mich in diesem Punkt gerne, wenn du nähere Infos hast! :))

    Ich kann kaum mehr als 1 VM auf meinem dienstlichen NB (SSD, 16 GB, I7) starten bevor mit 100% Plattenauslastung kaum noch der Task-Manager aufgeht…
    Auf meinem Heimsystem (SSD, 8 GB, I5) bittet mich mein System, geöffnete Programme zu schließen weil sich der Prozess mit über 3,5 GB zugeschaufelt hat… und das im LEERLAUF?!?!?

    Nun, ich kann deine Behauptung es sei eine "gute Funktion" nicht wiederlegen, eine solche Behauptung meinerseits hätte weder Hand noch Fuß…ich kann sie nur mit den Erfahrungen meinerseits und scheinbar auch einer nicht unwesentlichen Menge anderer Anwender, ernsthaft in Frage stellen:
    Solch eine Systembelastung nur damit irgendeine Anwendung/App ca. 0,025 Sekunden schneller aufgeht…in welchem Verhältnis steht das?

    Beste Grüße

    PS:
    Wenn "Funktion" ist es erst eine "gute Funktion" wenn sie transparent, konfigurierbar und bei Bedarf auch deaktivierbar ist – das ist allerdings nur meine persönliche Meinung :)

  15. Denny sagt:

    Hallo,

    bei mir war es der Treiber für die Grafikkarte. Hab da jetzt wieder einen alten Treiber installiert und mein Core i7 – 4790K ist wieder benutzbar.

  16. John sagt:

    Der Link hier ist Gold wert!

    http://superuser.com/questions/1020629/what-is-the-cause-of-a-high-cpu-usage-of-system-and-compressed-memory-in-windo

    Windows führt scheinbar regelmätig einen Task aus um den Arbeitsspeicher zu prüfen/warten. Bei mir war das zu 100% zu reproduzieren, geplante Tasks aufgemacht und die Wartung von Hand gestartet und siehe da CPU bei 33% ausgelastet.

    "For closure, on Win 10, I went to: Start->Control Panel->Administrative Tools->Task Scheduler Task Scheduler Library->Microsoft->Windows->MemoryDiagnostic There are two line items. Running of the task may be dependent upon log events. I'm not sure if they just have to exist, or if they trigger upon entry into the log. I disabled the RunFullMemoryDiagnosticEntry. I no longer see the 5% to 12% utilization after a few minutes delay. In the properties of the Task, on the settings tab, in may be possible to adjust things to not run very often. …. testing for another time."

    Gruß John

  17. Patrick sagt:

    Bei mir hat es geholfen die onboard mitgelieferte Software "Killer Network Manager" zu deinstallieren. Wird standardmäßig von z.B. MSI, Asus etc mitgeliefert

  18. Stefan sagt:

    Ich habe das Problem, dass die ntoskrnl.exe beim ersten Start des PC am Tag einen Bluescreen mit der Fehlermeldung MEMORY-MANAGEMENT ausgibt. Danach startet der PC neu und funktioniert dann problemlos. Kann da jemand was dazu sagen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.