En cette fin de matinée mon PC semblait très occupé, au moins autant que moi. En jetant un œil à la liste des tâches en cours j’ai pu constater qu’il restait très peu de mémoire disponible. Après avoir fermé quelques applications inutilement restées ouvertes depuis vendredi dernier, j’ai vu qu’il restait encore plusieurs processus gourmands, et notamment deux svchost.exe consommant chacun plus de 50 Mo.

On sait que Windows utilise les processus svchost.exe pour héberger des services n’ayant pas leur propre exécutable. Chaque instance de svchost.exe peut héberger plusieurs services, parfois plusieurs dizaines. On sait moins comment on peut obtenir la liste des services hébergés par un processus svchost.exe donné. Il existe plusieurs méthodes, je m’attarderai ici sur l’une d’entre elles qui fait appel à Windows PowerShell.

Lorsqu’il s’agit de manipuler des processus et des services dans PowerShell, on pense immédiatement à deux commandelettes fournies en standard :

PS> get-process

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName

-------  ------    -----      ----- -----   ------     -- -----------

     27       1      380        376    11            1952 AEADISRV

     38       2      736        432    21            1968 agrsmsvc 

    183       3     2608        580    41            1024 Ati2evxx

[...]                                                                                                                       

PS> get-service

Status   Name               DisplayName

------   ----               -----------

Stopped  AddFiltr           AddFiltr

Stopped  Adobe LM Service   Adobe LM Service

Running  AeLookupSvc        Application Experience

[...]                                                         

Comme on pourrait s’y attendre, on peut facilement obtenir la liste des processus nommés svchost.exe :

PS> get-process svchost

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName

-------  ------    -----      ----- -----   ------     -- ----------- 

    331       5     4020       3856    45             816 svchost

    732      11     6440       4872    56             884 svchost

    469      20   106252      13912   206             932 svchost

[...]

On peut même très facilement isoler les processus dont la mémoire de travail est supérieure à 50 Mo :

PS> get-process svchost | where {$_.workingset -gt 50MB}

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName

-------  ------    -----      ----- -----   ------     -- -----------

   1026      22    94800      79816   198            1068 svchost 

   2242     290   134076      98224   323            1080 svchost

Mais get-process ne fournit pas de méthode pour aller voir quels services se cachent dans ces processus. On pourrait à la rigueur s’en faire une idée en parcourant les modules chargés par chacun de ces processus, mais la liste serait assez rébarbative à parcourir et à recouper avec de véritables services Windows.

On aurait alors envie de se tourner vers get-service. Pendant un instant j’ai imaginé que les objets retournés par get-service avaient un numéro de tâche qui permettrait de les rattacher à un processus. Mais non. Ou alors, je n’ai pas trouvé.

J’ai alors pensé à un troisième larron : la classe WMI Win32_Service. PowerShell permet d’accéder très facilement aux classes WMI :

PS> get-wmiobject win32_service | get-member -membertype properties

   TypeName: System.Management.ManagementObject#root\cimv2\Win32_Service 

Name                    MemberType   Definition 

----                    ----------   ---------- 

AcceptPause             Property     System.Boolean AcceptPause {get;set;} 

AcceptStop              Property     System.Boolean AcceptStop {get;set;}

Caption                 Property     System.String Caption {get;set;}

CheckPoint              Property     System.UInt32 CheckPoint {get;set;} 

CreationClassName       Property     System.String CreationClassName {get;set;} 

Description             Property     System.String Description {get;set;}

DesktopInteract         Property     System.Boolean DesktopInteract {get;set;}

DisplayName             Property     System.String DisplayName {get;set;}

ErrorControl            Property     System.String ErrorControl {get;set;}

ExitCode                Property     System.UInt32 ExitCode {get;set;} 

InstallDate             Property     System.String InstallDate {get;set;}

Name                    Property     System.String Name {get;set;} 

PathName                Property     System.String PathName {get;set;} 

ProcessId               Property     System.UInt32 ProcessId {get;set;} 

ServiceSpecificExitCode Property     System.UInt32 ServiceSpecificExitCode {get;set;}

