Observateur d’événements pour les humains : trouver les erreurs réelles en 5 minutes

L’état d’esprit des cinq minutes (ce que vous cherchez vraiment)

Votre travail dans l’Observateur d’événements n’est pas de lire des logs. C’est de prendre une décision sous incertitude. Plus précisément, vous essayez de répondre à quatre questions :

1. Qu’est-ce qui a changé ? (Mise à jour, pilote, certificat, stratégie, chemin de stockage, synchronisation temporelle, droits de compte.)
2. Quand cela a-t-il commencé ? (Corrélez avec un déploiement/redémarrage/sauvegarde/fenêtre de correctifs.)
3. Quel composant échoue en premier ? (Les erreurs de stockage précèdent souvent les plantages d’application ; les échecs d’authentification précèdent les pannes de service.)
4. Est-ce une vraie erreur ou une plainte de fond ? (Certaines « erreurs » ne sont que Windows dramatisant.)

L’Observateur d’événements fait échouer les gens parce qu’ils traitent toutes les icônes rouges de la même façon. Ne le faites pas. Priorisez les signaux qui sont :

• Corrélés dans le temps avec le début de l’incident.
• Répétés (même Event ID + même source récurrente).
• Inter-logs (System + Application + un journal opérationnel spécifique qui concordent).
• Actionnables (pointent vers un périphérique, un fichier, un compte, un certificat ou un nom de service).

Et aussi : arrêtez de faire des captures d’écran de l’Observateur d’événements comme si c’était un oiseau rare. Exportez les événements. Interrogez-les. Comparez-les. Nous sommes en 2026, pas en 2006.

Blague #1 : L’Observateur d’événements, c’est l’endroit où les avertissements prennent leur retraite—confortablement, bruyamment, et sans jamais payer de loyer.

Une citation pour rester honnête :

Idée paraphrasée — W. Edwards Deming : sans données, vous n’êtes qu’une autre personne avec une opinion.

Mode opératoire de diagnostic rapide : vérifications 1re/2e/3e

Minute 0–1 : définissez la fenêtre de défaillance

• Quel est le premier horodatage du symptôme vu par les utilisateurs ?
• Un redémarrage a-t-il eu lieu ? Un correctif ? Un renouvellement de certificat ? Un basculement de stockage ?
• Choisissez une fenêtre : 15 minutes avant le début du symptôme jusqu’à 15 minutes après.

Décision : si vous ne pouvez pas borner le temps, vous ne pouvez pas borner la réalité. Obtenez l’heure d’abord.

Minute 1–2 : Journal System pour la vérité au niveau plateforme

Commencez dans Journaux Windows → Système. Pourquoi ? Parce que quand le plancher s’effondre, le mobilier (les applications) se plaint après.

Filtrez par niveaux : Critique, Erreur. Triez par Date et heure. Concentrez-vous sur des sources comme :

• Kernel-Power (redémarrages inattendus)
• Disk / storahci / nvme / iaStorAC (chemin de stockage)
• Ntfs (système de fichiers)
• Service Control Manager (services ne démarrant pas)
• WHEA-Logger (erreurs matérielles)
• Schannel (TLS/handshake certificat)

Décision : si le journal Système montre des réinitialisations de disque, des délais d’attente du contrôleur, WHEA ou des événements d’alimentation, cessez de blâmer l’application. Corrigez la plateforme d’abord.

Minute 2–3 : Journal Application pour savoir « qui est mort en premier »

Allez dans Journaux Windows → Application et filtrez de la même façon. Recherchez :

• Application Error (Event ID 1000)
• .NET Runtime (Event ID 1026)
• SQL Server, IIS, VSS, MSExchange*, sources fournisseurs
• SideBySide (problèmes de manifeste / CRT)

Décision : identifiez le premier plantage dans la fenêtre, puis corrélez en arrière : qu’est-ce qui l’a précédé dans System ?

Minute 3–4 : Journaux opérationnels pour le sous-système suspecté

La plupart des vraies réponses ne sont pas dans « Application » ou « System ». Elles sont dans :

• Journaux d’applications et de services → Microsoft → Windows → (composant) → Operational
• Exemples : WindowsUpdateClient/Operational, TaskScheduler/Operational, WinRM/Operational, GroupPolicy/Operational, Security-Kerberos/Operational

Décision : si la défaillance est liée aux mises à jour, à l’authentification ou aux stratégies, les journaux opérationnels vous donneront le vrai code d’erreur et le contexte.

