Windows Server 2022 Hyper‑V : résoudre le BSOD 0x23 FAT_FILE_SYSTEM (fastfat.sys, vmms.exe)

Votre hôte Windows Server 2022 dans un cluster Hyper‑V redémarre de façon imprévisible ? Un minidump indiquant bug‑check 0x23 — FAT_FILE_SYSTEM (pile : fastfat!FatDeleteVcb, processus : vmms.exe) pointe souvent vers un volume FAT/FAT32 défaillant. Voici le guide complet pour diagnostiquer et corriger.

Sommaire

Contexte et symptômes observés

Redémarrages spontanés sur un nœud Windows Server 2022 exécutant Hyper‑V au sein d’un cluster de bascule.
Minidump indiquant FAT_FILE_SYSTEM (code 0x23) avec la pile se terminant par fastfat!FatDeleteVcb.
Processus associé : vmms.exe (Service de gestion Hyper‑V).
Uptime d’environ 20 jours avant l’incident : problème latent, non corrélé immédiatement à une mise à jour.

Diagnostic technique : points clés

Indice clé	Interprétation
Module : fastfat.sys	Pilote du système de fichiers FAT/FAT32 ; toute corruption ou incohérence sur un volume de ce type peut provoquer le crash.
Processus : vmms.exe	Le service Hyper‑V accède à un support FAT (clé USB, carte SD, partition EFI, VHD/VHDX monté, etc.).
Paramètre 1 = 0x1C0345	Code d’erreur interne de FastFAT : structure de volume invalide (méta‑données FAT corrompues, secteurs défectueux, démontage brutal).
~20 jours d’uptime	Défaillance progressive (usure, firmware, fuite mémoire noyau) plutôt qu’un effet immédiat post‑patch.

Causes probables

Corruption ou défaut matériel sur un volume FAT/FAT32 : clé USB oubliée, carte SD, disque amovible, partition EFI.
Pilotes/firmware de stockage (SAS/SCSI/SAN/NVMe/RAID) obsolètes ou instables.
BIOS/UEFI et microcode non à jour.
Épuisement du non‑paged pool par un pilote tiers (antivirus, sauvegarde, filtre de chiffrement, HBA, etc.).

Comprendre le bug‑check 0x23 (FAT_FILE_SYSTEM)

Le code 0x23 est levé par fastfat.sys lorsque l’intégrité d’un volume FAT/FAT32 ne peut plus être garantie : FAT invalide, entrées de répertoire incohérentes, chaînes de clusters rompues, VCB/SCB corrompu, ou E/S irrécupérables. L’empreinte fastfat!FatDeleteVcb dans la pile suggère une tentative de démontage/fermeture d’un volume devenu incohérent (éjection inopinée, panne, reset contrôleur).

Paramètre	Signification pratique
P1	Code interne FastFAT (ici `0x1C0345`) indiquant une incohérence sévère.
P2–P4	Pointeurs/objets internes (VCB/IRP/DeviceObject). Utile en analyse WinDbg pour remonter au périphérique/chemin.

Plan d’action rapide (priorités)

Isoler le nœud : mettez le nœud en maintenance et drainez les rôles pour éviter un second incident pendant l’analyse.
Identifier tout volume FAT/FAT32 (y compris EFI) présent sur l’hôte et le vérifier (chkdsk hors‑ligne si nécessaire).
Débrancher/remplacer tout support amovible douteux. Ne laissez jamais VHD/VHDX ni checkpoints sur FAT/FAT32.
Mettre à jour pile de stockage (pilotes HBA/NVMe/RAID), firmware disques, BIOS/UEFI, correctifs Windows/Hyper‑V/Cluster.
Contrôler le non‑paged pool et activer Driver Verifier de manière ciblée si la piste pilote/fuite se confirme.

Pas à pas détaillé

1) Isoler le nœud de cluster en toute sécurité

Avant toute manipulation, évitez les interruptions de service :

# Mettre le nœud en maintenance et drainer les rôles
Suspend-ClusterNode -Drain

# Vérifier que toutes les VM/ressources ont migré

Get-ClusterGroup | Format-Table Name, OwnerNode, State

Une fois la maintenance terminée :

# Réintégrer le nœud
Resume-ClusterNode -Failback Immediate

2) Inventorier les volumes FAT/FAT32 (y compris la partition EFI)

