Votre serveur Windows Server 2019 plante avec l’écran bleu « UNEXPECTED_KERNEL_MODE_TRAP (0x7F) », paramètre 0x8 ? Voici un guide opérationnel, orienté résultats, pour diagnostiquer un double fault, stabiliser la plate‑forme et éviter le retour de ce BSOD.
Vue d’ensemble du problème
Un hôte Windows Server 2019 s’est arrêté brutalement sur un écran bleu indiquant UNEXPECTED_KERNEL_MODE_TRAP (0x0000007F) avec le paramètre 0x8, signature d’une double fault au niveau noyau. L’analyse du dump mémoire mentionne :
- Surcharge de pile noyau conduisant à un double fault.
- Processus actif au moment du crash :
dns.exe(service DNS). - Pilote tiers chargé :
epfw.sys(module pare‑feu ESET).
Les double faults surviennent le plus souvent lorsqu’un pilote provoque un stack overflow en noyau (empilement excessif d’appels) ou lorsqu’un composant matériel — fréquemment la mémoire — se comporte de manière erratique. Sur des serveurs exposés à des pilotes de filtrage (sécurité, sauvegarde, stockage), la profondeur de pile peut atteindre la limite autorisée par le noyau, particulièrement sous charge réseau/disque.
Symptômes et indices techniques
- Événements BugCheck et Kernel‑Power dans le journal Système, suivis d’un redémarrage inattendu.
- Dumps générés dans
C:\Windows\MEMORY.DMPet/ouC:\Windows\Minidump\*.dmp. - Stack trace souvent non exploitable (double fault), mais des hints (module chargé, thread courant) révèlent parfois le ou les pilotes en cause.
- Contexte applicatif : charge DNS élevée (
dns.exe), trafic réseau soutenu, sauvegarde à chaud, antivirus actif.
Comprendre le code 0x7F paramètre 0x8 (double fault)
Le bugcheck 0x7F est déclenché quand le CPU rencontre un piège noyau inattendu. Le paramètre 0x8 correspond à une double fault : un second piège survient alors que le CPU tente déjà de traiter une première exception, et la pile d’interruptions ne permet plus de poursuivre. En pratique :
- Logiciel : accumulation d’appels dans des pilotes de filtrage (antivirus/pare‑feu, minifiltres de fichiers, drivers de sauvegarde/déduplication, filtres NDIS, pilotes de stockage) ⇒ dépassement de la pile noyau.
- Matériel : RAM défectueuse ou instable (timings/voltage), micro‑erreurs CPU, carte mère instable, BIOS/microcode anciens.
- Paramétrage : overclocking, XMP agressif, options BIOS non validées en production.
Dans le cas décrit, la présence de epfw.sys (ESET firewall) et le processus dns.exe au moment du plantage renforcent l’hypothèse d’une profondeur de pile excessive côté réseau, sans exclure un problème RAM sous‑jacent.
Causes probables, synthèse orientée action
| Cause | Indicateurs | Action immédiate |
|---|---|---|
| Matériel (RAM/CPU/CM) | BSOD aléatoires, erreurs WHEA, historiques d’ajout de RAM | Tests mémoire prolongés, remise aux fréquences JEDEC, MàJ BIOS |
| Empilement de filtres (I/O, réseau) | Multiples agents temps réel (AV, sauvegarde, DLP, dédup) | Réduire au minimum les filtres actifs, tests A/B par désactivation |
| Pilote tiers obsolète | Modules de sécurité/stockage datés (ex. epfw.sys) | Mettre à jour vers une version stable, ou désactiver à blanc |
| Firmware/microcode | Plateforme ancienne, microcodes non appliqués | MàJ BIOS/UEFI, microcodes CPU, firmware RAID/NIC |
| Paramètres BIOS agressifs | XMP/overclock, C‑States atypiques | Revenir à des paramètres conformes constructeur |
Arbre décisionnel de dépannage rapide
- Stabiliser : désactiver le redémarrage auto, vérifier la collecte des dumps, sauvegarder le
MEMORY.DMP. - Sanity check matériel : mémoire à fréquence nominale non overclockée (pas de XMP en prod), quick test RAM/CPU.
- Réduire la pile : geler les outils non essentiels (un seul AV temps réel), désactiver temporairement les filtres non critiques.
- Mettre à jour : pilotes chipset/stockage/réseau, module ESET (
epfw.sys), firmware BIOS/NIC/RAID. - Driver Verifier ciblé sur les pilotes tiers seulement, en pré‑production si possible.
- Analyse WinDbg : vérifier !analyze -v, threads, pile, modules, consommation de pile.
- Validation : exécuter des charges représentatives (DNS, sauvegarde), surveiller l’absence de nouveaux 0x7F.
Procédure de remédiation détaillée
<h3>Tester la mémoire et le matériel</h3>
<ul>
<li>Planifier un test RAM prolongé (plusieurs passes). En environnement de production, privilégier une fenêtre de maintenance.</li>
<li>Revenir aux <strong>timings/fréquences JEDEC</strong> (désactiver XMP) ; vérifier ECC activé si disponible.</li>
<li>Stress CPU/jeu d’instructions (sans excès thermique) et <strong>surveiller les températures</strong>.</li>
<li>Mettre à jour <strong>BIOS/UEFI</strong> et firmwares RAID/NIC.</li>
</ul>
<h3>Mettre à jour ou retirer les pilotes récents</h3>
<ul>
<li>Identifier tout changement (agent de sécurité, pilote de stockage, outil de sauvegarde) <em>avant</em> le premier crash.</li>
<li>Revenir à la dernière version <strong>stable</strong> validée en entreprise — éviter les bêtas.</li>
<li>Mettre à jour les <strong>chipsets</strong>, pilotes <strong>stockage</strong> (SAS/RAID/NVMe), <strong>réseau</strong> (NDIS), et services d’intégration Hyper‑V/VMware Tools pour les VMs.</li>
</ul>
<h3>Vérifier les pilotes tiers de sécurité (ex. ESET)</h3>
<p>Le module <code>epfw.sys</code> (pare‑feu ESET) est souvent présent dans la pile réseau. Bonnes pratiques de test :</p>
<ul>
<li>Mettre à jour vers la branche LTS/Entreprise recommandée par l’éditeur.</li>
<li>Tester temporairement avec le pare‑feu/IPS en <strong>mode désactivé</strong> (ou politique permissive) pour mesurer l’impact sur la stabilité.</li>
<li>Éviter le cumul : ne conservez qu’<strong>une seule</strong> solution de protection temps réel active.</li>
<li>Si l’instabilité disparaît sans <code>epfw.sys</code>, ouvrir un ticket éditeur avec les minidumps et la version précise des modules.</li>
</ul>
<h3>Réduire la profondeur de la pile système</h3>
<p>Chaque filtre (fichier, réseau, stockage) ajoute des frames à la pile noyau. Quelques leviers concrets :</p>
<ul>
<li>Désactiver les minifiltres non essentiels (déduplication, DLP, outils de sauvegarde à chaud) pendant le diagnostic.</li>
<li>Sur réseau, limiter les filtres NDIS en parallèle (pare‑feu, QoS, inspection TLS, capture persistante).</li>
<li>Éviter d’instrumenter simultanément ETW/traceurs agressifs et filtres gourmands sous forte charge.</li>
</ul>
<h3>Contrôler l’intégrité système</h3>
<pre><code>cmd /c sfc /scannowDISM /Online /Cleanup-Image /RestoreHealth
Vérifiez ensuite le journal des événements Système & Application sur les 60 minutes précédant le BSOD.
<h3>Valider après chaque changement</h3>
<p>Redémarrez, chargez le service DNS de façon représentative et laissez tourner plusieurs jours. S’il n’y a plus de 0x7F, passez à l’étape suivante jusqu’à identifier la cause racine.</p>Analyse des dumps avec WinDbg : commandes utiles
Ouvrez le dump (MIMIDUMP.DMP ou MEMORY.DMP) dans WinDbg et exécutez :
!analyze -v
.r* ; vérifier l'état des registres
kv ; afficher la pile verbosée
!thread ; thread courant
!process 0 1 ; processus courant (reconnaître dns.exe)
lmvm epfw ; détails du module epfw.sys chargé
!verifier 3 ; état de Driver Verifier s'il est actif
!stacks 2 ; piles noyau par type (si disponibles)
!handle 0 3 ; objets du thread/processus
Pour la consommation de pile, recherchez des patterns d’appels répétés (minifiltres, callbacks de pare‑feu/NDIS, hooks de sauvegarde). En cas de double fault, la pile peut être incomplète ; misez sur les loaded modules et les derniers contextes connus (processus/IRQL).
Astuce : si dns.exe est le processus courant, rejouez une charge de requêtes DNS en labo avec et sans le filtre incriminé (epfw.sys) pour qualifier la corrélation.
Driver Verifier : quand et comment
Utilisez Driver Verifier pour stresser les pilotes tiers suspects — jamais en pleine production sans fenêtre de tir.
verifier /standard /driver epfw.sys
verifier /querysettings
rem Pour annuler :
verifier /reset
- Ciblez d’abord les pilotes non‑Microsoft (évitez
verifier /all). - Sur crash reproduit, comparez l’empreinte du call stack et corrélez avec la version du pilote.
Commandes et scripts d’inventaire (prêt à copier)
<h3>Lister les minifiltres et leur ordre</h3>
<pre><code>fltmc filtersfltmc instances
<h3>Inspecter les liaisons NDIS (filtres réseau)</h3>
<pre><code>PowerShellGet-NetAdapterBinding -Name * | Where-Object {$_.DisplayName -match « Filter|Firewall|NDIS|WFP »} | Format-Table -Auto
<h3>Identifier les pilotes tiers chargés</h3>
<pre><code>driverquery /v /fo table > C:\Temp\drivers.txtPowerShell Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DriverProviderName -ne « Microsoft » } | Select-Object DeviceName, DriverVersion, DriverProviderName, DriverDate | Sort-Object DriverDate -Descending
<h3>Événements à proximité du crash</h3>
<pre><code>PowerShell$since = (Get-Date).AddDays(-7) Get-WinEvent -FilterHashtable @{LogName=’System’; StartTime=$since} | Where-Object { $_.Id -in 41,1001,6008 } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message | Format-List
<h3>Vérifier l’état de collecte des dumps</h3>
<pre><code>wmic RECOVEROS get DebugInfoType, DebugFilePath, OverwriteExistingDebugFile, AutoReboot</code></pre>Bonnes pratiques spécifiques à Windows Server 2019 (DNS + sécurité)
- Évitez d’empiler plusieurs produits de sécurité en temps réel sur le rôle DNS. Conservez un seul filtre réseau/fichier au cœur du flux.
- Si vous utilisez un agent de sauvegarde « à chaud », validez sa compatibilité et son altitude de minifiltre avec la solution de sécurité.
- Sur hôtes virtualisés, mettez à jour les services d’intégration Hyper‑V ou VMware Tools.
- Segmenter la charge : si possible, dédiez le rôle DNS à une VM légère plutôt qu’à un hôte multi‑rôles lourdement instrumenté.
Tableau de remédiation priorisée
| Priorité | Action | Critère de succès | Rollback |
|---|---|---|---|
| Élevée | MàJ BIOS/microcode + pilotes NIC/stockage | 7 jours sans 0x7F | Revenir à la version stable précédente |
| Élevée | Désactivation temporaire du pare‑feu ESET (epfw.sys) | Crash disparaît sous charge DNS | Réactiver avec nouvelle stratégie/version |
| Moyenne | Réduction des filtres de fichiers/sauvegarde | Diminution des latences I/O, aucune récurrence | Réappliquer uniquement les filtres nécessaires |
| Moyenne | Driver Verifier ciblé pilotes tiers | Identification d’un pilote fautif | verifier /reset |
| Élevée | Tests RAM approfondis + retour aux timings stock | Aucune erreur sur ≥ 4 passes | Remplacement de la barrette fautive |
Modèle de plan de test/validation
- Avant : sauvegarder la configuration, collecter drivers/altitudes (
fltmc,driverquery), inventories. - Changement A : mise à jour BIOS + pilotes NIC. Durée d’observation : 7 jours sur charge DNS normale.
- Changement B : mise à jour ESET ou désactivation ciblée. Observation 3–7 jours.
- Changement C : rationalisation des filtres I/O et agents.
- Final : réintégrer progressivement les composants indispensables, un par un.
FAQ (BSOD 0x7F / double fault)
Est‑ce forcément matériel ?
Non. Le paramètre 0x8 pointe vers un double fault. La cause peut être logicielle (pile noyau saturée par des filtres) ou matérielle (RAM instable). D’où l’importance de combiner tests matériels et réduction des filtres.
Pourquoi dns.exe apparaît‑il souvent ?
Le service DNS émet de nombreux appels réseau/driver. Sous forte charge, la pile réseau (pare‑feu/NDIS) et les filtres de sécurité multiplient les transitions noyau, ce qui accentue le risque de dépassement de pile.
Puis‑je activer Driver Verifier en production ?
Évitez. Driver Verifier peut dégrader fortement les performances et provoquer des crashs de stress contrôlé. Utilisez‑le en pré‑prod ou avec fenêtre de maintenance limitée.
Dois‑je désinstaller la solution de sécurité ?
Préférez une désactivation temporaire et méthodique (ou une mise à jour) pour qualifier l’impact. Une fois la cause isolée, coordonnez‑vous avec l’éditeur pour un correctif ou une configuration adaptée.
Checklist opérationnelle (copier/coller)
- ✅ Collecte des dumps activée et testée
- ✅ BIOS/UEFI & firmwares à jour
- ✅ RAM aux timings stock, tests prolongés OK
- ✅ Pilotes NIC/stockage/chipset mis à jour
- ✅ Un seul agent de sécurité temps réel actif
- ✅ Minifiltres non essentiels désactivés
- ✅ ESET (
epfw.sys) mis à jour ou temporairement désactivé pour test - ✅ Driver Verifier exécuté sur pilotes tiers si nécessaire
- ✅ Observation ≥ 7 jours sans 0x7F avant clôture
Modèle de rapport d’incident (exemple)
Titre : BSOD 0x7F (UNEXPECTED_KERNEL_MODE_TRAP) - Windows Server 2019
Hôte : <NomServeur>
Rôle : DNS (dns.exe)
Horodatage : <UTC/local>
Modules tiers présents : epfw.sys (<version>), <autres>
Changements récents : <pilotes/agents/firmwares>
Actions :
* MàJ BIOS/UEFI & NIC/stockage
* Désactivation test ESET pare-feu (epfw.sys) : Oui/Non
* Réduction filtres I/O : Oui/Non (liste)
* Tests RAM :
Résultats :
* Reproduction du crash : Oui/Non
* Journaux associés : Event IDs 41, 1001, 6008
* Statut après 7 jours : Stable/Instable
Conclusion :
* Cause la plus probable :
* Actions définitives :
* Suivi : Points d’attention et pièges fréquents
- Accumulation silencieuse de filtres : chaque agent « utile » ajoute un étage. Rationalisez.
- VMs : vérifier la couche virtuelle (vNIC, vSCSI, pilotes paravirtualisés) autant que l’OS invité.
- Redémarrage automatique : laissez‑le désactivé le temps de collecter un dump exploitable.
- Timings RAM : un serveur doit respecter les profils validés constructeur (pas d’overclock en prod).
Conclusion
Un UNEXPECTED_KERNEL_MODE_TRAP (0x7F, paramètre 0x8) sur Windows Server 2019 est typiquement la conséquence d’un stack overflow noyau dû à l’empilement de filtres (sécurité/stockage/réseau) ou d’une instabilité matérielle (RAM). En appliquant la démarche ci‑dessus — tests matériels, mise à jour des micrologiciels et pilotes, réduction de la profondeur de pile, qualification des pilotes tiers (dont epfw.sys), et validation progressive — vous pouvez stabiliser durablement le rôle DNS et éliminer la récidive du BSOD.