Minute 4–5 : prouvez-le avec une requête, puis exportez

Les clics dans l’Observateur d’événements sont utiles pour l’orientation. Pour la preuve, utilisez Get-WinEvent ou wevtutil et exportez un lot serré.

Décision : si vous ne pouvez pas reproduire le même ensemble d’événements via une requête, vous courez probablement après la mauvaise piste.

Primer sur les journaux d’événements pour adultes

L’Observateur d’événements est un navigateur de base de données, pas un tableau de bord

Le système d’événement Windows est un système de journaux structurés avec des canaux, des fournisseurs, des IDs, des niveaux, des tâches, des opcodes, des mots-clés et des payloads XML. L’Observateur d’événements vous montre une vue aplatie. C’est utile, mais cela masque les meilleures parties : les champs structurés que vous pouvez interroger.

Pensez en « canaux » et « fournisseurs »

Canal est l’endroit où vivent les événements (System, Application, Security, et des centaines de canaux opérationnels). Fournisseur est qui a écrit l’événement (Service Control Manager, Disk, Schannel, WindowsUpdateClient).

Quand quelqu’un dit « cherche l’Event ID 41 », votre question de suivi devrait être : « Event ID 41 de quel fournisseur ? » Parce que les numéros d’Event ID ne sont pas uniques globalement entre fournisseurs.

Les niveaux sont politiques

« Erreur » ne signifie pas toujours erreur. Certains fournisseurs enregistrent des conditions transitoires comme erreurs parce que c’est la seule façon d’attirer l’attention. D’autres sous-déclarent parce que les fournisseurs détestent les tickets de support.

Faites confiance aux motifs, pas aux couleurs.

La corrélation bat l’interprétation

La même cause racine apparaît souvent comme une chaîne :

• Bugbite de stockage (Disk/Ntfs)
• Délai d’attente de service (Service Control Manager)
• Plantage d’application (.NET Runtime/Application Error)
• Plainte utilisateur (« C’est lent »)

Si vous partez du plantage de l’application, vous êtes déjà en retard.

Le journal Security est spécial (et souvent sans rapport)

Les journaux de sécurité sont contrôlés, verbeux et parfois énormes. Ils sont inestimables pour les échecs d’authentification et l’audit de stratégie, mais ils peuvent aussi consommer vos cinq minutes entières. Utilisez-les lorsque vous avez une hypothèse : Kerberos, NTLM, droits de connexion, comptes de service ou changements de GPO.

Faits intéressants & histoire (les parties qui comptent)

• Windows NT a introduit le service Event Log dans les années 1990 comme mécanisme central d’audit ; c’est pourquoi la séparation « System/Application/Security » définit encore des workflows aujourd’hui.
• Event Tracing for Windows (ETW) est devenu l’épine dorsale haute performance de la télémétrie Windows moderne ; de nombreux journaux « Operational » sont basés sur ETW.
• Les Event IDs sont scoped par fournisseur, pas universels. Deux fournisseurs différents peuvent utiliser le même ID pour des significations complètement différentes.
• Les changements de l’ère Vista ont considérablement étendu les canaux (Applications and Services Logs), ce qui explique pourquoi les journaux les plus utiles sont souvent enfouis sous Microsoft → Windows.
• Les événements Schannel sont devenus la sentinelle pour la casse TLS/certificats à mesure que les entreprises durcissaient les bases cryptographiques et désactivaient d’anciens protocoles.
• WHEA (Windows Hardware Error Architecture) a fait remonter les erreurs machine check et les erreurs matérielles corrigées de manière standardisée, c’est pourquoi WHEA-Logger est votre source « le matériel est mécontent ».
• Windows Update a évolué vers la composantisation (CBS, servicing stack), ce qui explique pourquoi les échecs de mise à jour demandent souvent de vérifier plusieurs canaux au-delà des messages basiques de WindowsUpdateClient.
• VSS (Volume Shadow Copy Service) est plus ancien que beaucoup de fournisseurs de sauvegarde qui l’utilisent ; quand il échoue, vos sauvegardes « réussissent » jusqu’à l’essai de restauration. Les logs disent la vérité en premier.
• Les valeurs par défaut de rétention des journaux sont souvent petites sur les serveurs, ce qui détruit silencieusement votre capacité à analyser « quand cela a commencé ».

12+ tâches pratiques : commandes, sorties et décisions