Commencez par répertorier tous les volumes de type FAT sur l’hôte :

# Lister les volumes FAT/FAT32
Get-Volume | Where-Object {$_.FileSystem -match 'FAT'} |
  Select-Object DriveLetter, FileSystem, FileSystemLabel, HealthStatus, Path, SizeRemaining, Size

# Lister les disques amovibles présents

Get-PnpDevice -Class Disk -PresentOnly | Sort-Object FriendlyName | Format-Table -Auto

# Rechercher une partition EFI (GPT)

Get-Partition | Where-Object {$_.GptType -match 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b'} |
Format-Table DiskNumber, PartitionNumber, GptType

Si une partition EFI est détectée, assignez‑lui une lettre pour la vérifier puis retirez la lettre :

# Exemple : assigner S: à la partition EFI
$efi = Get-Partition | Where-Object {$_.GptType -match 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b'}
$efi | Set-Partition -NewDriveLetter S

# Vérifier et réparer

chkdsk S: /f

# (Optionnel) vérifier l’indicateur "dirty"

fsutil dirty query S:

# Retirer la lettre après vérification

$efi | Remove-PartitionAccessPath -AccessPath S:

Si la partition EFI est sévèrement endommagée, recréez les fichiers d’amorçage :

bcdboot C:\Windows /s S: /f UEFI

3) Vérifier/réparer chaque volume FAT/FAT32 détecté

Exécutez chkdsk avec réparation ; pour les supports amovibles, testez aussi en lecture/sectorielle :

chkdsk X: /f /r

/f corrige automatiquement les erreurs.
/r localise les secteurs défectueux et tente la récupération ; prévoyez un créneau (opération longue).
Si le volume est utilisé, chkdsk proposera de planifier au prochain redémarrage : acceptez.

4) Interdire la présence de VHD/VHDX et checkpoints sur FAT/FAT32

La plateforme Hyper‑V n’est pas conçue pour héberger des disques virtuels sur FAT/FAT32. Vérifiez l’emplacement de chaque VHD/VHDX :

$r = foreach ($vm in Get-VM) {
  foreach ($d in (Get-VMHardDiskDrive -VMName $vm.Name)) {
    $root = [System.IO.Path]::GetPathRoot($d.Path)
    $dl = $root.Substring(0,1)
    $vol = Get-Volume -DriveLetter $dl -ErrorAction SilentlyContinue
    [PSCustomObject]@{
      VM           = $vm.Name
      VHDX         = $d.Path
      DriveLetter  = $dl
      FileSystem   = $vol.FileSystem
      HealthStatus = $vol.HealthStatus
    }
  }
}
$r | Sort-Object VM | Format-Table -Auto
# Filtrer les cas à risque
$r | Where-Object {$_.FileSystem -match 'FAT'}

Si une VM stocke un VHD(X) sur un support FAT/FAT32, déplacez‑le immédiatement vers NTFS ou ReFS (CSV, SMB 3, ou stockage local NTFS/ReFS) puis recréez un checkpoint sain si nécessaire.

5) Mettre à jour la pile de stockage et le firmware

Contrôleurs/initiators : SAS/SATA/NVMe/HBA/SAN (storport/miniports), pilotes multipathing.
Firmware des disques (SSD/NVMe/HDD), et BIOS/UEFI de l’hôte.
Mises à jour cumulatives Windows Server 2022, Hyper‑V et Failover Cluster.

Inventaire rapide des versions de pilotes de stockage :

Get-PnpDevice -Class SCSIAdapter, Storage, HDC -PresentOnly |
  ForEach-Object {
    [PSCustomObject]@{
      Name    = $_.FriendlyName
      Driver  = (Get-PnpDeviceProperty -InstanceId $_.InstanceId -KeyName 'DEVPKEY_Device_DriverVersion' -ErrorAction SilentlyContinue).Data
      Provider= (Get-PnpDeviceProperty -InstanceId $_.InstanceId -KeyName 'DEVPKEY_Device_DriverProvider' -ErrorAction SilentlyContinue).Data
    }
  } | Sort-Object Name | Format-Table -Auto

6) Surveiller l’épuisement du non‑paged pool

Un pool non paginé saturé par un pilote défectueux peut déclencher divers bug‑checks, dont 0x23. Surveillez :