ServiceType             Property     System.String ServiceType {get;set;}

Started                 Property     System.Boolean Started {get;set;}

StartMode               Property     System.String StartMode {get;set;}

StartName               Property     System.String StartName {get;set;}

State                   Property     System.String State {get;set;}

Status                  Property     System.String Status {get;set;}

SystemCreationClassName Property     System.String SystemCreationClassName {get;set;}

SystemName              Property     System.String SystemName {get;set;} 

TagId                   Property     System.UInt32 TagId {get;set;}

WaitHint                Property     System.UInt32 WaitHint {get;set;}

[...]

Bingo ! La propriété ProcessId (surlignée ci-dessus) semble tout à fait correspondre à ce que je cherche, à savoir faire une jointure entre la liste des processus svchost.exe et la liste des services. Essayons :

PS> get-process svchost | where {$_.workingset -gt 50MB} | foreach {

>> $id = $_.id; gwmi win32_service | where {$_.processi d -eq $id}} |

>> ft proc*,name,displayname,stat* -auto

>>            

ProcessId name                 displayname                     state   status

--------- ----                 -----------                     -----   ------

     1068 AudioEndpointBuilder Windows Audio Endpoint Builder  Running OK

     1068 CscService           Offline Files                   Running OK

     1068 EMDMgmt              ReadyBoost                      Running OK

[...]

Et voilà.

NB. Je suis obligé de tronquer les commandes sur plusieurs lignes pour que l'affichage soit lisible dans mon blog. En réalité, je tape les commandes les unes à la suite des autres sur un même ligne.

Pour celles et ceux qui s’interrogent: oui, on pouvait s’épargner la création d’une variable intermédiaire ($id) mais ça n’apportait aucune amélioration dans les performances de la requête, ça rendait la ligne un peu plus complexe à déchiffrer, et au final ça m’aurait éloigné de l’objet de cette discussion. J

Quant à mon problème de mémoire vive utilisée par svchost.exe, cet exercice m’a surtout permis de constater qu’il y avait beaucoup de monde pour utiliser cette mémoire, ce qui n’est pas forcément un problème en soi. Il y aurait eu deux ou trois services hébergés par chacun de ces processus, le problème aurait été autrement plus criant. Là, je me suis contenté de parcourir la liste et d’arrêter les services qui ne me paraissaient pas indispensables.

Il ne me restait plus qu’à pousser cette ligne de commandes dans un script, de manière à m’éviter de devoir rechercher l’information à chaque fois qu’il m’arrive de vouloir obtenir l’information. Dans sa version la plus simple, le fichier ressemblait alors à ceci :

PS> get-content get-hostedservice.ps1

# get-hostedservice

#                  

# Returns a list of services hosted by a process.

# 

# Syntax: get-hostedservice -id ProcessId 

param ([int]$Id)

get-wmiobject Win32_Service | where {$_.ProcessId -eq $Id}    

Et voici un exemple de mise en oeuvre :

PS> gps svchost | where {$_.workingset -gt 50MB} | foreach {get-hostedservice $_.id} |

>> ft proc*,name,displayname,stat* -auto    

>>

ProcessId name                 displayname                     State   Status

--------- ----                 -----------                     -----   ------

     1068 AudioEndpointBuilder Windows Audio Endpoint Builder  Running OK

     1068 CscService           Offline Files                   Running OK

     1068 EMDMgmt              ReadyBoost                      Running OK

[...]

La ligne à taper est plus simple que la précédente, mais pas tant que ça. Encore faut-il se rappeler que le script accepte l’Id d’un processus comme paramètre. Et j’aurais aimé pouvoir simplement récupérer les objets du pipeline dans mon script, sans avoir à les traiter un par un dans ma ligne de commandes avec une boucle foreach.

C’est là que la v2 de PowerShell apporte quelques grosses améliorations qui vont nous simplifier encore plus la tâche. Mais nous verrons tout cela dans la 2^e partie, à venir dans quelques jours. D’ici là, soyez sages ! J

Janel