Ci‑dessous des tâches pratiques que vous pouvez lancer immédiatement. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision que vous prenez. Les commandes sont montrées comme si vous étiez sur un hôte Windows avec PowerShell disponible ; l’invite n’est qu’une invite.

Task 1 — Lister les plus gros journaux (trouver ce qui dévore votre historique)

cr0x@server:~$ wevtutil el
Application
Security
System
Microsoft-Windows-WindowsUpdateClient/Operational
Microsoft-Windows-GroupPolicy/Operational
...

cr0x@server:~$ wevtutil gl System
name: System
enabled: true
type: Admin
owningPublisher:
isolation: Application
channelAccess: O:BAG:SYD:(A;;0x5;;;SY)(A;;0x1;;;BA)(A;;0x1;;;SO)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\System.evtx
  retention: false
  autoBackup: false
  maxSize: 20971520

Ce que cela signifie : la taille maximale du journal System est d’environ 20 Mo. Sur des serveurs chargés, cela peut représenter des heures ou des jours d’historique, pas des semaines.

Décision : si vous manquez de contexte, augmentez la taille du journal (et définissez une politique de rétention adaptée à votre environnement). De petits journaux équivalent à une mémoire courte.

Task 2 — Récupérer rapidement les 50 dernières erreurs System (sans GUI, sans défilement)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 50 | Format-Table TimeCreated,Id,ProviderName,Message -AutoSize"
TimeCreated            Id ProviderName           Message
-----------            -- ------------           -------
02/05/2026 02:11:03    7 Disk                   The device, \Device\Harddisk2\DR2, has a bad block.
02/05/2026 02:11:07 129 storahci                Reset to device, \Device\RaidPort0, was issued.
02/05/2026 02:11:15 7000 Service Control Manager The SQLSERVERAGENT service failed to start due to the following error: ...
...

Ce que cela signifie : des blocs défectueux sur le disque et des réinitialisations de contrôleur sont en amont. La défaillance de SQL Agent est un dommage collatéral en aval.

Décision : arrêtez l’optimisation côté application. Lancez un triage stockage/matériel : vérifiez SMART, le firmware du contrôleur, le câblage, le chemin SAN, la latence du stockage VM.

Task 3 — Borner la fenêtre temporelle (l’astuce des « cinq minutes »)

cr0x@server:~$ powershell -NoProfile -Command "$start=(Get-Date).AddMinutes(-30); $end=Get-Date; Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start; EndTime=$end; Level=1,2} | Sort-Object TimeCreated | Select-Object TimeCreated,Id,ProviderName -First 20"
TimeCreated            Id ProviderName
-----------            -- ------------
02/05/2026 01:49:52  6006 EventLog
02/05/2026 01:50:10    2 Kernel-General
02/05/2026 02:11:03    7 Disk
02/05/2026 02:11:07  129 storahci

Ce que cela signifie : au cours des 30 dernières minutes, les premiers événements sérieux surviennent à 02:11. C’est le début de l’incident, même si les utilisateurs l’ont remarqué à 02:15.

Décision : alignez tous les autres journaux sur 02:11 et travaillez à partir de là. Ne poursuivez pas du bruit plus ancien non relié.

Task 4 — Vérifier un redémarrage inattendu vs « quelqu’un l’a rebooté »

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:49:51
Message     : The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Ce que cela signifie : Kernel-Power 41 est un « arrêt non propre ». Il ne dit pas pourquoi ; il dit que l’OS n’a pas eu le temps de dire au revoir.

Décision : associez-le avec des événements BugCheck, des WHEA, des réinitialisations de disque ou des événements d’hyperviseur. Traitez-le comme un symptôme, pas une cause racine.

Task 5 — Trouver les échecs de démarrage de service (car des dépendances cassées ressemblent à « l’app est en panne »)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:15 7000 The SQLSERVERAGENT service failed to start due to the following error: The service did not start due to a logon failure.
02/05/2026 02:11:16 7009 A timeout was reached (30000 milliseconds) while waiting for the SQLSERVERAGENT service to connect.

Ce que cela signifie : un échec de connexion suggère un problème d’identifiants (changement de mot de passe, problème gMSA, droits retirés), pas du CPU ou de la mémoire.

Décision : validez le compte de service, les changements récents de mot de passe et les droits « Log on as a service ». Ne le redémarrez pas 20 fois et n’appelez pas ça « corrigé ».

