Après extension d’un RAID 6 sur un Dell PowerEdge R740xd utilisé par Veeam, Windows Server 2019 déclenche un BSOD SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007E) au démarrage normal, tandis que le mode sans échec reste stable. Voici un guide de diagnostic et de remédiation complet.
Sommaire
Contexte et symptômes
- Plateforme matérielle : Dell PowerEdge R740xd, contrôleur PERC, baie RAID 6 de 24 disques pour le stockage Veeam Backup et RAID 1 séparé pour le système.
- Événement déclencheur : ajout de 8 disques et extension du volume D:. Reconstruction RAID terminée sans erreur.
- Symptômes : BSOD en moins d’une minute en démarrage normal ; le mode sans échec est stable (pas de crash).
- Constat côté Dell : diagnostics/TSR/firmware sans anomalie. Piste privilégiée : pilote ou composant système.
Ce que signifie ce bug check
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007E) indique qu’un thread noyau a levé une exception non gérée. Dans les environnements serveurs, il s’agit très souvent d’un pilote tiers (stockage, filtre de fichiers, antivirus, sauvegarde) chargé uniquement en démarrage normal. Le fait que le mode sans échec tienne renforce cette hypothèse : Safe Mode n’initialise pas les pilotes non essentiels (start= demand ou boot delayed).
Paramètres du bug check et interprétation
| Paramètre | Signification | Comment l’exploiter |
|---|---|---|
| Arg1 | Code d’exception (p. ex. 0xC0000005 accès mémoire invalide) | Suggère un déréférencement de pointeur par un pilote fautif |
| Arg2 | Adresse où l’exception s’est produite | Se résout en nom de module dans WinDbg (lmv) |
| Arg3 | Paramètre d’exception complémentaire | Utile pour 0xC0000005 : lecture/écriture et adresse de la page |
| Arg4 | Paramètre d’exception complémentaire | Complète l’analyse selon le type d’exception |
Sur des serveurs de sauvegarde, des fautifs fréquents sont : pilotes de contrôleur RAID PERC (percsas3.sys ou dérivés), minifiltres de sauvegarde/antivirus (CBT/driver Veeam, filtres EDR), et, plus rarement, composants ACPI/chipset.
Hypothèses principales
- Pilote tiers chargé seulement en mode normal : service ou minifiltre initialisé tardivement (souvent en Automatic (Delayed Start)).
- Pilote de stockage obsolète ou mal apparié au firmware : après extension RAID, l’intensité I/O change ; un couple firmware/pilote désaligné peut exposer un bug.
- Conflit ACPI/IRQ ou changement de topologie PCIe après ajout de disques.
- Corruption système (fichiers OS) ou erreurs logiques sur le volume étendu.
- Mémoire instable ou option BIOS (caching/shadowing) révélant un défaut latent.
Plan d’action express
Objectif : stabiliser, identifier le fautif et rétablir un démarrage fiable sans perte de données.
- Désactiver le redémarrage auto :
sysdm.cpl> Avancé > Démarrage et récupération > décochez « Redémarrer automatiquement ». Assurez-vous de générer des dumps mémoire (mémoire du noyau). - Collecter les journaux/dumps :
C:\Windows\Minidumpet%SystemRoot%\MEMORY.DMP, ainsi que les journaux Système/Application (Event Viewer). - Activer le journal de démarrage :
bcdedit /set {default} bootlog Yes REM Fichier : C:\Windows\ntbtlog.txt - Essai en démarrage sélectif :
msconfig> onglet Services : masquer les services Microsoft, désactiver tout le reste, valider et tester le boot normal. - Geler les I/O de sauvegarde : stopper temporairement les services Veeam/antivirus pour confirmer l’influence du minifiltre.
- Contrôler l’intégrité OS :
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth - Vérifier le volume étendu :
chkdsk D: /f /rPlanifier si le volume est en cours d’utilisation. - Comparer pilotes Safe Mode vs normal : exploitez
ntbtlog.txtetdriverquerypour isoler les pilotes chargés uniquement en mode normal (voir section dédiée). - Analyser les minidumps avec WinDbg :
!analyze -v, identifier le module fautif et sa pile.
Tableau des solutions et bonnes pratiques
| Étape | Objectif | Commandes / Outils | Remarques clés |
|---|---|---|---|
| Identifier le pilote impliqué | Localiser le fautif via dump et journaux | WinDbg : !analyze -v lm t n .ecxr kv driverquery /v /fo csv > C:\drivers.csv | Concentrez-vous sur pilotes non-Microsoft chargés au moment du crash. |
| Mettre à jour / revenir en arrière | Assainir le stack stockage et filtres | Pilotes PERC H730P/H740P (percsas3), chipset, NIC ; minifiltres Veeam/AV | Assurez l’appairage firmware/pilote. Un firmware trop récent avec un pilote ancien est risqué. |
| Vérifier l’intégrité OS | Écarter une corruption système | sfc /scannow puis DISM /RestoreHealth | Redémarrez et contrôlez CBS.log en cas d’erreurs persistantes. |
| Contrôler volumes et RAID | Détecter secteurs faibles après l’agrandissement | chkdsk D: /f /r ; iDRAC : Consistency Check | Planifiez en fenêtre maint., surtout sur très grands volumes. |
| Tester la mémoire | Exclure une RAM instable | Dell ePSA/SupportAssist ; mdsched.exe | Un 0x7E peut masquer une erreur mémoire sous charge I/O. |
| Désactiver services non essentiels | Valider la thèse « service tiers » | msconfig démarrage sélectif | Réactivez par grappes pour isoler le fautif. |
| Ajuster BIOS/UEFI | Éliminer variables ACPI erronées | Désactiver Memory Caching/Shadowing, appliquer dernier BIOS | Notez la version avant toute mise à jour. |
| Plan de reprise | Éviter perte de données | Export config Veeam ; image système | Faites un snapshot/backup avant changements majeurs. |
Diagnostic approfondi
Analyse des minidumps avec WinDbg
- Symboles :
.symfix .sympath+ srv*C:\symcache*https://msdl.microsoft.com/download/symbols .reload - Analyse automatique :
!analyze -vRelevez MODULE_NAME et IMAGE_NAME ; regardez la stack (kv) pour voir les appelsstorport.sys,classpnp.sys,ntfs.sys, minifiltres (FltMgr). - Valider le module :
lmv m percsas3 lmv m veeam*Comparez la date de compilation et la version. - Contexte d’exception :
.ecxr rInspectez les registres et l’adresse fautive (Arg2 du bug check).
Comparer pilotes entre Safe Mode et démarrage normal
- Activer le journal de boot (déjà fait). Après un boot normal échoué, ouvrez
C:\Windows\ntbtlog.txten Safe Mode. - Exporter la liste des pilotes :
driverquery /v /fo csv > C:\safe-drivers.csv (en mode sans échec) driverquery /v /fo csv > C:\normal-drivers.csv (si possible)Sinon, utilisez l’Observateur d’événements > Système : source Service Control Manager et DriverFrameworks. - Comparer : cherchez les pilotes non-Microsoft présents uniquement en boot normal (minifiltres sauvegarde/AV, agents EDR, HBA additionnels).
Driver Verifier de manière ciblée
Prudence : Driver Verifier peut provoquer des BSOD plus tôt (c’est le but). Utilisez-le sur un créneau contrôlé avec accès console/iDRAC.
- Lancer :
verifier /standard /driver <pilote1.sys> <pilote2.sys>Évitez de cibler tous les pilotes ; concentrez-vous sur les pilotes tiers suspects. - Redémarrer et reproduire. Un nouveau dump devrait pointer précisément le pilote.
- Désactiver ensuite :
verifier /resetSi boot loop, démarrer en Safe Mode ou WinRE, puisverifier /resetou modification hors ligne du registre (voir annexe).
Examiner la pile de stockage
- Contrôleur PERC : relevez version firmware et pilote Windows. Harmonisez-les. Un pilote percsas3 trop ancien peut mal gérer exensions de VD ou I/O soutenues post-agrandissement.
- Storport : surveillez les événements 129 (Reset to device) et 153 (Disk has a bad block). Ils annoncent des timeouts ou médiacontrol.
- Vérifications RAID : lancez une Consistency Check via iDRAC/OMSA et examinez les erreurs correctibles/non corrigibles.
- Test Write Policy : bascule temporaire en Write-Through (dégradations attendues) pour réduire le stress et valider une instabilité liée au cache.
Spécificités Veeam
- Filtres CBT/minifiltres : assurez-vous qu’ils sont compatibles Windows Server 2019. Désactivez temporairement la fonctionnalité CBT sur les jobs ciblant le volume étendu pour tester.
- Services à arrêter pour lever le doute : orchestrateur, transport/proxy, et services d’agent. Si le BSOD disparaît, focalisez l’analyse sur ces pilotes.
- ReFS vs NTFS : de nombreux dépôts Veeam utilisent ReFS pour le fast clone. Vérifiez l’état du volume (intégrité, journalisation) et l’espace libre suffisant pour l’allocateur ReFS.
Système de fichiers et cohérence post-extension
- CHKDSK avec
/rsur D: pour repérer les clusters douteux. - Événements NTFS : 55 (corruption), 57/140/98 (journalisation) ; corrigez avant d’attaquer les pilotes.
Mémoire, ACPI et BIOS
- Tests mémoire : exécutez un test étendu. Des erreurs marginales se révèlent sous forte activité I/O.
- BIOS/UEFI : mettez à jour si raisonnable et documentez. Désactivez Memory Caching/Shadowing. Vérifiez la topologie PCIe (carte HBA/expandeur).
Services tiers et démarrage différé
Comme le crash survient ~1 minute après le boot, suspectez un service en Automatic (Delayed Start). Pour trier rapidement :
msconfig (masquer services Microsoft > Désactiver tout)
Réactivez ensuite par demi-lots (bisection) jusqu’à reproduire le BSOD et isoler le coupable.
Remédiations recommandées, par priorité
| Action | Impact | Détails opérationnels |
|---|---|---|
| Mise à jour/rollback du pilote PERC | Redémarrage requis | Alignez pilote Windows et firmware contrôleur. Si vous venez d’upgrader le firmware, tentez un pilote équivalent ; sinon, rollback à une version stable précédente. |
| Mise à jour des filtres de sauvegarde | Brève interruption des jobs | Mettre à niveau les composants Veeam (CBT/minifiltre). En cas d’instabilité, désactiver temporairement la fonction incrémentale basée bloc pour valider. |
| Désactivation ciblée du pilote fautif | Selon pilote | En Safe Mode : Gestionnaire de périphériques > propriété du périphérique > Roll Back Driver, ou sc config/reg hors ligne (voir annexe) pour Start=4. |
| Réparation OS | Redémarrage | sfc + DISM. En dernier recours : réparation in-place (setup.exe du média) préservant les rôles et données. |
| Validation matériel | Temps de test | ePSA mémoire complète, iDRAC : check cohérence, lecture S.M.A.R.T. agrégé. Un seul disque capricieux peut suffire à déclencher un chemin d’erreur dans un pilote. |
Exemple de séquence de correction
- Boot en Safe Mode, export des journaux et des minidumps.
msconfig: désactiver tous les services non-Microsoft ; test de boot normal : OK ⇒ service tiers fautif.- Réactivation par demi-lots : reproduction du crash après réactivation des services Veeam ⇒ focalisation sur filtres Veeam.
- Driver Verifier sur le pilote Veeam ciblé : nouveau dump identifie le module.
- Mise à jour du composant ; si indisponible ou instable : rollback à la version précédente stable.
- Vérification
chkdskdu volume D: et Consistency Check RAID. - Monitoring post-correction : absence d’événements 129/153/55 pendant 48–72 h.
FAQ
Pourquoi le mode sans échec est-il stable ?
Parce qu’il charge un minimum de pilotes/services. Les minifiltres de sauvegarde et certains drivers de stockage tiers sont ignorés, supprimant le déclencheur du BSOD.
La configuration « Dernière bonne configuration connue » est-elle utile ?
Sur les versions modernes, elle n’apparaît plus au menu de démarrage. Le système gère automatiquement les ControlSets. Préférez le rollback de pilote via le Gestionnaire de périphériques ou la désactivation hors ligne du service/driver.
Dois-je réinstaller Windows ?
Très rarement nécessaire. L’écrasante majorité des 0x7E ici provient d’un pilote tiers. Épuisez d’abord les pistes pilotes/firmware et l’intégrité système.
Indicateurs et journaux utiles
| Source / ID | Indice | Action |
|---|---|---|
| Système / 129 | Réinitialisation du périphérique (storport) | Mettre à jour pilote HBA/RAID ; vérifier chemins et câblage |
| Système / 153 | Bloc défectueux signalé | chkdsk /r ; surveillance RAID |
| Système / 11 et 15 | Erreurs disque/périphérique | Inspecter disque logique/physique via iDRAC/OMSA |
| Application / 1000 | Crash d’un service tiers | Correlate avec heure du BSOD |
Commandes et scripts pratiques
Lister les pilotes tiers par ancienneté
powershell -NoProfile -Command ^
"Get-WmiObject Win32_PnPSignedDriver |
Where-Object { $_.DriverProviderName -ne 'Microsoft' } |
Select DeviceName, DriverProviderName, DriverVersion, DriverDate |
Sort DriverDate -Descending | Format-Table -Auto"
Repérer rapidement les pilotes stockage/HBA
pnputil /enum-drivers | findstr /i "perc sas lsi hba storport"
Réinitialiser Driver Verifier en secours
verifier /reset
bcdedit /deletevalue {default} bootlog
Désactiver un pilote fautif hors ligne depuis WinRE
reg load HKLM\OFFSYS C:\Windows\System32\Config\SYSTEM
reg query HKLM\OFFSYS\ControlSet001\Services\<NomDuPilote>
reg add HKLM\OFFSYS\ControlSet001\Services\<NomDuPilote> /v Start /t REG_DWORD /d 4 /f
reg unload HKLM\OFFSYS
Points d’attention spécifiques au scénario
- Après extension RAID : l’augmentation de la file d’attente et des I/O parallèles peut exposer un bug dormant dans un pilote de filtre ou de contrôleur. D’où l’importance d’aligner versions firmware/pilote et de vérifier les files d’attente storport.
- Volume de dépôt Veeam : si l’indexation ou l’antivirus inspectent massivement le dépôt, envisager des exclusions adaptées (processus Veeam, répertoires de dépôt) afin de réduire les interceptions concurrentes de filtres.
- Services démarrage différé : le timing ~1 minute avant crash est typique d’un service Automatic (Delayed Start) ou d’un agent tiers initialisé après SCM. Ciblez ces services en priorité lors de la bisection.
Prévention et bonnes pratiques
- Couples firmware/pilote validés : normalisez une matrice interne des versions supportées pour PERC/BIOS/OS.
- Fenêtre de maintenance contrôlée : après ajout de disques/extension VD, planifiez une période de surveillance accrue (logs, alertes iDRAC).
- Politique de pilotes : évitez les mises à jour isolées. Mettez à niveau par ensembles cohérents (chipset + stockage + filtres).
- Backups de configuration : exportez la configuration Veeam avant tout changement potentiellement disruptif.
- Exclusions AV/EDR : appliquez des exclusions pour les binaires, répertoires et processus Veeam afin de limiter les conflits de filtres.
- Observabilité : surveillez événements 129/153/55 et les compteurs \PhysicalDisk\Avg. Disk sec/Read/Write pour détecter précocement des anomalies.
Compléments utiles
- Journal de démarrage :
bcdedit /set {default} bootlog Yespour générerntbtlog.txtet comparer la liste de pilotes chargés entre Safe Mode et normal. - Boucles de crash : s’il est impossible d’accéder au bureau, utilisez Safe Mode, désactivez Driver Verifier, puis Roll Back Driver dans le Gestionnaire de périphériques.
- Symboles WinDbg : paramétrez un cache local pour accélérer vos analyses (
C:\symcache). - Documentation Microsoft : la documentation du bug check 0x7E détaille d’autres causes (PnP, interruptions) et fournit des pistes avancées.
En résumé
Un 0x0000007E sur Windows Server 2019 consécutif à l’extension d’un RAID sur un R740xd pointe le plus souvent vers un pilote tiers (stockage ou minifiltre) chargé uniquement en démarrage normal. Enchaînez : analyse des minidumps → comparaison Safe Mode/normal → mise à jour ou rollback des pilotes de stockage et filtres → vérifications disque/RAID et mémoire. Avec une approche méthodique (bisection des services, Driver Verifier ciblé, appairage firmware/pilote), vous rétablirez un démarrage fiable tout en sécurisant les données de sauvegarde.