Corriger le BSOD RESOURCE_NOT_OWNED (0xE3) sur Windows Server 2022 : FastFAT, FSLogix et pilotes filtres

Votre Windows Server 2022 Datacenter redémarre avec un écran bleu RESOURCE_NOT_OWNED (0xE3) impliquant fastfat.sys ? Suivez cette procédure pas‑à‑pas (correctifs, vérifications Fslogix, pilotes filtres, scripts PowerShell et WinDbg) pour enrayer définitivement ces crashs en production.

Sommaire

BSOD répété « RESOURCE_NOT_OWNED » (0xE3) sur Windows Server 2022 Datacenter

Vue d’ensemble

Depuis quatre mois, un serveur Windows Server 2022 subit des BSOD récurrents. Les minidumps indiquent le code 0xE3 RESOURCE_NOT_OWNED avec une pile qui passe par fastfat.sys puis ntkrnlmp.exe. Ce stop code signifie qu’un pilote tente de libérer une ressource (verrou ERESOURCE) qu’il n’a pas acquise. Autrement dit : un driver « joue » avec un verrou qu’il ne possède pas, ce qui fait chuter le noyau.

Contexte typique dans lequel on rencontre ce bugcheck : filtres de systèmes de fichiers (antivirus, sauvegarde, DLP, agent EDR), pilotes de disques/contrôleurs (RAID/HBA/NVMe), et environnements RDS/VDI où FSLogix insère un mini‑filtre (frxdrvvt.sys).

Diagnostic express (en un coup d’œil)

Symptôme/Contexte	Hypothèse la plus probable	Test rapide	Action immédiate
BSOD 0xE3, pile avec `fastfat.sys`	Bug race condition FastFAT corrigé par une CU	Vérifier build & KB installée	Installer la CU d’avril 2024 (20348.2402) ou plus récent
RDS/VDI avec profils FSLogix	Ancienne version FSLogix / fuite de verrou	Contrôler version FSLogix	Mettre à niveau ≥ 2210 HF4 (2.9.8884) ou 25.xx
Présence de filtres tiers (AV, sauvegarde, DLP)	Pilote filtre libérant mal un ERESOURCE	`fltmc filters`	Mettre à jour ou retirer le filtre fautif
Volumes FAT/ExFAT branchés	Chemins code FastFAT sollicités	`Get-Volume`	Retirer/convertir en NTFS

Réponse & solution (priorités)

Action prioritaire	Détails	Pourquoi ?
Installer les dernières CU/SSU	Appliquez au minimum la cumulative update d’avril 2024 (KB5036909, build 20348.2402). Cette mise à jour corrige un race condition dans `fastfat.sys`. Installez ensuite les CU ultérieures (elles supplantent la KB d’avril).	De nombreux 0xE3 associés à `fastfat.sys` cessent après cette correction du pilote FastFAT.
Mettre à jour / tester FSLogix	Mettez à niveau vers FSLogix 2210 Hotfix 4 (2.9.8884) au minimum, ou idéalement vers la branche FSLogix 25.xx (v3). Des versions plus récentes incluent explicitement des corrections liées à des bugcheck `E3` lors de scénarios de redirection.	FSLogix insère un mini‑filtre kernel (`frxdrvvt.sys`) : des versions antérieures sont connues pour provoquer des fuites de verrous/BSOD dans certaines conditions.
Lancer Driver Verifier	Exécutez `verifier /standard /all` 24–48 h en fenêtre maîtrisée. S’il désigne un pilote fautif, mettez ce driver à jour ou désinstallez‑le.	Driver Verifier force les drivers à révéler des corruptions latentes (notamment mauvais usage des ressources/verrous).
Mettre à jour firmware & pilotes stockage	Pilotes RAID/HBA/NVMe/StorPort, agents de sauvegarde/EDR/AV, tout filtre de stockage. Validez également les firmwares (ex. Dell HBA330, contrôleurs NVMe).	Les filtres de fichiers datés sont une cause fréquente de `RESOURCE_NOT_OWNED`.
Écarter les volumes FAT	Retirez ou convertissez en NTFS tout support FAT/ExFAT non critique (clés USB, cartes SD, volumes systèmes déployés en FAT par des appliances).	Réduit les passages dans le code FastFAT (`fastfat.sys`), zone concernée par le correctif.
Capturer un dump complet	Si le problème persiste : configurez un complete memory dump, ouvrez un dossier auprès du support Microsoft et joignez le bucket `0xE3_nt!ExpReleaseResourceSharedForThreadLite`.	Permet une analyse noyau complète du thread fautif et du pilote impliqué.