Task 6 — Identifier les signatures de plantage (Event ID 1000) et le module fautif

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'; Id=1000} -MaxEvents 10 | Select-Object TimeCreated,Message | Format-Table -Wrap"
TimeCreated            Message
-----------            -------
02/05/2026 02:12:02  Faulting application name: w3wp.exe, version: ...
                       Faulting module name: ntdll.dll, version: ...
                       Exception code: 0xc0000374
                       Fault offset: ...

Ce que cela signifie : vous avez eu un crash avec un code d’exception. Le « module fautif » n’est pas toujours le coupable (ntdll rapporte souvent juste le plantage).

Décision : corrélez avec les logs spécifiques à l’application et les changements récents (mises à jour, nouvelles DLL, injection par antivirus). Si répétable, capturez un dump et arrêtez de deviner.

Task 7 — Exceptions du runtime .NET (souvent plus lisibles que les logs fournisseurs)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='.NET Runtime'; Id=1026} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 02:12:01
Message     : Application: MyService.exe
              Framework Version: v4.0.30319
              Description: The process was terminated due to an unhandled exception.
              Exception Info: System.IO.IOException: The network path was not found.

Ce que cela signifie : l’exception contient une défaillance concrète (chemin réseau introuvable). Cela pointe vers SMB, DNS, firewall, ou un partage manquant, pas « . NET est cassé ».

Décision : vérifiez la résolution de noms et la disponibilité du partage ; inspectez le journal System pour des erreurs réseau autour du même horodatage.

Task 8 — Erreurs de stockage et système de fichiers : Disk, Ntfs, et « surprise, c’est le SAN »

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Ntfs'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:10   55 The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume.

Ce que cela signifie : NTFS signale une corruption. Cela peut être une vraie panne disque, un problème de chemin de stockage, ou un souci hôte/VM provoquant des problèmes d’ordre d’écriture.

Décision : si vous êtes sur une VM, vérifiez la santé du stockage hôte et des chaînes de snapshot. Si physique, vérifiez la santé du disque et les logs du contrôleur. Planifiez une fenêtre contrôlée pour chkdsk ; ne le lancez pas « à l’aveugle » sur un volume de base de données critique sans revue d’impact.

Task 9 — Événements matériels WHEA (les erreurs corrigées restent des erreurs)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:10:58   17 Warning          A corrected hardware error has occurred. Component: PCI Express Root Port...

Ce que cela signifie : les erreurs corrigées signifient que le système a récupéré, mais votre matériel se dégrade ou votre bus est mécontent (souvent NIC/HBA/PCIe).

Décision : traitez cela comme un indicateur avancé. Escaladez vers le matériel/fournisseur, vérifiez l’alignement firmware/driver et corrélez avec les réinitialisations disque/réseau.

Task 10 — Échecs TLS et certificats via Schannel (quand « l’API est en panne » est en fait crypto)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Level=2} -MaxEvents 10 | Format-Table TimeCreated,Id,Message -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:08:44 36874 An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server.

Ce que cela signifie : les paramètres crypto client et serveur ne se recoupent pas. Cela arrive souvent après des changements de durcissement ou des bibliothèques clientes anciennes.

Décision : identifiez le client (souvent dans les logs applicatifs ou traces réseau) et corrigez le chevauchement des suites de chiffrement/protocoles. Évitez de « réactiver TLS 1.0 » sauf si votre appétit pour le risque est une reconstitution historique.

Task 11 — Échecs de Windows Update avec détails opérationnels (arrêtez de dépendre du GUI)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 01:40:12   20 Installation Failure: Windows failed to install the following update with error 0x800f081f: ...
02/05/2026 01:40:13   25 Windows Update failed to download an update. Error: 0x8024401c

Ce que cela signifie : vous avez de vrais codes d’erreur. 0x800f081f indique souvent des problèmes du magasin de composants/source de fichiers ; 0x8024401c concerne souvent la connectivité/WSUS/proxy.

Décision : séparez les problèmes « servicing stack/component store » des problèmes « réseau/WSUS ». Différents propriétaires, différentes corrections.

Task 12 — Interroger par fournisseur + ID en XPath (la précision compte)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Provider[@Name='Disk'] and (EventID=7))]]" /f:text /c:3
Event[0]:
  Log Name: System
  Source: Disk
  Date: 2026-02-05T02:11:03.0000000Z
  Event ID: 7
  Task: N/A
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: server01
  Description:
  The device, \Device\Harddisk2\DR2, has a bad block.

Ce que cela signifie : extraction propre et spécifique au fournisseur. C’est ce que vous collez dans les notes d’incident sans honte.

