Diagnostic des performances par processus sous Windows : Get-Process, Get-CimInstance et nombre de handles

Objectif

Identifier, depuis PowerShell, le processus Windows à l'origine d'un problème de CPU, de mémoire ou de handles observé sur l'ensemble de l'hôte, et ne recourir à un outil Sysinternals que lorsqu'un processus précis est déjà suspecté.

Prérequis

PowerShell sur la machine cible (en local ou via remoting) ; service WMI/CIM en cours d'exécution pour les classes Win32_PerfFormattedData_* (c'est le cas par défaut) ; droits d'administrateur pour inspecter les processus appartenant à d'autres utilisateurs.

Étapes

1. Trier par working set : Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, WorkingSet64, CPU. La documentation de Get-Process indique que le working set et CPU sont des propriétés directement disponibles sur les objets retournés ; utilisez WorkingSet64 (alias WS), car l'ancienne propriété 32 bits WorkingSet est incorrecte pour les processus dépassant 2 Go.
2. Trier de la même façon par CPU : Get-Process | Sort-Object CPU -Descending | Select-Object -First 10. Ici, CPU est le temps processeur cumulé depuis le démarrage du processus, et non un pourcentage : un processus actif depuis longtemps peut donc se classer haut tout en étant actuellement inactif.
3. Pour obtenir un taux plutôt qu'un total cumulé, interrogez la classe de données de performance formatées : Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Where-Object Name -notin '_Total','Idle' | Sort-Object PercentProcessorTime -Descending | Select-Object -First 10 Name, IDProcess, PercentProcessorTime. Le filtre est important : sans lui, les instances _Total et Idle arriveraient en tête de liste. La valeur est exprimée par rapport à un processeur logique ; un processus multithread peut donc dépasser 100. La documentation de Get-CimInstance décrit l'interrogation d'une classe via -ClassName ; celle de la classe Win32_PerfFormattedData_PerfProc_Process répertorie PercentProcessorTime et IDProcess parmi ses propriétés, déjà calculées sous forme de taux.
4. Vérifiez les handles lorsqu'un processus est soupçonné de provoquer une fuite de handles, une cause fréquente de dégradation lente plutôt que de pic soudain : Get-Process | Sort-Object Handles -Descending | Select-Object -First 10 Name, Id, Handles. La propriété sous-jacente Process.HandleCount est documentée comme le nombre de handles du système d'exploitation ouverts par le processus ; un nombre qui augmente régulièrement pendant des heures sans changement de charge de travail est la signature d'une fuite.
5. Une fois un processus précis identifié, passez à un outil Sysinternals pour obtenir le détail que PowerShell n'expose pas : Process Explorer, pour examiner exactement quels handles et quelles DLL le processus a ouverts ; ou Process Monitor, pour suivre en temps réel son activité sur le système de fichiers, le registre ainsi que les processus et threads.
6. Process Monitor exige des droits d'administrateur (il charge un pilote) ; Process Explorer fonctionne sans, mais n'affiche le détail complet des processus d'autres utilisateurs qu'avec élévation de privilèges. Arrêtez rapidement la capture dans Process Monitor, car son journal grossit vite avec les paramètres par défaut.

Résultat attendu

Un identifiant de processus précis, accompagné d'une mesure (pourcentage CPU, working set ou nombre de handles) exploitable par un script, avec passage à un outil graphique uniquement lorsque les propriétés de PowerShell ne suffisent pas.

Limites et base de vérification

Les classes Win32_PerfFormattedData_* sont calculées à partir de deux échantillons internes consécutifs ; une requête isolée peut donc renvoyer un taux peu fiable lors du tout premier appel, et interroger deux fois à quelques secondes d'intervalle est plus fiable. Le nombre de handles seul n'indique pas quel type de ressource (fichier, clé de registre, événement) fuit ; la vue par handle de Process Explorer est nécessaire pour ce détail.