Mesures complémentaires utiles

Intégrité système : sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth.
Disques : chkdsk /f sur toutes les partitions NTFS/ReFS (planifier au redémarrage pour le volume système).
Corrélation temporelle : reliez la première date de crash aux installations de pilotes/agents (sauvegarde, EDR, imprimantes, drivers GPU) ou aux mises à jour récentes.
Hyper‑V / RDS : appliquez les CU sur les hôtes Hyper‑V et validez la compatibilité matérielle (ex. serveurs lames, R750) avec Server 2022 et vos pilotes.

Procédure pas‑à‑pas détaillée

1) Confirmer la build et les KB installées

Objectif : s’assurer que le serveur a reçu au minimum la CU d’avril 2024 (20348.2402) puis les CU plus récentes.

# Afficher la build exacte (ex. "20348.2402")
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($cv.CurrentBuild).$($cv.UBR)"

# Vérifier si la KB d'avril 2024 est installée

Get-HotFix -Id KB5036909 -ErrorAction SilentlyContinue

# Lister les 15 dernières mises à jour installées

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15 Source,HotFixID,InstalledOn

Si la build est inférieure à 20348.2402, ou si certaines CU postérieures manquent, programmez l’installation via WSUS/Windows Update/Catalogue. Bonnes pratiques : capture VSS/instantané, fenêtre de maintenance, vérification des sauvegardes.

2) Mettre à niveau FSLogix (ou l’isoler)

FSLogix insère un mini‑filtre (frxdrvvt.sys) et un service (frxsvc). Plusieurs corrections ultérieures ont visé des plantages de type E3 sur des chemins de redirection. Recommandations :

Version minimale : FSLogix 2210 Hotfix 4 (2.9.8884).
Version conseillée en 2025 : FSLogix 25.xx (v3), qui apporte des correctifs supplémentaires et des améliorations de stabilité sur RDS/AVD (dont des fix explicitement liés à des E3 dans des scénarios de redirections).

Vérifier la version installée :

# Méthode 1 : binaire du service
$frx = Get-Command 'C:\Program Files\FSLogix\Apps\frxsvc.exe' -ErrorAction SilentlyContinue
if ($frx) { (Get-Item $frx.Source).VersionInfo.FileVersion } else { "FSLogix non détecté" }

# Méthode 2 : Registre (si présent)

Get-ItemProperty 'HKLM:\SOFTWARE\FSLogix\Apps' -ErrorAction SilentlyContinue |
Select-Object Release, Version, InstallPath

Test d’isolement (maintenance uniquement) : désactiver temporairement FSLogix sur un nœud de test ou durant une plage de faible charge :

# Désactiver Profiles / ODFC par stratégie locale
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\ODFC"     /v Enabled /t REG_DWORD /d 0 /f

# Stopper service et désactiver le driver (redémarrage requis)

Stop-Service frxsvc -Force
sc.exe config frxsvc start= disabled
sc.exe config frxdrvvt start= disabled
Restart-Computer

Si les crashs cessent avec FSLogix désactivé : mettez à niveau vers la dernière version prise en charge, revalidez les exclusions AV et votre stratégie de redirections.xml.

3) Dresser l’inventaire des minifiltres et pilotes sensibles

Un 0xE3 est quasi toujours logiciel. Identifions les filtres susceptibles de mal gérer un verrou :

# Liste des mini-filtres en place
fltmc filters

# Instances par volume (cherchez des filtres tiers)

fltmc instances

# Pilotes signés installés (ex. stockage, AV, sauvegarde)

Get-CimInstance Win32\_PnPSignedDriver |
Sort-Object DriverDate -Descending |
Select-Object -First 50 DeviceName, DriverVersion, DriverDate, Manufacturer

# Périphériques stockage et versions pilotes

Get-PnpDevice -Class "SCSIAdapter","Storage","HDC" -Status OK |
Get-PnpDeviceProperty DEVPKEY\_Device\_DriverVersion,DEVPKEY\_Device\_DriverDate |
Format-Table

À mettre à jour en priorité : pilotes HBA/RAID/NVMe/StorPort, agents de sauvegarde (VSS, CBT), filtres EDR/AV, chiffrage, DLP.

4) Écarter les volumes FAT/ExFAT

Le pilote fastfat.sys gère FAT/ExFAT. Limitez son exposition sur un serveur :

# Repérer les volumes concernés
Get-Volume | Select-Object DriveLetter, FileSystem, FileSystemLabel, HealthStatus