Décision : utilisez des requêtes XPath quand vous avez besoin de preuves reproductibles et moins d’ambiguïté GUI.

Task 13 — Exporter un bundle d’évidence serré (pour escalade ou postmortem)

cr0x@server:~$ wevtutil epl System C:\Temp\System.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Application C:\Temp\Application.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Microsoft-Windows-WindowsUpdateClient/Operational C:\Temp\WindowsUpdate-Operational.evtx
The operation completed successfully.

Ce que cela signifie : vous avez maintenant des fichiers EVTX portables qui préservent la structure et peuvent être ouverts ailleurs.

Décision : exportez toujours en EVTX, pas en CSV, quand vous voulez que des ingénieurs fassent du vrai filtrage et de la corrélation plus tard.

Task 14 — Trouver les événements « journal vidé » (parce que parfois le mystère est de la sabotage ou de la panique)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:10:22
Message     : The audit log was cleared.

Ce que cela signifie : quelqu’un (ou quelque chose) a vidé le journal Security. Cela peut être une action de maintenance légitime. Ça peut être un attaquant. Ça peut être un administrateur paniqué qui a essayé de « réduire le bruit ».

Décision : traitez cela comme un événement de sécurité et de gouvernance. Validez les enregistrements de changement, les accès privilégiés et pourquoi cela a été fait. Vider des journaux n’est pas du dépannage ; c’est détruire des preuves.

Task 15 — Détecter les problèmes de synchronisation temporelle (quand auth et TLS échouent « sans raison »)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Level=2,3} -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:05:01   36 Warning          The time service has not synchronized the system time for 86400 seconds because no time data was available.

Ce que cela signifie : la dérive temporelle peut casser Kerberos, les certificats, les tâches planifiées et provoquer des comportements applicatifs « aléatoires ».

Décision : corrigez la hiérarchie NTP/temps. Ne contournez pas en assouplissant les politiques d’authentification ; vous reviendrez ici la semaine suivante.

Trois mini-histoires d’entreprise (parce que la réalité est plus étrange)

Histoire 1 : l’incident causé par une mauvaise hypothèse

Le ticket disait : « La base de données est lente après le patch. » Le DBA insistait sur une régression du plan de requête. L’équipe Windows insistait sur un paramètre SQL. Tout le monde était certain. Personne n’avait raison.

Sur le serveur affecté, le journal System montrait des réinitialisations intermittentes storahci et des avertissements Disk. Le timing collait parfaitement avec la fenêtre « lent », mais l’équipe l’a écarté parce que le tableau de bord du SAN était vert et l’hôte VM ne montrait pas d’alertes.

L’hypothèse erronée était subtile : « Si le SAN est sain, Windows n’enregistrerait pas de réinitialisations de disque. » En pratique, Windows enregistre ce que le guest voit. Un problème de chemin transitoire, un pilote HBA instable ou une configuration multipath défectueuse peut faire subir des délais d’attente au guest alors que l’array semble « sain ». Les tableaux verts ne prouvent pas des E/S vertes.

La correction n’était pas un paramètre de base de données. C’était un problème d’alignement pilote/firmware sur le chemin de stockage de l’hôte. Une fois le chemin stabilisé, la latence des requêtes est revenue à la normale sans toucher à SQL.

Ce qui a sauvé la réponse à l’incident n’a pas été une expertise profonde du stockage. Ce furent cinq minutes de corrélation de journaux disciplinée : réinitialisations disque d’abord, retards de service ensuite, plaintes applicatives ensuite. La plateforme a dit la vérité ; les gens n’aimaient juste pas la réponse.

Histoire 2 : l’optimisation qui s’est retournée contre eux

Une équipe voulait des connexions plus rapides et moins d’écritures « inutiles ». Ils ont réduit la taille des journaux d’événements et activé un écrasement agressif parce que « nous envoyons de toute façon les logs vers un système central ». C’était présenté comme de l’hygiène de performance. Ça a même passé une revue de changement, car personne ne veut être la personne défendant des fichiers journaux plus gros.

Trois semaines plus tard, un contrôleur de domaine a commencé à montrer des échecs d’authentification sporadiques. Les utilisateurs se sont plaints pendant des jours : « Parfois ça marche, parfois non. » Incident intermittent classique : douleur maximale, preuve minimale.

Quand l’équipe a finalement regardé l’Observateur d’événements, les journaux Security et System ne contenaient que quelques heures d’historique. Les échecs s’étaient produits « hier », mais hier n’existait plus. La centralisation des logs existait sur le papier ; le service de connecteur avait échoué silencieusement, et bien sûr ses propres logs avaient été écrasés aussi.

