Windows: Arbeitsspeicher-Probleme analysieren
Vergesst 1-Klick-Tuning, ernsthafte Probleme verlangen nach ein "wenig" mehr.
Natürlich gibt es einfach Apps, die Arbeitsspeicher regelrecht fressen – insbesondere Browser. Aber auf einem aktuellen Rechner mit 8 Gigabyte RAM oder mehr ist das kein großes Problem, Windows‘ Speichermanagement regelt das recht gut, im Zweifelsfall hilft abschalten. Was aber, wenn der Speicher ständig vollläuft, bei 90+ Prozent herumhängt und partout nicht zurückkommen will? Dann müsst Ihr Housten anrufen und den Standardspruch ablassen.
(M)Ein Problem
Ihr seht gleich Schritt für Schritt, wie Ihr böse Speicherteufel entlarven könnt. Aber erstmal der konkrete Anlass für meine eigene Problemsuche, vielleicht findet Ihr Euch da ja wieder: Nach ein paar Stunden waren meine 32 Gigabyte Arbeitsspeicher laut Task-Manager-Manager immer zu rund 90 Prozent belegt. Aber selbst, wenn ich alle Programme schloss, änderte sich nichts daran. Und auch andere Anwendungen konnten den Speicher nicht für sich beanspruchen, virtuelle Maschinen beispielsweise brachen den Start ab – zu wenig Speicher. Die – muhaha – Lösung: Neustart.
Und da habe ich gemacht, was Menschen halt so machen und über Windows‘ Speichermanagement geschimpft. Ist auch viel leichter, als sich damit zu beschäftigen. (Und wer sich jetzt denkt „Yep, genau – wo ist das Problem?“, HÄNDE WEG VON TWITTER! ;) ) Aber schimpfen macht nur Spaß, bringt aber keine Lösungen. Mit sehr überschaubarem Aufwand ist mein Problem mittlerweile gelöst, der Übeltäter war eine bestimmte Version der Freeware Wise Folder Hider, die ich eigentlich durchaus mag.
Nun ist Speichertheorie ein langwieriges Thema und bezüglich der Windows-Bausteine kann man ganze Bücher verfassen. Hier bekommt Ihr weder eine ausführliche Erklärung, noch ausufernde theoretische Grundlagen, sondern einen praktischen Weg, um vermutlich den meisten Speicherproblemen auf den Grund zu gehen. Ein sehr gutes Video, natürlich auf Englisch, gibt es bei Channel 9, einem Entwicklerkanal von Microsoft selbst. Dort wird in einer halben Stunde über RAM-Management doziert – anhand des Tools RamMap aus der Sysinternals-Suite, das auch hier eine Rolle spielt. Eine ausführliche schriftliche Erläuterung zu RamMap findet Ihr hier, ebenfalls von Microsoft selbst.
Mit RamMap allein habt Ihr schon ein mächtiges Tool an der Hand, aber es ist noch nicht das Ende der Fahnenstange.
5 Stufen RAM-Analyse
Wenn Ihr Probleme mit dem Speicher habt, könnt Ihr folgende Tools verwenden – von einfach und oberflächlich bis hin zu komplex und detailliert:
1. Task-Manager
Der Task-Manager zeigt, welche aktiven Prozesse Speicher verbrauchen und gibt eine grobe Übersicht, welche Speicherbereiche wie betroffen sind. Ein Problem fällt schnell auf: Gerne werden hier 90 Prozent angezeigt, aber zählt man die Werte der einzelnen Prozesse/Apps zusammen, landet man nicht bei 90 Prozent … Das liegt daran, dass die Prozesse eben nur einen bestimmten Teil des Arbeitsspeichers belegen. Die Prozentangabe über Spaltenüberchrift ist also nicht die Summe der einzelnen Prozesse. Ganz tolles Design :(
2. Ressourcenmonitor
Der Ressourcenmonitor zeigt ein paar Infos mehr, kann weitere Infos über Prozesse aufrufen, hat eine hübsche Darstellung, kann aber auch nicht mehr als der RAM-Tab im Task-Manager. Immerhin sieht man den Speicherverlauf als Graphen, was insofern hilfreich ist, als dass man die Auswirkung von Maßnahmen sehen kann. Ein Problem beider Tools: Vermutlich läuft das bei Euch auf Deutsch – für die Suche nach Lösungen benötigt Ihr aber die englischen Originalbegriffe, selbst auf deutschen Tech-Seiten sind diese üblicher.
3. RamMap
RamMap zeigt eine extrem detaillierte Analyse der RAM-Verwendung. Extrem nützlich ist aber allein schon die namensgebende Map/Karte: Ihr seht auf einen Blick die Verteilung des physischen Speichers im Speichermanagement. Und allein diese Kenntnis kann schon ungemein bei der Identifizierung des Problems helfen. In meinem Fall hat gleich der erste Versuch einer Suche nicht nur das generelle Problem aufgezeigt (Speicherleck durch Treiber, mehr dazu später), sondern auch gleich Wise Folder Hider als Verursacher, das als Beispiel genutzt wurde – Glück gehabt.
4. PoolMon
PoolMon steht für Memory Pool Monitor: Das Microsoft-Tool zeigt live die Verwendung des Arbeitsspeichers an, ähnlich wie der Task-Manager im Prozesse-Tab die laufenden Programme. Das Schöne daran: Ihr könnt hier nach Größe und Namen sortieren, um sofort die größten Verursacher zu identifizieren. Grundsätzlich ginge das auch mit RamMap, aber nur mit viel Sucherei und ein paar Infos dürften auch einfach fehlen.
5. Windows Performance Analyzer
Und wenn das alles nicht hilft, wird halt aufgezeichnet. Die bisherigen Tools gucken sich vor allem den Status Quo an, da ändert auch eine simple Timeline nichts dran. Für den Windows Performance Analyzer (WPA) zeichnet Ihr hingegen zunächst einige Zeit den Verkehr im Arbeitsspeicher auf und analysiert dann die Geschehnisse des gesamten Zeitraums.
Im Folgenden seht Ihr, wie Ihr mit RamMap, PoolMon und WPA vorgehen könnt. Dabei wird beiläufig auch eine ziemlich nützliche Frage beantwortet: Wo sieht man eigentlich den Arbeitsspeicher, der virtuellen Maschinen zugesichert wurde?
1. RamMap: RAM verstehen
Ein erster Blick auf RamMap wird vermutlich eines sein: Nichtssagend. Aber es reichen schon ein paar Dinge, um dem Tool etwas Nützliches abgewinnen zu können. Wichtig sind hier vor allem folgende Spalten:
- Active: Aktuell aktiv genutzer/zugeordneter Speicher.
- Standby: Teile, die mal Active waren – wird freigegeben, falls anderweitig benötigt.
- Zeroed: Ehemals belegter, wieder freigegebener Speicher, der bei Bedarf für den Active-Bereich freigegeben wird.
Die sonstigen Spalten sind rein für die interne Verwaltung relevant. Active + Standby + Zeroed ist in etwa die Summe Eures physischen Speichers. Der Active-Teil ist tatsächlich in Gebrauch und steht somit nicht zur Verfügung, Standby- und Zeroed-Teile stehen Anwendungen bei Bedarf zur Verfügung.
Und folgende Zeilen:
- Process Private: Exklusiv von laufenden Apps reservierter Speicher – das, was Task-Manager und Ressourcenmonitor anzeigen.
- Mapped File: Dateien von der Festplatte, die von Apps für schnelleren Zugriff in den Arbeitsspeicher gelegt werden.
- Paged Pool: Kernel-reservierter Speicher mit Dingen, die (auf Festplatte/pagefile.sys) ausgelagert werden können, um Speicher frei zu geben.
- Nonpaged Pool: Kernel-Dinge, die nicht ausgelagert werden können.
- Driver Locked: Von Treibern pauschal geblockte/reservierte Bereiche.
Wirklich interessant sind dabei die Bereiche Pools und Driver Locked.
Driver Locked: Hier wird die Frage beantwortet, wo der Arbeitsspeicher virtueller Maschinen landet. Startet einfach eine VM, aktualisiert die RamMap-Anzeige mit F5 und schon werdet Ihr hier einen Sprung bemerken. Aber: Wenn Ihr hier zum Beispiel zwei VMs mit jeweils 4 Gigabyte RAM startet, werden hier nicht zwangsläufig 8 Gigabyte angezeigt – der Speichermanager der Virtualisierungslösung teilt den reservierten Speicher zwischen VMs auf.
Pools: Hier geht es um systeminterne Dinge und die Pools sollten nicht irre groß sein. Vor neun Jahren sprach Microsoft hier von rund einem halben Gigabyte bei 64-Bit-Systemen, mittlerweile dürften auch 1,5 Gigabyte in Ordnung sein. Aber eben nicht 8 Gigabyte. Wirklich problematisch ist ein großer Haufen im Nonpaged Pool, denn dieser Speicher kann nicht auf die Festplatte ausgelagert werden und blockiert damit tatsächlich physischen Speicher.
Mein Problem von oben hatte sich genau hier manifestiert: Etliche Gigabyte im Nonpaged Pool. Die generelle Ursache in diesem Bereich ist meist ein Memory Leak durch einen Treiber, also einfach ein Gerätetreiber, der durch einen Bug Speicher beansprucht. Der Verursacher in diesem Fall: Wise Folder Hider. Und das scheint so oft vorzukommen, dass die Suche eben sofort erfolgreich war.
Aber Ihr könnt ja nicht auf Glück hoffen. Wie also könnt Ihr herausfinden, was denn da genau Nonpaged-Pool-Speicher frisst? Das weitere Vorgehen ist natürlich nur exemplarisch für dieses Nonpaged-Pool-Treiber-Memory-Leak-Problem gedacht, für andere Probleme solltet Ihr aber ableiten können.
Nebenbei: Über das Empty-Menü kann RamMap auch ein wenig Speicher freischaufeln, was sich dann im Ressourcenmonitor erkennen lässt – Wunder bewirkt das in der Regel nicht.
2. PoolMon: Pool Tag ausfindig machen
PoolMon ist im Grunde (für diesen Zweck) super simpel zu nutzen, auch wenn es kompliziert aussieht – allein die Installation nervt etwas. Denn das Tool gehört zum Windows Driver Kit und dafür müsst Ihr allerlei Kram installieren:
- Visual Studio 2019
- Windows 11 SDK
- Windows 11 WDK
- Kleinkram während der Installation, einfach Zustimmen ;)
Alle aktuellen Links findet Ihr direkt auf Microsofts WDK-Seite.
Öffnet anschließend einen Admin-Terminal, also cmd.exe (Eingabeaufforderung) suchen, Kontextmenü öffnen, „Als Administrator öffnen“ wählen. Führt dann PoolMon aus:
cd "C:\Program Files (x86)\Windows Kits\10\Tools\x64"
poolmon.exe
Die Ansicht sortiert Ihr nun über P nach Pool-Typen und dann über B nach Bytes. Das Ergebnis: Ihr seht die größten Nonpaged-Pool-Belegungen ganz oben. Wichtig ist dabei der Eintrag in der ersten Spalte, der Pool Tag. Über diese Tags lässt sich identifizieren, wer für den Speicherverbrauch verantwortlich ist.
Bei der Installationsorgie eben ist auch eine Textdatei mitinstalliert worden, die Tags für Windows-eigene Treiber und Kernel-Kram auflistet:
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\triage\pooltag.txt"
Hier im Beispiel ist es jedenfalls der Tag ConT und dieser muss nun gesucht werden. Eine Google-Suche zeigt in diesem konkreten Fall über einige Umwege an, dass das Tag etwas mit Virtual Box zu tun hat – was ein Abschalten experimentell sofort bestätigt, wieder Glück. Generell müsst Ihr aber den verursachenden Treiber suchen – vornehmlich im Treiberordner von Windows:
cd C:\Windows\System32\drivers
findstr /s cont *.sys | more
more sorgt nur dafür, dass Ihr den Anfang der Ausgabe seht, ansonsten bekommt Ihr vermutlich Hunderte Seiten sinnloser Ausgabe. Ihr seht hier im Screen ganz oben 3ware.sys.
Diese Datei könnt Ihr nun im Explorer ausfindig machen und über das Kontextmenü zum Beispiel den Hersteller und eventuell auch direkt da Produkt herausfinden – und dann wieder die Google-Suche bemühen.
Vermutlich werdet Ihr an diesem Punkt häufig das Problem identifiziert haben. Für die Lösung könnt Ihr dann beispielsweise das verursachende Produkt deinstallieren oder es einfach aktualisieren, das ist natürlich von Fall zu Fall anders.
Wenn PoolMon nichts Eindeutiges hervorbringt, muss halt noch ein Tool her. Und das dürfte mindestens immer der Fall sein, wenn PoolMon lediglich Windows-eigene Treiber als größte Verbraucher listet.
3. WPA: Pool Tag analysieren
Nun geht es ans Aufzeichnen, mit folgendem Kommandochen:
xperf -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree+PoolAllocSession+PoolFreeSession -BufferSize 2048 -MaxFile 1024 -FileMode Circular && timeout -1 && xperf -d C:\pool.etl
Wenn Euch all die vielen xperf-Optionen interessieren, schaut in der Dokumentation des Windows Performance Toolkits nach, hier soll der Befehl als Blackbox genügen. Sobald Ihr den Befehl abgesetzt habt, wird aufgezeichnet und in der Datei C:\pool.etl gespeichert – lasst die Aufzeichnung eine Minute oder so laufen und beendet dann mit einem beliebigen Tastendruck im Terminal. Eventuell könnt Ihr in der Zeit auch Programme starten/nutzen, die Ihr als Verursacher in Verdacht habt.
Anschließend könnt Ihr die ETL-Datei per Doppelklick im Windows Performance Analyzer öffnen – was wieder einen überwältigen Screen offenbart.
Klickt zunächst links in der Spalte auf den Bereich Other und dann doppelt auf Pool Allocations. Klappt dann oben den Bereich NonPaged aus, sucht Euren Tag (hier also ConT). Macht einen Rechtsklick darauf und wählt aus dem Kontextmenü Filter to Selection. Im Datenbereich ist dann nur noch Relevantes zu sehen.
Öffnet anschließend den View Editor über STRG+E und aktiviert die Spalte Stack.
Nun könnt Ihr Euch weiter durch die Einträge wühlen und nach verdächtigen Einträgen suchen. Aber was heißt schon verdächtig … Nun, häufig werdet Ihr Einträge sehen, die eindeutig nicht direkt zu Windows gehören und zum Beispiel Produkt- oder Herstellernamen beinhalten. So würde zum Beispiel auch das oben genannte Wise Folder Hider mit einem Eintrag WiseFs64.sys auftauchen (das ich aber schon deinstalliert hatte).
Wie geht’s weiter?
Wie ganz oben erwähnt, das Problem ist damit nicht gelöst. Aber Ihr solltet nun alle Informationen haben, um das Problem identifizieren zu können. Und wenn erstmal klar ist, was das Problem ist, lässt sich die Lösung meist schnell über eine Websuche finden. Im Zweifelsfall: Die betroffene Software deinstallieren, Speicher erneut prüfen und dann gegebenenfalls nach Alternativen, Patches oder aktuelleren Versionen suchen.
Und wenn Euch das jetzt alles superkompliziert erscheint: Das alles ist nur ein winziger Teil des ganzen Window-RAM-Themas und kratzt nur an der Oberfläche der Tool-Features und ist teils auch noch deutlich vereinfacht und verkürzt. Die gute Nachricht: Wirklich relevant ist das nur für Entwickler und vielleicht ein paar Hardcore-Admins. Normale Nutzer …, nun ganz normale Nutzer werden Dinge wie PoolMon niemals auch nur mit dem Arsch ansehen ;) Aber relativ normale, fortgeschrittene Windows-Nutzer können sich mit den hier gezeigten Werkzeugen und Wegen in vielen Fällen behelfen, auch wenn man nicht alles komplett versteht.
Wenn Ihr wirklich mehr wissen und verstehen wollt, legt Euch die Bücher der Windows-Internals-Reihe zu, die quasi die theoretische Grundlage für die Sysinternals-Suite liefern.