# Conversion FAT -> NTFS (exige l'exclusivité du volume ; sauvegardez avant)

# convert X: /FS\:NTFS

Retirez si possible tout média amovible FAT/ExFAT non indispensable (clés USB, SD). Pour des appliances qui montent du FAT, voyez avec l’éditeur une alternative NTFS ou un mode réseau (SMB/NFS) neutre côté kernel.

5) Activer Driver Verifier (contrôle des pilotes)

Attention : Driver Verifier est intrusif et peut provoquer des BSOD ciblés sur les drivers fautifs. Utilisez‑le en période contrôlée.

# Activer les règles standard sur tous les pilotes
verifier /standard /all
shutdown /r /t 0

# Vérifier l'état

verifier /querysettings

# Désarmer au besoin

verifier /reset

Après un ou plusieurs redémarrages induits par Verifier, analysez les nouveaux dumps : le pilote incriminé y apparaît généralement en clair.

6) Vérifications de base système

# Intégrité des fichiers et image
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

# Consistance NTFS/ReFS (planifier si nécessaire)

chkdsk C: /f

7) Configurer un dump mémoire complet

Un dump complet est crucial pour poursuivre l’analyse si le problème persiste.

Ouvrez Système > Paramètres avancés > Démarrage et récupération.
Dans Écriture des informations de débogage, sélectionnez Image mémoire complète (ou automatique à défaut).
Assurez une taille de fichier d’échange suffisante (au moins la RAM si « complet »), puis redémarrez.

En cas de BSOD, récupérez : C:\Windows\MEMORY.DMP et le lot de minidumps (C:\Windows\Minidump). Ouvrez un dossier avec Microsoft et communiquez le bucket vu dans l’Observateur d’événements (ex. 0xE3_nt!ExpReleaseResourceSharedForThreadLite).

Analyse avancée avec WinDbg (cheat‑sheet)

Sur un dump (mini ou complet), cherchez les verrous, la pile et le driver déclencheur :

!analyze -v
!locks
kb
!thread
!stacks 2
lmvm fastfat
!verifier 3

Indicateurs fréquents :

Pile noyau montrant ExReleaseResourceForThreadLite ou ExpReleaseResourceSharedForThreadLite et un pilote tiers juste au‑dessus.
Locks détenus par un autre thread au moment du release.
Traces de mini‑filtres (précisez l’ordre d’empilement via fltmc).

Plan de remédiation « 60 minutes »

Mettre à jour le serveur vers une build ≥ 20348.2402 puis installer toutes les CU disponibles.
Mettre à niveau FSLogix vers 2210 HF4 a minima (recommandé : 25.xx), redémarrer, valider.
Mettre à jour pilotes/firmware stockage et filtres (AV/EDR, sauvegarde). Retirer tout filtre obsolète.
Retirer/convertir les volumes FAT/ExFAT. Ne laisser que NTFS/ReFS en production.
Activer Driver Verifier 24–48 h si BSOD persiste, récupérer le dump et corriger le pilote pointé.
Basculer en dump complet et ouvrir un ticket Microsoft si nécessaire.

Exemples de scripts & commandes utiles

Lister et dater les crashs 0xE3

Get-WinEvent -FilterHashtable @{LogName='System'; ID=1001} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'BugCheck\s+E3' -or $_.Message -match '0x000000E3' } |
  Select-Object TimeCreated, ProviderName, Id, Message

Repérer rapidement les drivers non Microsoft

Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DriverProviderName -notlike '*Microsoft*' } |
  Sort-Object DriverDate -Descending |
  Select-Object DeviceName, DriverVersion, DriverDate, DriverProviderName -First 100

Ordre d’empilement des filtres

fltmc filters
fltmc instances C:

Conversion d’un volume FAT en NTFS (exemple)

# Sauvegardez d'abord !
convert E: /FS:NTFS

Cas particuliers & points d’attention

Serveurs RDS/AVD et FSLogix : au‑delà de 2210 HF4, les builds 25.xx (v3) apportent des correctifs ciblant des instabilités lors de la gestion de redirections et peuvent éliminer des E3 résiduels. Mettez aussi à jour le client Teams si présent, et validez vos exclusions AV sur les fichiers VHD/VHDX FSLogix.
Antivirus/EDR : vérifiez que les exclusions officielles sont en place (répertoires FSLogix, dossiers de profils, chemins VSS/sauvegarde). Beaucoup d’E3 disparaissent après mise à niveau de l’agent de sécurité.
Matériel : bien que rare pour un 0xE3, écartez un contrôleur défectueux (contrôleur RAID/NVMe) via mises à jour firmware et tests I/O ciblés. Vérifiez aussi BIOS/UEFI et microcodes.
Postes d’administration : utilisez la même version du SDK/WinDbg que la cible quand c’est possible et assurez la symbolication (.symfix, .reload).
Volumes réseau mappés via pilotes tiers (iSCSI/FC/NFS) : validez les initiateurs et multipathing (MPIO) à jour.

