MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Windows Server 2022 : corriger le BSOD 0x139 (KERNEL_SECURITY_CHECK_FAILURE) – Guide complet et actions terrain

Windows Server 2022 : corriger le BSOD 0x139 (KERNEL_SECURITY_CHECK_FAILURE) – Guide complet et actions terrain

Windows Server

Votre serveur Windows Server 2022 redémarre avec un BSOD BugCheck 0x00000139 (KERNEL_SECURITY_CHECK_FAILURE) et le fichier server list.xml se retrouve vide ? Voici une procédure terrain, pas à pas, pour diagnostiquer, corriger et prévenir la récidive.

Sommaire

Vue d’ensemble du problème

Contexte typique : après un renouvellement quasi complet du matériel et une réinstallation « propre » de Windows Server 2022, la machine reste stable près de deux mois, puis recommence à s’arrêter brutalement sur un Blue Screen of Death avec le code 0x139. Au redémarrage, un message du gestionnaire Windows indique qu’il « n’arrive pas à lire le fichier server list.xml », lequel apparaît vidé (taille 0 octet ou contenu tronqué).

Ce tableau oriente vers une corruption mémoire ou noyau (souvent côté pilote), éventuellement aggravée par un arrêt brutal pendant l’écriture du fichier XML. Le correctif exige une approche méthodique couvrant matériel, pilotes, système et services tiers.

Comprendre le BugCheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE)

Le bugcheck 0x139 signale que le noyau a détecté une violation d’intégrité interne (par exemple, structures de liste corrompues, dépassement de tampon de pool, altération de cookies de pile, etc.). Dans la pratique, la cause n’est pas « Windows lui‑même », mais un pilote en mode noyau, un module matériel instable (RAM, stockage, alimentation), voire un logiciel de filtrage agressif (antivirus, sauvegarde, DLP, EDR) qui manipule les E/S à un niveau bas.

Dans WinDbg, l’analyse !analyze -v affiche le « Probably caused by » et un jeu de paramètres. Le premier paramètre (Parameter1) catégorise la corruption détectée. Vous verrez souvent des mentions du type LIST_ENTRY corruption ou pool overrun. Couplé à la pile d’appels (kv), cela permet d’identifier le pilote fautif.

Symptômes et indices complémentaires

  • BSOD aléatoires, parfois sous charge E/S (sauvegarde, antivirus, rebuild RAID, snapshot).
  • Événements systèmes voisins du crash : WHEA‑Logger (erreurs matérielles), Disk/StorPort/NVMe, NTFS, volsnap.
  • Fichier server list.xml vidé au redémarrage : signe d’une écriture interrompue ou d’un handle non flushé avant l’arrêt brutal.

Causes probables

CatégorieMécanisme plausibleComment le valider
MatérielComposant défectueux (RAM, contrôleur disque, carte mère, câbles)• Outils diagnostics constructeur
• Journal d’événements → « WHEA‑Logger »
PilotesPilote obsolète ou incompatible corrompant des structures noyau• Driver Verifier (mode vérification)
• Vérifier versions/compatibilité HCL
SystèmeFichiers système ou image Windows endommagés• sfc /scannow, puis DISM /online /cleanup-image /restorehealth
Logiciels/ServicesConflit entre services, filtre antivirus, sauvegarde, etc.• Désactiver/retirer modules tiers récents
• Mode minimal « services.msc »
MémoireBarrettes ou timings instables• Windows Memory Diagnostic (ou MemTest86)
MalwareCode malveillant modifiant le noyau ou les XML• Analyse antivirus hors‑ligne / EDR
StockageSecteurs défectueux détruisant le XML après crash• chkdsk /scan + SMART, maj firmware SSD/HDD