Ils ont reconstitué la timeline avec d’autres preuves (logs clients, logs de firewall et ce qui restait sur le DC). La cause racine s’est avérée être une dérive temporelle sur le chemin NTP d’un site, provoquant des échecs Kerberos à certains moments. Corriger la synchronisation temporelle a résolu le problème. Mais le temps de résolution a été dominé par une blessure auto-infligée à la rétention des données.

Leçon : optimiser la journalisation en réduisant la rétention, c’est comme économiser sur les détecteurs de fumée en retirant les piles. Oui, le bip s’arrête. Et le bâtiment peut toujours brûler.

Histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la situation

Un service lié aux paiements a commencé à échouer des handshakes TLS après un durcissement de routine. L’équipe applicative jurait que rien n’avait changé dans leur déploiement. L’équipe sécurité jurait que le baseline était sûr. Le service était en panne, et tout le monde répétait son récit de blâme préféré.

Un SRE a fait quelque chose douloureusement ennuyeux : il a exporté les journaux pertinents (System, Application et événements liés à Schannel) pour une fenêtre de deux heures, puis les a comparés à la fenêtre saine de la semaine précédente sur le même hôte.

La différence était évidente : Schannel a commencé à enregistrer des erreurs de non‑correspondance de suites de chiffrement juste après une mise à jour de stratégie. Cela a permis d’identifier le « quoi a changé » à un moment et un sous‑système spécifiques. Ensuite, les journaux opérationnels dans la pile applicative montraient la version de la bibliothèque cliente en échec, qui était plus ancienne et ne supportait pas les suites restantes.

La correction a été ciblée : mettre à jour la bibliothèque cliente et conserver le baseline durci. Pas de rollback. Pas de réactivation d’anciens protocoles. Pas de disputes nocturnes du type « faisons fonctionner ça à tout prix ».

La pratique ennuyeuse gagne : conservez assez d’historique de logs, exportez des preuves EVTX structurées et comparez à une baseline connue bonne. Ce n’est pas glamour, mais c’est ainsi que vous gardez vos weekends.

Blague #2 : La façon la plus rapide d’améliorer votre MTTR est d’empêcher « encore un redémarrage » d’être votre principal outil de diagnostic.

Erreurs courantes : symptôme → cause racine → correction

1) « Tout est rouge » dans l’Observateur d’événements

Symptôme : Des centaines d’erreurs ; vous ne savez pas par où commencer.

Cause racine : Pas de fenêtre temporelle, pas de corrélation, et vous mélangez du bruit chronique avec une défaillance aiguë.

Correction : Définissez une fenêtre de 30 minutes autour du début du symptôme. Filtrez sur Critique+Erreur. Triez par heure. Identifiez la première paire fournisseur/ID répétée.

2) Kernel-Power 41 et panique

Symptôme : L’Event ID Kernel-Power 41 apparaît ; les gens concluent « alimentation » ou « bug Windows ».

Cause racine : 41 est un marqueur générique d’arrêt non propre ; il est généralement en aval d’un plantage, d’un blocage, d’une coupure de courant ou d’un reset d’hyperviseur.

Correction : associez-le à des événements BugCheck, des avertissements WHEA, des réinitialisations disque/contrôleur et des logs d’hyperviseur. Traitez 41 comme une miette de pain, pas un diagnostic.

3) Application Error 1000 blâmée sur « ntdll.dll »

Symptôme : Le crash montre ntdll.dll ; les équipes blâment Windows.

Cause racine : ntdll rapporte fréquemment, mais n’est pas l’offenseur. La cause réelle est souvent une corruption mémoire, un module incompatible, un outil de sécurité injecté, ou une faute I/O en amont.

Correction : corrélez avec .NET Runtime (1026), les logs fournisseurs et les changements récents. Capturez des dumps de plantage si répétable. Vérifiez les erreurs stockage/réseau précédant le crash.

4) Service Control Manager 7000/7009 ignorés

Symptôme : Le service ne démarre pas ; les gens le redémarrent en boucle.

Cause racine : Échec de logon du compte de service, défaillance de dépendance, ou I/O lente provoquant des timeouts.

Correction : lisez le message exact du SCM. Validez les identifiants/les droits. Si timeouts, investiguez la latence disque et la chaîne de dépendances, pas le binaire du service.

5) Erreurs Schannel « corrigées » en réactivant d’anciens protocoles