PerfMon : Memory\Pool Nonpaged Bytes, Memory\Pool Nonpaged Allocs.
PoolMon (si disponible) : repérez les tags qui croissent anormalement (poolmon -b -p).

Si une fuite est suspectée, ciblez les pilotes tiers (antivirus, sauvegarde, chiffrement, HBA) avec Driver Verifier :

verifier /query
verifier /standard /driver MonPiloteTiers*.sys
:: Pour arrêter si nécessaire :
verifier /reset

Important : n’activez pas Verifier sur tous les pilotes d’un hôte de production sans fenêtre de maintenance ; ciblez en priorité les filtres tiers et gardez un accès de gestion hors bande.

7) Lecture avancée du minidump avec WinDbg (optionnel mais précieux)

.symfix
.reload
!analyze -v
kv
!process 0 1
!thread
!devstack &lt;DeviceObject du volume si disponible&gt;
!volsnap
!poolused 2

Confirmez PROCESS_NAME = vmms.exe et la trace fastfat!FatDeleteVcb.
Repérez le DeviceObject du volume : il permet d’identifier le disque/chemin (USB/SAN).
Inspectez les tags de pool si la piste non‑paged est plausible.

Correction et bonnes pratiques (détaillées)

Vérifier les disques

chkdsk X: /f /r

Planifiez au redémarrage si le volume est verrouillé. Pour chaque support FAT (EFI, USB, carte SD), répétez l’opération. Remplacez tout support présentant des secteurs réalloués ou instables.

Réparer les fichiers système

sfc /scannow
dism /online /cleanup-image /restorehealth

Maintenir à jour l’écosystème

Pilotes : contrôleurs SAS/NVMe/RAID, HBA, multipath.
Firmware : disques, backplane, cartes HBA/NIC si concernées.
Plateforme : BIOS/UEFI & microcode CPU.
OS : correctifs Windows, mises à jour Hyper‑V/Failover Cluster.

Examiner le matériel

Débranchez tout périphérique USB ajouté récemment, testez les disques avec les outils constructeur et contrôlez les attributs SMART.
Exécutez Diagnostic mémoire Windows ou un test RAM constructeur pour exclure des erreurs non paginées.

Analyser les journaux d’événements

Dans Observateur d’événements, filtrez Système et Application :

Disk / storport : erreurs/temps d’attente E/S (ID 7, 51, 129, 153, 157).
fastfat : incohérences ou démontages inattendus de volumes FAT.
autochk : résultats de chkdsk au démarrage.

Assainir l’architecture Hyper‑V

Stockez VHD(X), checkpoints et fichiers de configuration de VM sur NTFS ou ReFS (CSV ou partage SMB 3), jamais sur FAT/FAT32.
Après correctif matériel/logiciel, exécutez Validate Cluster pour vérifier la santé du stockage, réseau et quorum.
Avant maintenance, basculer les VM vers un autre nœud pour éviter l’indisponibilité.

Surveiller la mémoire noyau

Suivez Memory\Pool Nonpaged Bytes et corrélez avec l’activité sauvegarde/AV/scan.
Mettez à jour/désactivez temporairement les filtres tiers trop consommateurs du pool.
Si nécessaire, augmentez la RAM ou ajustez la mémoire dynamique Hyper‑V pour réduire la pression noyau.

Arbre décisionnel de dépannage

Question	Action	Résultat attendu
Un volume FAT/FAT32 est‑il présent (y compris EFI) ?	Vérifier via PowerShell, assainir avec `chkdsk`, remplacer si instable.	Plus de crash 0x23, journaux propres.
Des VHD(X)/checkpoints résident‑ils sur FAT ?	Déplacer vers NTFS/ReFS, supprimer checkpoint corrompu, recréer si besoin.	Chemins de stockage conformes, I/O stables.
Erreurs storport/disk récurrentes ?	Mettre à jour pilotes/firmware, vérifier câblage/baies, MPIO.	Disparition des timeouts/erreurs I/O.
Non‑paged pool en hausse continue ?	Identifier le tag via PoolMon, cibler le pilote avec Verifier, patcher/remplacer.	Pool stabilisé, plus d’éviction noyau.
Crashs persistants après assainissement ?	Collecter un dump complet, escalader au support éditeur/fournisseur matériel.	Diagnostic profond par symboles et trames.

Scripts prêts à l’emploi

Inventaire et contrôle des volumes FAT/FAT32

