Votre serveur Windows Server 2019 redémarre inopinément avec un Bugcheck et un code 0xC0000005 ? Suivez ce guide pas‑à‑pas pour isoler la cause racine (pilote, mise à jour, RAM, disque, firmware) et stabiliser durablement la plateforme.
Problématique exposée
Un hôte Windows Server 2019 redémarre de façon imprévisible tous les quelques jours. Dans le Journal des événements > Système apparaissent des entrées typiques :
- Kernel-Power (ID 41) — le système a redémarré sans s’arrêter correctement.
- BugCheck (ID 1001) — « The computer has rebooted from a bugcheck. » avec des paramètres comme
0x0000007E (0xC0000005, ...)ou0x0000003B (0xC0000005, ...).
Les pilotes Fujitsu ont déjà été mis à jour, mais les redémarrages persistent. Le paramètre 0xC0000005 indique une violation d’accès mémoire (accès à une adresse non valide) survenue en mode noyau, souvent déclenchée par un pilote, une corruption mémoire ou un firmware inadapté.
Comprendre le code 0xC0000005 et ses contextes
Le code 0xC0000005 n’est pas, à lui seul, un bugcheck : c’est un code d’exception qui apparaît en paramètre de nombreux BSOD (Blue Screen of Death) côté noyau, par exemple :
| Bugcheck (exemples) | Signification fréquente | Quand 0xC0000005 apparaît |
|---|---|---|
0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) | Exception non gérée dans un thread noyau | Le premier paramètre contient souvent 0xC0000005 (violation d’accès) |
0x0000003B (SYSTEM_SERVICE_EXCEPTION) | Exception lors d’un appel de service système | Souvent une violation d’accès dans un pilote ou un filtre |
0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA) | Référence mémoire invalide en zone non paginée | Peut résulter d’un pointeur corrompu ou de RAM défectueuse |
La valeur 0xC0000005 traduit donc un déréférencement invalide (lecture/écriture/exécution), typiquement lié à un driver fautif, une corruption de pile, un DMA mal géré, ou une instabilité matérielle (RAM, contrôleur disque, VRM, etc.).
Analyse synthétique des causes probables
Les familles de causes les plus communes se répartissent comme suit.
| Domaine | Causes fréquentes |
|---|---|
| Logiciel | Pilote corrompu ou incompatible, mise à jour Windows défectueuse, fichier système endommagé, filtres minifilter (antivirus/EDR/backup) défaillants |
| Matériel | Barrette RAM défectueuse, erreurs ECC récurrentes, secteur disque instable, contrôleur RAID/HBA capricieux, surchauffe, alimentation irrégulière |
| Paramétrage | BIOS/UEFI inadapté (XMP, overclock, C‑states agressifs), micro‑code processeur obsolète, options d’économie d’énergie trop poussées |
Plan d’action priorisé (résolution et stabilisation)
Appliquer tous les correctifs Windows et firmware
- Windows Update (y compris mises à jour facultatives de pilotes et de micro‑code) → rechercher et installer tous les correctifs de sécurité et de fiabilité.
- BIOS/UEFI, BMC/iRMC, micro‑code CPU, RAID/HBA, contrôleur de disque/NVMe : mettre ensemble firmware et pilote à un couple validé par le constructeur.
- En environnement Fujitsu, vérifier aussi le Support Package (System Inspection) et l’état de la batterie du cache RAID (BBU/Capacitor Pack).
Vérifier l’intégrité logicielle
Exécuter d’abord les contrôles système pour éliminer une base instable.
| Action | Commande | Interprétation |
|---|---|---|
| Vérification fichiers système | sfc /scannow | Répare les fichiers système altérés (journal dans %windir%\Logs\CBS\CBS.log) |
| Réparation image de Windows | DISM /Online /Cleanup-Image /RestoreHealth | Corrige le magasin de composants (%windir%\Logs\DISM\dism.log) |
| Inventaire des pilotes | driverquery /v /fo table | Repérer un pilote récent/tiers susceptible d’être fautif |
| Liste des filtres systèmes | fltmc | Identifier antivirus/EDR/backup (minifilters) pouvant intercepter E/S |
Si les plantages ont commencé après une mise à jour spécifique (pilote, cumulative update), désinstaller ou régresser ce composant pour confirmer la corrélation.
Activer et fiabiliser la capture de dumps
Sans un dump noyau fiable, l’analyse est aveugle. Assurez‑vous de :
- Configurer « Automatic memory dump » (ou Kernel memory dump) dans Propriétés Système > Démarrage et récupération.
- Conserver un fichier d’échange géré par le système sur la partition système.
- Laisser au moins 20 % d’espace libre sur la partition système pour accueillir
MEMORY.DMPet les minidumps (C:\Windows\Minidump). - Vérifier la clé
HKLM\System\CurrentControlSet\Control\CrashControl(valeurs :CrashDumpEnabled,LogEvent,AutoReboot).
Pour éviter de manquer l’écran bleu lors d’un diagnostic, décochez temporairement « Redémarrer automatiquement » dans Démarrage et récupération (à planifier en fenêtre de maintenance).
Analyser les fichiers dump avec WinDbg
Ouvrez C:\Windows\MEMORY.DMP ou un minidump dans WinDbg (x64) et lancez :
.symfix
.reload
!analyze -v
Points clés à examiner :
- Probably caused by / MODULE_NAME / IMAGE_NAME : pilote suspect.
- STACK_TEXT et FAULTING_IP : contexte du crash (lecture/écriture/exécution).
- Commandes utiles :
kv(pile),!thread,!process,lmvm <driver>(version/timestamp),!verifier 3(si Driver Verifier actif),!sysinfo smbios,!vm.
Si l’analyse pointe un filtre E/S (antivirus, sauvegarde, chiffrement), testez sa désactivation contrôlée ou le passage à une version validée par l’éditeur.
Tester le matériel
- RAM : au moins deux passes avec Windows Memory Diagnostic (mode étendu) ou MemTest86. Sur plateforme ECC, contrôler le compteur d’erreurs correctibles dans l’iRMC/IPMI et les journaux WHEA.
- Disques :
chkdsk /scanà chaud puis utilitaire constructeur. Sur RAID, vérifier l’état de tous les membres, la batterie/capacité du cache et la queue depth HBA. - Thermique/énergie : surveiller températures, vitesses de ventilateurs et tensions via BMC/iRMC. Un VRM instable peut mimer des fautes mémoire.
Réviser la configuration BIOS/UEFI
- Désactiver tout overclock mémoire/CPU et les profils XMP non validés serveur.
- Revenir au profil d’alimentation « High Performance » côté OS et limiter les C‑states agressifs si la charge est sensible.
- Mettre à jour le micro‑code CPU et réinitialiser les options expérimentales (ASPM, PCIe power saving) si non nécessaires.
Collecter des données supplémentaires si les redémarrages persistent
- Journaux de débogage stockage/réseau (Storport, iSCSI, SMB Direct) et compteurs Perfmon corrélés à la charge.
- Driver Verifier (paramètres standard) :
verifier /standard /all verifier /querysettingsAttention : Driver Verifier peut provoquer des BSOD plus rapidement pour révéler le pilote fautif. Planifier une fenêtre de maintenance et garder un accès hors bande (iRMC/iKVM).
Escalade au support constructeur
Préparer un dossier complet pour accélérer le diagnostic :
- Numéro de série châssis, versions BIOS/BMC/RAID/HBA/NIC/NVMe.
- Dernier
MEMORY.DMPanalysé avec extraits!analyze -v,!thread,!process,lmvdu pilote suspect. - Rapport d’autodiagnostic matériel (iRMC/IPMI) et statistiques ECC/WHEA.
Procédure détaillée pas‑à‑pas (check‑list opérable)
- Stabiliser le contexte
- Activer Automatic memory dump et vérifier la taille du pagefile (gérée par le système).
- Libérer ≥ 20 % de la partition système.
- Désactiver le redémarrage automatique pendant l’enquête.
- Assainir l’OS
- Appliquer Windows Update et redémarrer.
- Lancer
sfc /scannowpuisDISM /Online /Cleanup-Image /RestoreHealth.
- Revenir sur les derniers changements
- Identifier les logiciels/pilotes installés avant l’apparition des BSOD (Reliability Monitor, journal MsiInstaller/Application).
- Désinstaller/régresser ces composants (conserver les versions et dates).
- Mettre à niveau firmware/pilotes critiques
- BIOS/UEFI, BMC/iRMC, RAID/HBA, NIC, NVMe, contrôleurs de stockage.
- Maintenir des couples pilotes/firmware validés par l’OEM.
- Analyser les dumps
- Ouvrir
MEMORY.DMPdans WinDbg, exécuter!analyze -v. - Si un pilote tiers ressort, créer un change contrôlé pour le mettre à jour/retirer.
- Ouvrir
- Tester matériel
- RAM : 2 passes minimum. Remplacer la barrette incriminée; sur ECC, permuter les barrettes pour confirmer la localisation du slot.
- Disques : diagnostic constructeur, vérifier secteurs réalloués/pendants, latences.
- RAID/HBA : état du cache, latences, erreurs 129/153 dans le journal Système.
- Durcir la configuration
- Profil d’alimentation « Performances élevées », désactiver les tweaks non validés.
- Activer Memory Scrubbing en BIOS si disponible.
- Driver Verifier (si besoin)
- Activer Standard settings sur les pilotes non Microsoft ou ciblés.
- Collecter le BSOD induit et réanalyser. Désactiver ensuite avec
verifier /reset.
Signatures courantes et remèdes rapides
Stockage : timeouts et filtres
Indicateurs : événements Système ID 129/153 (Reset/Timeout), pic de Average Disk sec/Transfer, traces de filtres de sauvegarde/chiffrement.
- Mettre à jour pilote Storport/HBA et firmware RAID/NVMe.
- Désactiver temporairement les filtres non essentiels (backup, DLP) pour valider l’hypothèse.
- Vérifier la cohérence RAID, la santé de la BBU et le câblage (SAS/NVMe backplane).
Mémoire : erreurs ECC et 0x50/0x3B
Indicateurs : WHEA 18/19, compteur ECC qui grimpe, BSOD aléatoires sous charge.
- Test RAM étendu. Remplacer la/les barrettes indiquées par iRMC/IPMI.
- Mettre à jour BIOS/micro‑code, désactiver XMP, équilibrer les canaux (population guidée).
Pilote réseau/EDR : 0x7E avec 0xC0000005
Indicateurs : Probably caused by: <driver.sys> réseau ou sécurité, pile montrant ndis!... / fltmgr!....
- Mettre à jour/désinstaller l’agent incriminé, valider avec Driver Verifier ciblé.
- Adapter les exclusions antivirus (répertoires système, VHDX, dossiers de rôle serveur).
Outils et commandes utiles (mémo)
| Objectif | Commande | Notes |
|---|---|---|
| Exporter récents BugCheck/Kernel‑Power | Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1001} | Select TimeCreated,Id,Message | PowerShell : vue chronologique des plantages |
| Lister pilotes non Microsoft | Get-CimInstance Win32_PnPSignedDriver | Where-Object {$_.DriverProviderName -ne 'Microsoft'} | Repérer versions/timestamps suspects |
| Lister minifilters | fltmc | Ordre de chargement et altitude des filtres |
| Vérifier pagefile | wmic pagefile list /format:list | Préreq pour Kernel/Automatic dump |
| Forcer Driver Verifier (standard) | verifier /standard /all | À désactiver après collecte : verifier /reset |
Pour les environnements virtualisés et Hyper‑V
- Hôte Hyper‑V : vérifier pilotes NIC (vSwitch), stockage (vhdmp, vioscsi), firmware et plan d’alimentation. Un défaut hôte se répercute sur toutes les VM.
- VM invitée : si la VM seule plante avec
0xC0000005, examiner ses pilotes intégration et filtres (sauvegarde/antivirus intra‑VM). - Disques virtuels (VHDX/RAID) : vérifier la cohérence et la redondance. Une corruption VHDX ou un RAID dégradé peut déclencher des exceptions noyau.
Bonnes pratiques de continuité et de suivi
- Plan de continuité : tant que la cause n’est pas éradiquée, planifier des sauvegardes plus fréquentes et tester la restauration.
- Surveillance centralisée : collecter journaux (Windows Event, WHEA), compteurs PerfMon et métriques BMC dans un outil (Log Analytics, Zabbix, etc.) pour corrélation charge/alerte/BSOD.
- Hygiène de mise à jour : instaurer des rings de déploiement (pré‑prod → prod) avec points de restauration/snapshots pour rollback rapide.
Étude de cas condensée : méthode sur un incident réel
- Contexte : redémarrage 1 à 2 fois/semaine, Event 1001 avec
0x7E (0xC0000005,...). - Actions :
- Activation Automatic dump et collecte du premier
MEMORY.DMP. - Analyse WinDbg : Probably caused by un pilote de sauvegarde (minifilter) ancien.
- Mise à jour du pilote et du composant serveur de sauvegarde.
- Driver Verifier ciblé pour validation → aucun nouveau BSOD en 72 h.
- Activation Automatic dump et collecte du premier
- Résultat : stabilité retrouvée > 30 jours, mean time between failures remonté.
FAQ & points d’attention
Faut‑il un dump complet (Full memory dump) ?
Le Kernel/Automatic memory dump suffit dans la majorité des cas et consomme nettement moins d’espace. N’activez le Full que si le support l’exige.
Le code 0xC0000005 implique‑t‑il forcément la RAM ?
Non. Il signale une violation d’accès, souvent causée par un driver. D’où l’importance de l’analyse WinDbg et des tests RAM pour trancher.
Driver Verifier est‑il sans risque ?
Il est normal qu’il déclenche plus rapidement un BSOD pour exposer le pilote fautif. Utiliser en fenêtre de maintenance et prévoir un accès hors bande au serveur.
Modèle de rapport d’escalade (copier‑coller)
Objet : Escalade BSOD Windows Server 2019 – Bugcheck avec 0xC0000005
Contexte :
* Fréquence : \
* Rôles du serveur : \
* Derniers changements : \
Environnement :
* Modèle châssis/N° série : <...>
* BIOS/BMC/RAID/NIC/NVMe versions : <...>
* RAM : \
Symptômes :
* Event 41/1001 avec paramètres : \
* WHEA : \
Analyse :
* Extraits WinDbg : !analyze -v (Probably caused by, MODULE\_NAME)
* Pile fautive : \
* Pilote suspect : \
Actions réalisées :
* SFC/DISM, Windows Update, mises à jour firmware/pilotes
* Tests RAM/Disques
* Driver Verifier (oui/non)
Pièces jointes :
* MEMORY.DMP (ou minidumps), logs iRMC/IPMI, rapports diagnostics Conclusion
En combinant correctifs (OS/firmware), vérifications d’intégrité, analyse de dumps avec WinDbg, tests matériels et, si nécessaire, Driver Verifier et escalade constructeur, vous disposez d’un cadre complet pour identifier la cause racine d’un Bugcheck comportant 0xC0000005 et stabiliser durablement votre Windows Server 2019. N’oubliez pas de renforcer la surveillance, la gestion des changements et la continuité pour prévenir la régression.
Récapitulatif actionnable
| Étape | But | Livrable |
|---|---|---|
| Mettre à jour OS/firmware | Éliminer bugs connus | Inventaire versions avant/après |
| SFC + DISM | Base OS saine | Logs CBS/DISM |
| Configurer dumps | Preuve post‑mortem | MEMORY.DMP / minidumps |
| WinDbg | Identifier pilote/module | Extraits !analyze -v |
| Tests RAM/Disques | Exclure hardware | Rapports diagnostics |
| Driver Verifier | Stress des pilotes | BSOD ciblé (ou absence) |
| Escalade | Support éditeur/OEM | Dossier complet |
Annexe : réglages recommandés de capture de crash
- CrashDumpEnabled : 7 (Automatic) ou 2 (Kernel).
- LogEvent : 1 (journaliser l’événement).
- SendAlert : 0 (ou selon vos outils de supervision).
- AutoReboot : 0 pendant l’enquête, 1 ensuite.
Dossier utile : C:\Windows\Minidump (minidumps) et C:\Windows\MEMORY.DMP (dump noyau).
Annexe : scripts de collecte express
# 1) Événements critiques récents
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1001; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message
# 2) Pilotes tiers (nom, version, date)
Get-CimInstance Win32\_PnPSignedDriver |
Where-Object {$\_.DriverProviderName -ne 'Microsoft'} |
Select-Object DeviceName, DriverProviderName, DriverVersion, DriverDate | Sort-Object DriverDate -Descending
# 3) Filtres minifilter
fltmc
# 4) Liste de paquets installés récemment (7 jours)
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Message Résumé exécutif
Les redémarrages intempestifs avec Bugcheck et paramètre 0xC0000005 sur Windows Server 2019 sont le plus souvent corrélés à un pilote noyau ou à une instabilité matérielle. La stratégie gagnante : mettre à jour l’ensemble OS/firmware, fiabiliser la capture de dumps, analyser sous WinDbg, valider par tests RAM/disques et Driver Verifier, puis verrouiller la configuration BIOS/UEFI. La surveillance et la collecte rigoureuse d’indicateurs (événements, WHEA, perf) réduisent le temps moyen de résolution et évitent la récidive.
Informations complémentaires utiles
- Plan de continuité : jusqu’à résolution définitive, planifier des sauvegardes fréquentes et tester la restauration.
- Disques virtuels (RAID/Hyper‑V) : vérifier la cohérence et la redondance ; une corruption au niveau VHDX/RAID peut aussi déclencher un
0xC0000005. - Suivi : mettre en place une surveillance centralisée (ex. Log Analytics, Zabbix) pour corréler les plantages avec la charge, la température ou une opération planifiée.