Plan d’action conseillé (pas à pas)

  1. Sauvegarder immédiatement le contenu critique et les journaux avant toute manipulation. Commande PowerShell (collecte d’urgence) $stamp = Get-Date -Format 'yyyyMMdd-HHmmss' $dest = "C:\Temp\BSOD-0x139-$stamp" New-Item -ItemType Directory -Force -Path $dest | Out-Null Copy-Item -Path "C:\Windows\MEMORY.DMP" -Destination $dest -ErrorAction SilentlyContinue Copy-Item -Path "C:\Windows\Minidump\*" -Destination "$dest\Minidump" -Recurse -ErrorAction SilentlyContinue wevtutil epl System "$dest\System.evtx" wevtutil epl Application "$dest\Application.evtx" Get-ComputerInfo | Out-File "$dest\ComputerInfo.txt" -Width 300 driverquery /v /fo csv > "$dest\Drivers.csv" Get-Process | Sort-Object CPU -Descending | Select-Object -First 50 | Format-Table -AutoSize | Out-String | Set-Content "$dest\TopCPU.txt" Get-Item "C:\Path\To\server list.xml" -ErrorAction SilentlyContinue | Format-List * | Out-String | Set-Content "$dest\ServerListXml.txt"
  2. Configurer et analyser le vidage mémoire (MEMORY.DMP) dans WinDbg.
    • Vérifiez l’option Kernel memory dump (ou Automatic memory dump) et le chemin du dump.
    • Dans WinDbg : !analyze -v .symfix .reload kv !thread !process 0 1 lmvm <NomDuPiloteSuspect>
    • Interprétez Parameter1 (type de corruption) et la pile noyau : si la pile montre un filtre disque, réseau ou antivirus juste avant ntoskrnl, commencez par ce pilote.
  3. Activer Driver Verifier sur les pilotes non‑Microsoft (hors stockage critique) pendant 24 h or charge ciblée. Configuration prudente de Driver Verifier
    • Lancez verifier.exe → « Créer des paramètres standards » → « Sélectionner les pilotes à partir d’une liste » → cochez uniquement les pilotes tiers liés aux E/S (réseau, sauvegarde, antivirus, cryptage, filtrage).
    • Évitez de valider les pilotes de stockage essentiels sur un serveur de production pour limiter le risque d’indisponibilité.
    • Si boucle de BSOD : démarrez en mode sans échec puis désactivez : verifier /reset
    • Le premier pilote à tomber sous Driver Verifier est souvent le vrai fautif.
  4. Mettre à jour l’empilement matériel/logiciel bas niveau : BIOS/UEFI, microcodes CPU, contrôleur RAID/HBA, firmware SSD/NVMe, pilotes réseau (y compris fonctionnalités avancées), pilote GPU (si présent).
    • Sur carte mère : désactivez toute forme d’OC/XMP agressif ; chargez les paramètres Optimized Defaults.
    • Contrôlez l’édition/ build de Windows Server 2022 et l’historique des Quality Updates. Si les arrêts ont commencé juste après un Patch Tuesday, testez la désinstallation de la dernière cumulative (à n’envisager que si la machine est instable en production).
  5. Tester la mémoire hors OS.
    • Windows Memory Diagnostic en mode étendu (plusieurs passes) ou MemTest86 autonome.
    • Surserveurs ECC : vérifiez la présence d’erreurs corrigées (elles annoncent parfois une panne imminente).
    • Remplacez la barrette dès la première erreur. Mélanger des marques/timings différents augmente le risque d’instabilité.
  6. Contrôler l’alimentation.
    • Vérifiez l’UPS, l’ondulation et la stabilité du rail 12 V sous charge.
    • Les Kernel‑Power 41 peuvent accompagner des arrêts brutaux ; ils ne prouvent pas la cause mais justifient une enquête électrique.
  7. Réparer l’image système, puis redémarrer. sfc /scannow DISM /online /cleanup-image /restorehealth Contrôlez le journal CBS.log. Si server list.xml est recréé correctement après redémarrage, poursuivez la surveillance.
  8. Isoler les rôles et services tiers.
    • Désactivez temporairement l’antivirus/EDR tiers, les logiciels de sauvegarde (services & pilotes de filtrage), DLP, HSM, chiffrement à la volée.
    • Redémarrez en configuration de démarrage minimale via services.msc (désactivation ciblée des services non‑Microsoft) et observez.
    • Réactivez un à un pour identifier le conflit.
  9. Corréler dans l’Observateur d’événements (Système & Application) l’heure du BSOD avec d’autres erreurs : Disk, Ntfs, Volsnap, StorPort, NVMe, WHEA‑Logger. Requêtes PowerShell utiles # Dernières erreurs critiques système Get-WinEvent -LogName System -MaxEvents 500 | Where-Object {$_.LevelDisplayName -in 'Critical','Error'} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message # Filtre WHEA-Logger Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Level=2} -MaxEvents 50 | Select-Object TimeCreated, Id, Message # Erreurs Disk/Storport/NVMe proches d’un crash Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object {$*.ProviderName -match 'Disk|storport|stornvme|nvme' -and $*.LevelDisplayName -in 'Error','Warning'} | Select-Object TimeCreated, ProviderName, Id, Message
  10. Mettre en place une surveillance proactive.
    • Activez un Data Collector Set (perfmon) pour suivre : Memory\Pages Input/sec, Memory\Page Reads/sec, PhysicalDisk\Avg. Disk sec/Transfer, LogicalDisk\% Free Space, Processor(_Total)\% Interrupt Time, Network Interface\Packets Outbound Errors.
    • Surveillez WHEA (erreurs corrigées/non corrigées) et SMART (voir plus bas).
    • Automatisez la sauvegarde de server list.xml (exemple de script ci‑dessous).