Symptôme : L’échange TLS échoue ; quelqu’un propose d’activer TLS 1.0/ciphers faibles.

Cause racine : La bibliothèque cliente ne parle pas TLS moderne ou ne supporte pas les suites ; le durcissement a supprimé les options legacy.

Correction : mettez à jour la pile cliente ou configurez un chevauchement de suites supportées en sécurité. Ne réactivez les crypto faibles qu’avec une exception explicite et un plan de sortie.

6) Échecs de mise à jour traités comme « Windows qui fait son truc »

Symptôme : Les mises à jour échouent de façon intermittente ; les équipes reportent les patchs indéfiniment.

Cause racine : Problèmes du magasin de composants, proxy/WSUS en panne, ou mismatch du servicing stack ; les détails sont dans les journaux opérationnels, pas dans le GUI.

Correction : utilisez WindowsUpdateClient/Operational et les codes d’erreur. Séparez réseau vs servicing et assignez au bon propriétaire.

7) Journaux manquants au pire moment

Symptôme : Vous ne trouvez pas d’événements de la semaine dernière quand le problème a commencé.

Cause racine : Taille des journaux trop petite, écrasement activé, ou journaux vidés.

Correction : augmentez la taille des journaux ; surveillez la santé du forwarding des logs ; alertez sur les événements de vidage de logs ; exportez des preuves pendant les incidents.

8) Dérive temporelle provoquant des échecs auth et TLS « aléatoires »

Symptôme : Échecs Kerberos, erreurs de certificats, tâches planifiées manquantes.

Cause racine : Mauvaise configuration hiérarchie NTP/temps, source de temps bloquée, confusion de synchronisation hôte VM.

Correction : validez les événements du Windows Time Service ; corrigez les sources temporelles ; assurez-vous que la hiérarchie temporelle du domaine est respectée.

Checklists / plan étape par étape (triage reproductible)

Checklist A — Triage Observateur d’événements en cinq minutes (vitesse humaine)

1. Notez la fenêtre de défaillance (estimation de l’heure de début, services affectés, dernier état connu bon).
2. Journal System d’abord : filtrez Critique+Erreur, concentrez-vous sur Disk/Ntfs/stor*; WHEA; Kernel-Power; SCM; Schannel.
3. Identifiez la première erreur répétée « nouvelle » dans la fenêtre. Le nouveau compte plus que le fort.
4. Journal Application ensuite : trouvez le premier crash/exception ; notez le nom du processus et le code d’erreur.
5. Journal opérationnel ensuite : choisissez le canal du sous‑système (WindowsUpdateClient, GroupPolicy, Kerberos, WinRM, TaskScheduler, etc.).
6. Corrélez les horodatages : construisez une séquence de 5–10 événements. Les incidents sont des récits.
7. Prouvez via une requête (Get-WinEvent/wevtutil) et exportez des preuves EVTX.
8. Prenez une décision : problème plateforme vs application vs identité/stratégie vs mise à jour/régression.

Checklist B — Si vous suspectez stockage ou système de fichiers

1. Recherchez dans System les événements Disk, storahci/nvme/iaStor*, Ntfs, volsnap dans la fenêtre.
2. Cherchez des motifs : réinitialisations (129), mauvais blocs (7), corruption NTFS (55), erreurs d’écriture différée.
3. Vérifiez si les défaillances coïncident avec sauvegardes, snapshots ou jobs lourds.
4. Décidez : problème disque côté guest vs chemin host/SAN vs mismatch pilote/firmware.
5. Escaladez avec des journaux exportés et une fenêtre temporelle précise, pas « ça fait longtemps que c’est lent ».

Checklist C — Si vous suspectez identité/auth/stratégie

1. Journal System : avertissements Time-Service, problèmes Netlogon, journaux Kerberos opérationnels.
2. Erreurs SCM : « logon failure » au démarrage d’un service indique généralement identité/stratégie.
3. Journal Security uniquement quand vous avez un ID/fournisseur ciblé ; sinon c’est un piège à temps.
4. Confirmez les changements GPO récents et s’ils correspondent à l’heure de début de l’événement.

Checklist D — Si vous suspectez des mises à jour

1. WindowsUpdateClient/Operational : capturez les codes d’erreur et le contexte exact de la mise à jour.
2. System/Application : cherchez des erreurs liées au servicing stack et au component store autour du même moment.
3. Décidez : réseau/WSUS/proxy vs component store.
4. Documentez les codes d’erreur exacts dans le dossier d’incident. Ils importent.

