Mark Russinovich & Windows Internals : Observabilité et Fiabilité

Pourquoi Mark Russinovich compte encore pour les opérations Windows

Si vous exécutez Windows en production — sur portables, serveurs, VDI ou machines virtuelles cloud — le travail de Mark Russinovich continue d’apparaître dans les opérations quotidiennes. Pas par réputation ou nostalgie, mais parce qu’il a popularisé une approche du dépannage fondée sur les preuves : regardez ce que l’OS fait réellement, puis expliquez les symptômes avec des preuves.

Trois idées en clair

Observabilité signifie que vous pouvez répondre à « que se passe-t-il maintenant ? » à partir des signaux produits par le système (événements, traces, compteurs). Quand un service ralentit ou que les connexions d’ouverture de session bloquent, l’observabilité fait la différence entre deviner et savoir.

Débogage consiste à transformer un problème vague (« ça a gelé ») en un mécanisme précis (« ce thread est bloqué sur de l’I/O », « ce processus fait thrash du fichier d’échange », « cette injection de DLL a changé le comportement »).

Fiabilité est la capacité à continuer de fonctionner sous contrainte et à récupérer de manière prévisible — moins d’incidents, rétablissements plus rapides et changements plus sûrs.

Pourquoi la connaissance des internals accélère les incidents

La plupart des « pannes mystérieuses » ne sont pas des mystères : ce sont des comportements Windows que vous n’avez pas encore cartographiés : fuites de handles, processus enfants incontrôlés, pilotes bloqués, timeouts DNS, entrées d’auto-démarrage cassées, ou outils de sécurité qui ajoutent de la latence. Une compréhension basique des internals Windows (processus, threads, handles, services, mémoire, I/O) vous aide à reconnaître rapidement des motifs et à collecter les bonnes preuves avant que le problème ne disparaisse.

Ce que cet article va vous aider à faire

Nous allons nous concentrer sur des workflows pratiques et adaptés aux opérations en utilisant :

• les outils Sysinternals (en particulier Process Explorer et Process Monitor) pour une visibilité rapide et peu contraignante
• le traçage ETW quand les logs ne suffisent pas et que vous avez besoin d’une timeline haute fidélité
• WinDbg et les dumps de crash/gel pour convertir des échecs en causes racines exploitables

L’objectif n’est pas de faire de vous un ingénieur kernel. C’est de rendre les incidents Windows plus courts, plus calmes et plus faciles à expliquer — pour que les corrections soient plus sûres et reproductibles.

Windows Internals comme super-pouvoir de dépannage

Les “internals” Windows sont simplement l’ensemble des mécanismes que Windows utilise pour faire du travail réel : ordonnancer les threads, gérer la mémoire, démarrer les services, charger les pilotes, gérer les activités de fichiers et de registre, et appliquer les frontières de sécurité. La promesse pratique est simple : quand vous comprenez ce que l’OS fait, vous arrêtez de deviner et vous commencez à expliquer.

C’est important parce que la plupart des symptômes opérationnels sont indirects. « La machine est lente » peut être une contention CPU, un seul thread chaud, une tempête d’interruptions de pilote, une pression de pagination, ou un filtre antivirus bloquant l’I/O. « Elle gèle » peut être un deadlock, un appel réseau bloqué, un timeout de stockage, ou un service qui attend une dépendance. La connaissance des internals transforme des plaintes vagues en hypothèses testables.

Espace utilisateur vs. espace noyau (juste ce qu’il faut)

À un niveau élevé, l’espace utilisateur est là où s’exécutent la plupart des apps et services. Quand elles plantent, elles prennent généralement seulement elles-mêmes. L’espace noyau est là où Windows lui‑même et les pilotes s’exécutent ; les problèmes à ce niveau peuvent figer tout le système, déclencher un bugcheck (écran bleu) ou dégrader silencieusement la fiabilité.

Vous n’avez pas besoin de théorie profonde pour utiliser cette distinction — juste assez pour choisir les preuves. Une application qui consomme le CPU tourne souvent en espace utilisateur ; des réinitialisations de stockage répétées ou des problèmes de pilote réseau pointent souvent vers l’espace noyau.

Dépannage fondé sur les preuves

L’état d’esprit de Russinovich — reflété dans des outils comme Sysinternals et dans Windows Internals — est « preuve d’abord ». Avant de changer des paramètres, redémarrer aveuglément ou réinstaller, capturez ce que fait le système : quel processus, quel thread, quel handle, quelle clé de registre, quelle connexion réseau, quel pilote, quel événement.

Une fois que vous pouvez répondre à « que fait Windows maintenant, et pourquoi », les correctifs deviennent plus petits, plus sûrs et plus faciles à justifier — et le travail de fiabilité cesse d’être du pompier réactif.

L’approche Sysinternals : rendre l’invisible visible