Pourquoi le fichier server list.xml se vide ?

Un plantage au milieu d’un cycle « écrire/renommer » peut laisser un fichier temporaire incomplet ou un fichier final de taille nulle. Autres causes : filtre de pilote interceptant les E/S, secteurs défectueux, application qui n’effectue pas de flush avant fermeture, ou conflit de verrouillage.

  • Atténuation immédiate : placer le XML sur un volume distinct (ou volume rapide/fiable), activer les Shadow Copies, versionner le fichier, ajouter un write‑ahead (écrire vers .tmp puis rename atomique).
  • Contrôler le stockage : chkdsk /scan, vérifier SMART/firmware SSD, câbles et ports. Sur contrôleur RAID, vérifier l’état du cache et de la batterie de cache.

Procédure express (si vous manquez de temps)

  1. Mettre à jour BIOS/firmwares + pilotes réseau/stockage.
  2. Lancer sfc + DISM.
  3. Désactiver temporairement antivirus/agents de sauvegarde.
  4. Exécuter Driver Verifier (pilotes tiers uniquement) jusqu’au prochain crash et noter le pilote incriminé.
  5. Tester la RAM hors OS (1+ passes étendues) et remplacer au besoin.

Notes pour environnements virtualisés

  • Hyper‑V / VMware / Proxmox : mettez à jour les Integration Services / VMware Tools / outils invités. Corrigez la Virtual Hardware Version si obsolète.
  • Vérifiez la chaîne stockage : contrôleur virtuel (PVSCI/LSI), filesystems hôtes, latence, snapshots fréquents.
  • Évitez la sous‑allocation de RAM et le ballooning agressif.

Scripts utiles

1) Sauvegarde/auto‑restauration du server list.xml au démarrage

Ce script PowerShell sauvegarde le XML avec un horodatage, détecte un fichier vide et restaure la dernière version saine. Ajoutez‑le en tâche planifiée « Au démarrage ».

$Path = "C:\Path\To\server list.xml"
$Bak  = "C:\Path\To\Backups"
New-Item -ItemType Directory -Force -Path $Bak | Out-Null

function Get-LastGoodBackup {
Get-ChildItem $Bak -Filter "server list.xml.*.bak" |
Where-Object {$_.Length -gt 0} |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1
}

# 1) Sauvegarde préventive

if (Test-Path $Path) {
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
Copy-Item $Path (Join-Path $Bak "server list.xml.$stamp.bak") -ErrorAction SilentlyContinue
}

# 2) Détection & restauration si vide ou inexistant

$needRestore = $true
if (Test-Path $Path) {
if ((Get-Item $Path).Length -gt 0) { $needRestore = $false }
}
if ($needRestore) {
$good = Get-LastGoodBackup
if ($null -ne $good) {
Copy-Item $good.FullName $Path -Force
}
}

Tâche planifiée (exemple)