FAQ

1) Pourquoi je vois des événements « Error » sur des serveurs sains ?

Parce que certains fournisseurs enregistrent des conditions transitoires et récupérables comme erreurs (surtout les timeouts réseau et de service). Jugez par corrélation : même heure que le symptôme, répétition et confirmation inter‑logs.

2) Quel est le meilleur journal pour commencer ?

System. Il capture le matériel, les pilotes, le stockage, l’alimentation et le démarrage des services—les choses qui font échouer les applications ensuite.

3) Dois‑je me concentrer sur les Event IDs ou les sources ?

Les deux, mais commencez par le fournisseur/source plus l’Event ID. Les Event IDs seuls sont ambigus entre fournisseurs. « Event ID 41 » signifie Kernel-Power ; « Event ID 41 » ailleurs peut signifier tout autre chose.

4) Combien de temps dois‑je conserver les journaux ?

Assez longtemps pour répondre à « quand cela a commencé ? » Pour beaucoup de serveurs, cela signifie des semaines, pas des jours. Si vous centralisez les logs, conservez malgré tout une rétention locale suffisante pour survivre à des pannes de forwarding.

5) Est‑ce que Kernel-Power 41 est toujours matériel ?

Non. C’est un marqueur d’arrêt non propre. Ça peut être une coupure d’alimentation, un bugcheck, un gel, un reset d’hyperviseur, ou quelqu’un appuyant sur le bouton d’alimentation (oui, ça arrive). Associez‑le à d’autres événements.

6) Comment savoir si un crash est causé par un problème de stockage ?

Cherchez des réinitialisations disque/contrôleur, des erreurs NTFS, des échecs d’écriture différée ou des problèmes volsnap précédant le crash. Si des erreurs de stockage précèdent des fautes applicatives dans la même fenêtre, considérez le stockage comme suspect.

7) Pourquoi l’Observateur d’événements « se fige » parfois quand je clique sur un journal ?

De gros journaux + rendu coûteux + accès distant peuvent être lents. Utilisez Get-WinEvent pour récupérer une fenêtre temporelle bornée ou un petit nombre d’événements. Les requêtes évoluent mieux que les clics.

8) Quand dois‑je exporter en EVTX vs copier/coller du texte ?

Exportez en EVTX quand vous avez besoin de filtrage structuré, de corrélation ou de partager avec un autre ingénieur. Copier/coller du texte convient pour un événement unique dans une timeline d’incident, mais perd la structure.

9) Est‑il sûr de vider les journaux comme « maintenance » ?

Rarement. Vider les journaux détruit la continuité forensique et rend l’analyse de tendance impossible. Si nécessaire, faites‑le sous contrôle de changement, exportez d’abord et enregistrez qui/quoi/quand/pourquoi.

10) Que faire si je ne trouve rien dans System ou Application ?

Alors vous êtes probablement dans un canal opérationnel (WindowsUpdateClient, GroupPolicy, Kerberos, TaskScheduler, Defender, WinRM) ou le problème est externe (équipement réseau, dépendance en amont). Passez aux journaux du sous‑système et vérifiez la fenêtre temporelle.

Prochaines étapes (quoi faire après avoir « trouvé » le problème)

Trouver l’erreur n’est pas la même chose que réparer le système. Le geste professionnel est de transformer votre découverte de cinq minutes en fiabilité durable :

1. Exportez des preuves (EVTX) pour System, Application et le canal opérationnel pertinent pour la fenêtre d’incident.
2. Écrivez une courte timeline d’incident avec 5–10 événements clés dans l’ordre. Incluez le fournisseur, l’Event ID et l’horodatage.
3. Classez la défaillance : plateforme/stockage, identité/stratégie, mise à jour/régression, bug applicatif, ou dépendance externe.
4. Corrigez la cause en amont en premier. Les réinitialisations de stockage causent des pannes applicatives « mystérieuses » ; la dérive temporelle cause des échecs d’authentification « aléatoires ».
5. Rendez les journaux survivables : augmentez la rétention, surveillez la santé du forwarding et alertez sur les événements de vidage de logs.
6. Automatisez la requête que vous avez utilisée aujourd’hui. Si elle vous a sauvé une fois, elle vous sauvera encore—probablement à 02:17.

Si vous ne retenez rien d’autre : arrêtez de lire l’Observateur d’événements comme un roman. Interrogez‑le comme un système. Votre disponibilité vous remerciera.