FAQ

Le code 0xE3 peut‑il venir d’une RAM défectueuse ?
C’est exceptionnel : 0xE3 est quasi toujours dû à une erreur logique d’un pilote (mauvaise gestion d’ERESOURCE). Testez tout de même la RAM si vous avez d’autres symptômes (erreurs WHEA, corruptions aléatoires).

Faut‑il activer Driver Verifier en production ?
Seulement en fenêtre de maintenance, et de préférence sur un nœud RDS/cluster isolé. Verifier provoque volontairement des plantages pour épingler le pilote fautif.

Pourquoi viser spécifiquement la CU d’avril 2024 ?
Elle inclut une correction explicite d’un race condition dans fastfat.sys. Toute CU plus récente l’intègre également.

Dois‑je supprimer tous les périphériques FAT ?
Pas nécessairement, mais tout volume FAT/ExFAT inutile doit être retiré ou converti pour limiter les appels à FastFAT sur un serveur.

Points clés à retenir

0xE3 est essentiellement logiciel ; le matériel est rarement en cause.
Microsoft a corrigé un bug FastFAT intégré aux CU (avril 2024 pour Server 2022). Les CU ultérieures l’embarquent.
FSLogix non à jour et les filtres pilotes tiers sont les suspects principaux. Leur mise à niveau corrige la majorité des cas.

En résumé, commencez par mettre le système et FSLogix à niveau, puis faites valider les pilotes avec Driver Verifier : dans la plupart des environnements, ces étapes suffisent à éliminer durablement les écrans bleus « RESOURCE_NOT_OWNED ».

Annexe : check‑list opérationnelle

✅ Build ≥ 20348.2402, CU ultimes appliquées (production gelée pendant la fenêtre).
✅ FSLogix mis à jour (≥ 2210 HF4 ou 25.xx), exclusions AV revues, redirections validées.
✅ Pilotes/firmware stockage et filtres (AV/EDR/sauvegarde) à jour.
✅ Volumes FAT/ExFAT retirés/convertis.
✅ Driver Verifier testé 24–48 h, dump(s) collecté(s).
✅ Si persistant : dump complet, ticket Microsoft avec bucket communiqué.

Modèles de communication (pour le CAB/Change Advisory Board)

Message de maintenance planifiée (exemple)

« Nous allons appliquer les mises à jour cumulatives Windows Server 2022 et mettre à niveau FSLogix pour corriger des incidents BSOD 0xE3. Fenêtre : 22h00–23h30. Impact : déconnexion RDS pendant le redémarrage (<3 min). »

Compte‑rendu post‑incident (exemple)

« Cause racine : race condition FastFAT + ancien mini‑filtre FSLogix. Actions : CU avril 2024 puis CU courantes installées, FSLogix 25.xx déployé, filtres EDR mis à niveau, suppression volumes FAT. Résultat : 0 BSOD sur 14 jours. »

Modèle d’arbre de décision

Si pile → fastfat.sys → mettre à jour (CU) → retirer FAT → si persiste → FSLogix présent ? → mettre à niveau → Driver Verifier → pilote tiers identifié → mise à jour/suppression → OK. Sinon → dump complet + support Microsoft.

Bonnes pratiques supplémentaires

Observabilité : centralisez les journaux (Event 1001 BugCheck, Kernel‑Power 41), sauvegardez les dumps, corrélez avec les déploiements SCCM/Intune/WSUS.
Change management : une seule variable par changement. Vérifiez la stabilité 48–72 h entre deux étapes.
Rollback : prévoyez un plan de retour en arrière (snapshots Hyper‑V/VMware, sauvegarde système) avant les mises à jour d’agents.

Conclusion

Le couple « FastFAT corrigé + FSLogix à jour + hygiène des filtres » résout l’immense majorité des BSOD 0xE3 sur Windows Server 2022. Ajoutez Driver Verifier pour désigner sans ambiguïté le pilote fautif lorsqu’un filtre tiers persiste à mal libérer ses ressources. Avec ces étapes, vous revenez à une plateforme RDS/AVD stable et prédictible.