TaskExplorer : lire une machine Windows comme un arbre de processus, pas une liste

Résumé

TaskExplorer est un gestionnaire de processus libre pour Windows : un arbre de processus avec CPU, mémoire, disque et réseau en direct, des piles de threads, les handles, l'inspection mémoire et une analyse antivirus multi-moteurs.

Recommander
Nom
Task Explorer
Version
1.6.4
Tarif
Gratuit
Open source
Open source
Mis à jour
2026-10-06 20:24

Une liste de processus répond à la mauvaise question

TaskExplorer est un gestionnaire de processus libre pour Windows, écrit par DavidXanatos, et sa décision de conception centrale est petite avec de grandes conséquences : les processus sont affichés en arbre plutôt qu'en liste plate. Une liste plate est un recensement. Elle dit qu'il y a deux cent quarante choses en cours et laquelle consomme le plus de temps processeur, et elle ne répond à aucune des questions que l'on se pose réellement quand une machine se comporte mal.

L'arbre en répond à une autre : qui a lancé qui. Cette relation est le début de presque tout diagnostic. Une application lente parce qu'un processus auxiliaire redémarre sans cesse, un hôte de services qui a accumulé une douzaine d'instances en silence — rien de tout cela ne se remarque dans une liste triée, et tout cela est évident dès que la hiérarchie est visible.

Arbre des processus

Quatre chiffres, et ce que chacun mesure vraiment

Des valeurs en direct pour le processeur, la mémoire, le disque et le réseau sont affichées par processus, et la compétence utile est de savoir laquelle ment dans quel sens. L'utilisation du processeur est un débit, pas un total : un processus à quatre-vingt-dix pour cent pendant une seconde et un autre à neuf pour cent pendant dix secondes ont fourni le même travail, et seul le temps processeur cumulé les distingue. Un processus qui semble inactif mais affiche un temps total énorme n'est pas inactif ; il a terminé.

Mémoire est le mot le plus vague du lot. Ce qu'un programme a demandé au système, ce que le système a réellement engagé et ce qui réside actuellement en mémoire physique sont trois nombres différents, et ils peuvent différer d'un ordre de grandeur pour un même processus. La conséquence pratique : le plus grand nombre d'une colonne mémoire n'est souvent pas le problème ; la forme intéressante est celle d'un processus dont la mémoire engagée monte régulièrement pendant que la taille résidente reste plate — c'est ainsi que ressemble une fuite vue de l'extérieur.

Disque et réseau complètent le tableau, et ils comptent parce que le stockage le plus récent et le plus rapide n'effectue encore qu'un nombre limité d'opérations par seconde. Une machine qui paraît poussive alors que le processeur est à dix pour cent attend généralement un disque, et l'entrée-sortie par processus est ce qui transforme ce soupçon en un nom.

Graphiques

Threads et piles : la différence entre occupé et bloqué

L'inspection des piles de threads est la fonction qui sépare un outil de surveillance d'un outil de diagnostic. Un seul processus peut contenir des dizaines de threads, et un processus à zéro pour cent d'utilisation peut malgré tout faire quelque chose — ou attendre indéfiniment. Une pile dit lequel : c'est la liste de ce dans quoi ce thread se trouve, et la lire est la manière de distinguer un blocage d'une inactivité.

Deux motifs méritent d'être reconnus. Un interblocage ressemble à deux threads ou plus qui attendent chacun quelque chose que l'autre détient, et il est invisible dans tout chiffre agrégé parce que rien ne se consomme. Un goulot d'étranglement ressemble à de nombreux threads empilés au même endroit, souvent un verrou ou une section monothread dont tout le monde a besoin. Ni l'un ni l'autre n'est un problème de performance au sens où un graphique le montre ; les deux sont structurels, et les deux ne deviennent visibles que lorsqu'on voit où se tiennent les threads.

Les graphiques historiques relèvent de la même idée dans la dimension temporelle. Un chiffre à cet instant explique peu ; la forme des dernières minutes explique beaucoup, parce que la plupart des problèmes sur un poste de travail ne sont pas des états mais des événements — un pic quand un fichier est indexé, une dent de scie quand une tâche de fond réessaie, un palier qui commence exactement quand le ventilateur s'est lancé.

Piles de threads

