Prozessbezogene Performance-Diagnose unter Windows: Get-Process, Get-CimInstance und Handle-Zähler

Ziel

Ein hostweites CPU-, Speicher- oder Handle-Problem mit PowerShell auf einen einzelnen Windows-Prozess eingrenzen und erst dann ein Sysinternals-Tool einsetzen, wenn ein bestimmter Prozess bereits im Verdacht steht.

Voraussetzungen

PowerShell auf dem Zielrechner (lokal oder über Remoting); der laufende WMI/CIM-Dienst für die Win32_PerfFormattedData_*-Klassen (standardmässig der Fall); administrative Rechte, um Prozesse anderer Benutzer einzusehen.

Schritte

1. Nach Working Set sortieren: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, WorkingSet64, CPU. Laut der Dokumentation von Get-Process stehen Working Set und CPU direkt als Eigenschaften der zurückgegebenen Objekte zur Verfügung. Dabei WorkingSet64 (Alias WS) verwenden, denn die ältere 32-Bit-Eigenschaft WorkingSet liefert bei Prozessen über 2 GB falsche Werte.
2. Auf die gleiche Weise nach CPU sortieren: Get-Process | Sort-Object CPU -Descending | Select-Object -First 10. CPU ist hier die kumulierte Prozessorzeit seit dem Start des Prozesses und kein Prozentwert; ein lange laufender Prozess kann daher weit oben stehen, obwohl er aktuell im Leerlauf ist.
3. Für eine Rate statt einer kumulierten Summe die Klasse mit den formatierten Performancedaten abfragen: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Where-Object Name -notin '_Total','Idle' | Sort-Object PercentProcessorTime -Descending | Select-Object -First 10 Name, IDProcess, PercentProcessorTime. Der Filter ist wichtig: Ohne ihn stünden die Instanzen _Total und Idle an der Spitze der Liste. Der Wert bezieht sich auf einen logischen Prozessor, weshalb ein Multithread-Prozess über 100 liegen kann. Die Dokumentation von Get-CimInstance beschreibt die Abfrage einer Klasse über -ClassName; die Dokumentation der Klasse Win32_PerfFormattedData_PerfProc_Process führt PercentProcessorTime und IDProcess unter ihren Eigenschaften auf, bereits als Rate berechnet.
4. Handles prüfen, wenn bei einem Prozess ein Handle-Leck vermutet wird. Das ist eine häufige Ursache für schleichende Verschlechterung statt eines plötzlichen Ausschlags: Get-Process | Sort-Object Handles -Descending | Select-Object -First 10 Name, Id, Handles. Die zugrunde liegende Eigenschaft Process.HandleCount ist dokumentiert als Anzahl der Betriebssystem-Handles, die der Prozess geöffnet hat. Ein Zähler, der über Stunden stetig steigt, ohne dass sich die Last ändert, ist das typische Merkmal eines Lecks.
5. Sobald ein bestimmter Prozess identifiziert ist, für Details, die PowerShell nicht bereitstellt, auf ein Sysinternals-Tool wechseln: Process Explorer, um genau zu sehen, welche Handles und DLLs ein Prozess geöffnet hat; oder Process Monitor, um dessen Dateisystem-, Registry- und Prozess-/Thread-Aktivität in Echtzeit zu beobachten.
6. Process Monitor benötigt administrative Rechte (es lädt einen Treiber); Process Explorer läuft auch ohne sie, zeigt aber die vollständigen Details zu Prozessen anderer Benutzer nur mit erhöhten Rechten. Die Aufzeichnung in Process Monitor zügig beenden, da das Log bei den Standardeinstellungen schnell wächst.

Erwartetes Ergebnis

Eine konkrete Prozess-ID mit einem gemessenen Wert (CPU-Prozentsatz, Working Set oder Handle-Zähler), auf den ein Skript reagieren kann. Ein GUI-Tool kommt erst zum Einsatz, wenn die Eigenschaften von PowerShell nicht ausreichen.

Grenzen und Prüfbasis

Die Win32_PerfFormattedData_*-Klassen werden aus zwei aufeinanderfolgenden internen Messungen berechnet. Eine einzelne Abfrage kann daher beim allerersten Aufruf eine unzuverlässige Rate liefern; zuverlässiger ist es, zweimal im Abstand von einigen Sekunden abzufragen. Der Handle-Zähler allein verrät nicht, welcher Ressourcentyp (Datei, Registry-Schlüssel, Event) leckt; dafür ist die Ansicht pro Handle in Process Explorer nötig.