# 1) Lister les volumes FAT/FAT32 et leur état
$fat = Get-Volume | Where-Object {$_.FileSystem -match 'FAT'}
$fat | Format-Table DriveLetter, FileSystem, HealthStatus, Size, SizeRemaining -Auto

# 2) Planifier un chkdsk /f pour chacun (attention /r peut être très long)

foreach ($v in $fat) {
if ($v.DriveLetter) {
Write-Host "Planification chkdsk sur" $v.DriveLetter":"
cmd /c "chkdsk $($v.DriveLetter): /f"
}
}

# 3) Vérifier les périphériques amovibles connectés

Get-PnpDevice -Class Disk -PresentOnly | Sort-Object FriendlyName | ft Status, FriendlyName, InstanceId -Auto

Audit des chemins VHD/VHDX

$report = foreach ($vm in Get-VM) {
  $disks = Get-VMHardDiskDrive -VMName $vm.Name
  foreach ($d in $disks) {
    $root = [System.IO.Path]::GetPathRoot($d.Path)
    $dl = $root.Substring(0,1)
    $vol = Get-Volume -DriveLetter $dl -ErrorAction SilentlyContinue
    [PSCustomObject]@{
      VM         = $vm.Name
      VHDX       = $d.Path
      Drive      = $dl
      FileSystem = $vol.FileSystem
    }
  }
}
$report | Sort-Object VM | Format-Table -Auto
$report | Where-Object {$_.FileSystem -match 'FAT'}

Contrôle du non‑paged pool (PerfMon via PowerShell)

# Collecteur rapide : Nonpaged Bytes sur 15 minutes, intervalle 15 s
$ctr = "\Memory\Pool Nonpaged Bytes"
typeperf $ctr -si 15 -sc 60 | Out-File C:\temp\nonpaged.csv

Bonnes pratiques pour éviter la récidive

Interdisez le stockage de VM sur USB/FAT et désactivez l’accès direct à des supports amovibles non maîtrisés.
Standardisez NTFS/ReFS pour VM et CSV ; privilégiez ReFS pour gros volumes et résilience des métadonnées.
Validez le cluster après tout changement (pilotes, firmware, ajout de disques, patchs).
Surveillez les événements Disk/storport, la latence I/O et la santé SMART.
Documentez et automatisez les vérifications (tâches planifiées de collecte de journaux, rapports de volumes).

Points d’attention et cas particuliers

Un 0x23 persistant après correction d’un support FAT pointe souvent un driver filtrant défectueux ; ciblez‑le avec Driver Verifier.
La partition EFI (FAT32, ~100 Mo) peut être vérifiée/réparée. En cas de corruption, recréez les fichiers d’amorçage avec bcdboot.
Si la charge mémoire est en cause (pics de sauvegarde, antivirus, DLP), ajustez la mémoire dynamique des VM ou augmentez la RAM de l’hôte.
En cluster, quarantainez temporairement un nœud qui reproduit les incidents le temps d’épuiser la piste pilote/firmware.

Checklist finale de remise en production

Tous les volumes FAT/FAT32 vérifiés (chkdsk OK) ; EFI saine.
Aucun VHD/VHDX/checkpoint sur FAT/FAT32 ; tout migré vers NTFS/ReFS.
Pilotes/firmware/BIOS mis à jour ; correctifs Windows/Hyper‑V/Cluster appliqués.
PerfMon : Nonpaged Bytes stable ; pas de croissance anormale.
Observateur d’événements : plus d’erreurs Disk/storport/fastfat depuis la dernière maintenance.
Validate Cluster sans échecs bloquants.

Conclusion

Le couple fastfat.sys + vmms.exe dans un crash 0x23 sur un hôte Hyper‑V oriente d’abord vers un support FAT/FAT32 corrompu ou instable. En traçant méthodiquement les volumes concernés, en assainissant le stockage (NTFS/ReFS uniquement pour les VM), en mettant à jour la pile de stockage et en surveillant la mémoire noyau, on élimine la grande majorité des récidives. Si, malgré tout, le problème persiste, la collecte d’un dump complet suivie d’une analyse avancée reste l’option la plus efficace pour identifier un pilote fautif ou un défaut matériel plus subtil.

Windows Server 2022 Hyper‑V : résoudre le BSOD 0x23 FAT_FILE_SYSTEM (fastfat.sys, vmms.exe)