Sysinternals se comprend mieux comme une « boîte à outils de visibilité » pour Windows : des utilitaires petits et portables qui révèlent ce que le système fait réellement — processus par processus, handle par handle, clé de registre par clé de registre. Plutôt que de traiter Windows comme une boîte noire, Sysinternals vous permet d’observer le comportement derrière des symptômes comme « l’application est lente », « le CPU est élevé » ou « le serveur perd des connexions ».

Faire confiance mais vérifier : ne pas deviner, mesurer

Beaucoup de douleur opérationnelle vient de suppositions plausibles : c’est sûrement le DNS, c’est probablement l’antivirus, Windows Update est encore bloqué. L’état d’esprit Sysinternals est simple : fiez-vous à vos instincts pour formuler une hypothèse, puis vérifiez-la avec des preuves.

Quand vous pouvez voir quel processus consomme le CPU, quel thread attend, quel chemin de fichier est martelé, ou quelle valeur de registre est réécrite, vous cessez de débattre des opinions et vous commencez à réduire les causes. Ce basculement — du récit à la mesure — rend la connaissance des internals pratique, pas académique.

Pourquoi Sysinternals brille pendant les incidents en direct

Ces outils sont conçus pour le moment « tout brûle » :

• Peu de friction : beaucoup d’outils s’exécutent sans installation et démarrent rapidement.
• Retour rapide : vous pouvez valider ou rejeter une théorie en quelques minutes.
• Visibilité ciblée : chaque utilitaire répond à une classe de questions (processus, éléments de démarrage, points réseau, usage mémoire).

C’est précieux quand vous ne pouvez pas vous permettre un long cycle d’installation, un déploiement d’agent lourd ou un redémarrage juste pour collecter de meilleures données.

Principes d’utilisation sûre

Sysinternals est puissant, et le pouvoir mérite des garde‑fous :

• Exécutez au besoin : commencez par l’observation en lecture seule ; élevez les privilèges seulement si nécessaire.
• Documentez vos actions : enregistrez horodatages, filtres et actions prises pour que les conclusions soient reproductibles.
• Minimisez les perturbations : préférez capturer des preuves (captures d’écran, logs, traces exportées) plutôt que d’« essayer des corrections » en plein incident.
• Changez avec précaution : si vous devez modifier un paramètre ou tuer un processus, notez la raison et l’effet attendu, puis vérifiez le résultat.

Utilisé ainsi, Sysinternals devient une méthode disciplinée : observez l’invisible, mesurez la vérité et effectuez des changements justifiés, pas optimistes.

Process Explorer & Process Monitor : le duo de débogage du quotidien

Si vous ne gardez que deux outils Sysinternals dans votre trousse d’admin, que ce soit Process Explorer et Process Monitor. Ensemble, ils répondent aux questions les plus courantes « que fait Windows maintenant ? » sans agent, redémarrage ni configuration lourde.

Process Explorer : des réponses rapides en quelques secondes

Process Explorer, c’est le Gestionnaire des tâches avec vision X‑ray. Quand une machine est lente ou instable, il vous aide à cibler quel processus est responsable et à quoi il est lié.

Il est particulièrement utile pour :

• CPU et threads : quel processus consomme du CPU, et est‑ce un thread chaud ou plusieurs ?
• Relations parent/enfant : qu’est‑ce qui a lancé le processus (service, tâche planifiée, mise à jour, action utilisateur) ?
• DLLs et handles : quels modules sont chargés, et quels fichiers/clés/pipes le processus garde ouverts ?

Ce dernier point est un super‑pouvoir de fiabilité : « pourquoi je ne peux pas supprimer ce fichier ? » devient souvent « ce service a un handle ouvert dessus ».

Process Monitor : la piste complète d’activité

Process Monitor (Procmon) capture des événements détaillés sur le système de fichiers, le registre et l’activité process/thread. C’est l’outil pour des questions comme : « que s’est‑il passé quand l’app a gelé ? » ou « qu’est‑ce qui martèle le disque toutes les 10 minutes ? »

Avant d’appuyer sur Capture, formulez la question :

• Quel est le symptôme (logon lent, disque élevé, crash, accès refusé) ?
• Quand survient‑il (au démarrage, à 09:00, après la mise en veille) ?
• Quelle machine et quel contexte utilisateur (un seul serveur, un seul profil, seulement sur VPN) ?

Capturez seulement ce dont vous avez besoin (le bruit est l’ennemi)

Procmon peut vous submerger à moins de filtrer agressivement. Commencez par :

• Filtrer sur un Process Name ou un PID spécifique.
• Utiliser des règles Include pour le chemin qui vous intéresse (ex. dossier de config) et exclure le reste.
• Capturer pendant une courte fenêtre autour du symptôme, puis arrêter.

Ce que vous en retirez

Les résultats courants sont très pratiques : identifier un service malveillant qui interroge sans cesse une clé de registre manquante, repérer un scan « temps réel » qui touche des milliers de fichiers, ou trouver une tentative de chargement de DLL manquante (« NAME NOT FOUND ») qui explique pourquoi une app ne démarre que sur une machine.