Les handles sont là où vivent vraiment les fuites

Pouvoir voir les fichiers, clés de registre et connexions réseau qu'un processus tient ouverts est la partie la plus sous-estimée de l'outil. Les fuites de mémoire sont le type célèbre, mais sur un système moderne la défaillance plus fréquente est une fuite de handles : un programme ouvre un fichier, une clé ou une socket et ne le ferme jamais, et après quelques jours il ne peut plus rien ouvrir du tout.

La liste rend la fuite visible et, plus important, nommable. Si un processus détient quatre cents connexions vers un serveur auquel il devrait parler une fois, la question est passée de pourquoi cet ordinateur est lent à pourquoi ce programme ouvre des connexions qu'il ne ferme jamais. C'est toute la valeur de la fonction : elle convertit une plainte vague en un défaut précis avec un responsable.

Handles ouverts

Inspection de la mémoire, et les réserves honnêtes

Pouvoir consulter et modifier la mémoire d'un autre processus est une capacité de débogage et de rétro-ingénierie, et il vaut la peine d'être précis sur son usage. Elle sert à comprendre ce qu'un programme détient à un moment donné — une structure, un tampon décodé, une chaîne qui ne devrait pas être là. Elle ne remplace pas un débogueur avec symboles, et modifier la mémoire vivante pour changer un comportement est une technique à demi-vie très courte : la compilation suivante déplace tout.

La réserve qui compte le plus est procédurale. Un outil capable de lire la mémoire de n'importe quel processus peut tout lire, y compris des identifiants qui s'y trouvent par hasard, et un outil capable d'arrêter ou de suspendre n'importe quel processus peut en suspendre un dont le système dépend. Aucune des deux capacités n'est dangereuse en soi ; les deux le sont entre les mains de quelqu'un qui n'a pas réfléchi à la suite. Suspendre un processus n'est pas un bouton pause pour un programme — c'est le gel de tout ce que ce processus tenait, et autre chose l'attend peut-être.

L'analyse multi-moteurs, et ce qu'elle ne promet pas

Soumettre un processus suspect à un service en ligne qui le passe devant de nombreux moteurs antivirus est réellement utile, et le mot à remarquer est suspect. L'analyse est un second avis sur un fichier, pas un verdict sur une machine. Un résultat propre signifie qu'une quarantaine de moteurs, avec leurs signatures du moment, n'ont rien trouvé ; cela ne signifie pas que le fichier est sûr, et certainement pas que le processus se comporte bien. Un résultat positif est une preuve plus forte, mais un seul moteur signalant un petit utilitaire est un faux positif courant.

L'autre moitié de la phrase est la vie privée. Soumettre un fichier signifie qu'une copie quitte la machine et arrive chez un tiers, et le fait que ce soit normal n'en fait pas une chose anodine. Savoir si l'on envoie un condensat ou le fichier entier, et y réfléchir avant de le faire avec un document plutôt qu'un programme, c'est la différence entre utiliser la fonction et être utilisé par elle.

Courbes

Portable, personnalisable, plusieurs fenêtres

Trois petites décisions achèvent le tableau. Le programme est portable, ce qui compte surtout là où il est le plus utile : sur une machine qui n'est pas la vôtre, où installer un logiciel est soit interdit, soit exactement ce que l'on cherche à éviter. Les colonnes se réorganisent et le tri se change, ce qui ressemble à une préférence et constitue en fait la manière dont un utilisateur expérimenté transforme un tableau générique en la vue qui répond à sa question. Et plusieurs fenêtres signifient que deux processus peuvent être observés côte à côte, ce que la comparaison exige.

Fenêtre principale

Là où il trouve sa place

C'est un outil de diagnostic, pas un nettoyeur et pas un accélérateur. Il ne rend pas un ordinateur plus rapide, et il ne faut pas l'utiliser pour tuer des processus au hasard en espérant que quelque chose s'améliore — un processus tué est un processus que son propriétaire relancera, généralement en quelques secondes. Il répond à la question de ce qui se passe réellement, avec assez de détail pour agir. Pour un développeur qui traque un blocage, un administrateur qui cherche qui tient un fichier ouvert, ou quiconque veut comprendre pourquoi une machine avec beaucoup de mémoire libre ne répond pas, c'est tout le travail.