$script = "C:\Admin\Fix-ServerListXml.ps1"
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$script`""
$trigger= New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -TaskName "Protect-ServerListXml" -Action $action -Trigger $trigger -RunLevel Highest -Description "Backup/Restore of server list.xml on startup"

2) Vérification rapide stockage & SMART (Windows Server 2022)

Get-PhysicalDisk | Get-StorageReliabilityCounter |
  Select-Object FriendlyName, Temperature, Wear, ReadErrorsTotal, WriteErrorsTotal, TotalUnrecoverableErrors |
  Format-Table -AutoSize

3) Collecte ciblée des pilotes tiers

Get-WmiObject Win32_PnPSignedDriver |
  Where-Object {$_.DriverProviderName -and $_.DriverProviderName -notmatch 'Microsoft'} |
  Select-Object DeviceName, DriverVersion, DriverProviderName, InfName, DriverDate |
  Sort-Object DriverDate -Descending |
  Export-Csv "C:\Temp\ThirdPartyDrivers.csv" -NoTypeInformation -Encoding UTF8

Check‑list de validation (« Definition of Done »)

  • Aucun BSOD 0x139 sous charge I/O et CPU pendant au moins un cycle d’exploitation significatif (ex. 7 jours).
  • Absence d’événements Error/Critical récurrents côté Disk/StorPort/NVMe/NTFS/WHEA‑Logger.
  • Driver Verifier ne déclenche plus de crash sur les pilotes tiers ciblés.
  • server list.xml reste cohérent après redémarrages et opérations de maintenance (sauvegardes, snapshots).

Arbre de décision rapide

Si…Alors…Pourquoi
Les BSOD surviennent lors de sauvegardes/scan AVDésactivez temporairement les filtres, mettez à jour/ remplacez le pilote fautifConflits d’E/S noyau fréquents avec filtres
Événements WHEA avant le BSODDiagnostiquer matériel (RAM/CPU/carte mère/PSU)Erreur matérielle signalée par le CPU/PCIe
WinDbg pointe un pilote tiersMettre à jour/retirer le pilote et re‑testerCause la plus courante du 0x139
Seul le fichier XML est affectéIsoler le répertoire/volume, activer versioningProtection contre écriture interrompue
RAM testée défaillanteRemplacer la/les barrette(s), retesterLa corruption mémoire entraîne des 0x139

Bonnes pratiques pour fiabiliser durablement

  • Mises à jour planifiées : pilotes et firmwares validés en pré‑production, puis déploiement par vagues.
  • Politiques de redémarrage : éviter les reboots non maîtrisés pendant des écritures applicatives.
  • Surveillance : alertes sur WHEA, Disk/NTFS, %Idle Time disque, erreurs réseau, taille du fichier XML.
  • Journaux centralisés : export automatique EVTX et dumps vers un partage robuste.
  • VBS/HVCI : si activés, vérifier la compatibilité des pilotes tiers (sinon erreurs noyau possibles).

Informations complémentaires utiles

  • Le code 0x139 est fréquent lorsque Pool Overrun ou List Entry Corrupt affectent le noyau ; un pilote en mode noyau est généralement en cause.
  • Sur serveur virtualisé, assurez‑vous que les outils d’intégration/hyperviseur sont à jour (VMware Tools, Hyper‑V Integration Services).
  • Si la machine est critique, envisagez de désinstaller les dernières mises à jour cumulatives de Windows si le problème est apparu juste après un Patch Tuesday.
  • Pour éviter la corruption du fichier XML, placez‑le sur un volume distinct ou versionné (Shadow Copies) afin d’avoir un rollback rapide.

Annexe A — commandes et gestes techniques

  • Réparer l’image : sfc /scannow DISM /online /cleanup-image /restorehealth
  • Vérifier disque : chkdsk C: /scan
  • Activer un journal PerfMon rapide : logman create counter BSOD0x139 -c "Memory\Pages Input/sec" "PhysicalDisk\Avg. Disk sec/Transfer" "Processor(_Total)\% Interrupt Time" -si 00:00:15 -o C:\Perf\BSOD0x139.blg -f bin -v mmddhhmm -max 500 -cnf 01:00:00 logman start BSOD0x139
  • Driver Verifier (CLI) : verifier /standard /driver <liste_de_pilotes_non_microsoft> verifier /query verifier /reset
  • WinDbg — séquence de base : !analyze -v .symfix .reload kv !poolused 2 !thread !locks lm t n

Annexe B — événements à surveiller

SourceIDs fréquentsInterprétationAction
WHEA‑Logger17, 18, 19, 20Erreurs matérielles CPU/PCIe (corrigées ou non)Diagnostic RAM/CPU/carte mère/PCIe
Disk / StorPort / stornvme7, 51, 129, 153Temps d’accès, réinitialisation de port/cheminMettre à jour pilote/firmware, vérifier câbles
Ntfs55, 57, 98Corruption de système de fichiers / journalCHKDSK, vérifier stockage, restaurer depuis sauvegarde
volsnap25, 27Snapshot interrompu/retardéVérifier charge I/O et espace libre
Kernel‑Power41Arrêt brutal précédentContrôler PSU/UPS et pilotes basse couche

Étude de cas (résolution type)

Situation : BSOD 0x139 irréguliers sur un hôte de fichiers, accompagnés d’événements Disk 153 et vidé du server list.xml après redémarrage. Action : mise à jour du firmware NVMe et du pilote de filtrage antivirus, Driver Verifier ciblant le pilote de sauvegarde, désactivation d’une optimisation réseau offload sur la carte. Résultat : le pilote antivirus a été remplacé, le firmware NVMe corrigé, plus aucun BSOD en 14 jours et XML stable avec sauvegardes quotidiennes.

En résumé

Le KERNEL_SECURITY_CHECK_FAILURE (0x139) sur Windows Server 2022 révèle une corruption détectée par le noyau. En appliquant la démarche ci‑dessus — diagnostic matériel, vérification des pilotes, réparation système, puis élimination des conflits logiciels — vous identifierez la cause avec un haut taux de succès et rétablirez une stabilité durable, tout en protégeant le fichier server list.xml contre la corruption.

Windows Server
troubleshooting BSOD Windows Server 2022 WinDbg Driver Verifier 0x139
Sommaire