RESOURCENOTOWNED (0xE3) su Windows Server 2022: diagnosi e fix avanzati per ambienti RDS/AVD con FSLogix

Il tuo cluster Windows Server 2022 Datacenter cade in BSOD con RESOURCENOTOWNED (0xE3)? In questa guida pratica trovi cause probabili, check rapidi e un playbook operativo per stabilizzare ambienti RDS/AVD con FSLogix e isolare il driver incriminato.

Indice

Panoramica del problema

Un host Windows Server 2022 va in arresto anomalo a intervalli regolari. Il minidump mostra il bugcheck 0xE3 RESOURCENOTOWNED e uno stack con riferimenti a fastfat!FatCommonClose. L’ambiente è tipicamente RDS/AVD con FSLogix per montare profili utente in VHD/VHDX. Nonostante firmware e patch recenti, i riavvii persistono.

Il quadro è coerente con un filter driver in modalità kernel (antivirus/EDR, backup, deduplica, profili VHD, cifratura, HBA/NIC storage) che rilascia una risorsa non posseduta. Il kernel, per prevenire corruzione dati, eleva il bugcheck 0xE3.

Come riconoscerlo subito

Segnale	Dove guardare	Indizio
Codice bugcheck	Minidump, WinDbg `!analyze -v`	`RESOURCENOTOWNED (E3)`, thread in close path file‑system
Stack con fastfat	WinDbg stack trace	Presenza di `fastfat!FatCommonClose` o `fastfat.sys` nello stack
Filtri file‑system	`fltmc filters`	Molteplici minifilter attivi: AV/EDR, backup, VSS, FSLogix
Eventi disco	Event Viewer → System, Microsoft‑Windows‑NTFS	Eventi di I/O anomalo, timeout, ID 55/57/261
Ambiente VHD	Condivisioni SMB profili	Profili in VHD(X) montati da FSLogix su share di rete

Cosa vuol dire RESOURCENOTOWNED

Il kernel usa strutture di sincronizzazione ERESOURCE sui percorsi I/O (open/close, rename, flush, ecc.). Se un driver chiama le API di rilascio (ad esempio ExReleaseResourceLite) senza aver acquisito la risorsa, emergono inconsistenze che il sistema non può tollerare. Per evitare corruzione del file‑system o deadlock globali, Windows forza un arresto con bugcheck 0xE3. In pratica: un driver in modalità kernel sta “liberando un lucchetto che non gli appartiene”.

Perché vedi fastfat anche se usi NTFS

fastfat.sys è il driver del file‑system FAT (FAT12/16/32). Può comparire nello stack anche su host prevalentemente NTFS per varie ragioni legittime: volumi rimovibili, VHD/VHDX con partizioni FAT, mount temporanei, percorsi di compatibilità, oppure stack I/O attraversati da minifilter che agganciano più file‑system. Vedere fastfat nello stack non implica che fastfat sia colpevole: spesso il crash viene “innescato” da un filter driver superiore nello stack che altera lo stato del lock.

Soluzione proposta in sintesi

Fase	Cosa fare	Perché è utile
Aggiornare sistema	Installare l’ultimo Cumulative Update di Windows Server 2022 (es. CU di ottobre 2025, KB 5034xxx) e micro‑patch di BIOS/driver storage/NIC.	Molti fix a deadlock e filtri I/O arrivano via CU e aggiornamenti OEM.
FSLogix	Portare FSLogix ad almeno build 2210 con hotfix recente (es. 2.9.8884.x) o superiore. In test, disabilitare temporaneamente i servizi `frxsvc` e il driver `frxdrvvt` per A/B test.	Versioni datate possono generare BSOD o stalli I/O in ambienti RDS/AVD.
Driver Verifier	Eseguire `verifier` sui driver di terze parti per forzare i percorsi d’errore e ottenere il modulo responsabile nel dump.	Identifica il driver che rilascia impropriamente la risorsa.
Filtri e storage	Aggiornare/isolare AV/EDR, backup, deduplica, cifratura, HBA/NIC, driver di minifilter di terze parti.	I minifilter sono la causa più comune di 0xE3 in ambienti con profili VHD e I/O intenso.
Integrità file‑system	Eseguire `chkdsk /scan` su tutti i volumi, controllare eventi NTFS e dischi.	Corruzioni o metadati inconsistenti possono esporre bug di driver in chiusura file.
Dump completi	Abilitare dump complete/active o live kernel per analisi approfondite o invio a supporto.	Serve visibilità su ERESOURCE, thread e driver nel contesto del crash.
Hardware	Test RAM, stress I/O, firmware controller RAID e microcode CPU.	Esclude alterazioni della memoria che falsano le strutture di sincronizzazione.

Procedura operativa dettagliata

Aggiornare Windows e firmware

Prima di ogni altra cosa, portare l’host all’ultimo livello di patch supportato:

Applicare l’ultimo Cumulative Update per Windows Server 2022 (canale LTSC), includendo Servicing Stack e .NET se presenti.
Aggiornare firmware BIOS/UEFI, driver storage/NIC, controller RAID, HBA, microcode CPU secondo il vendor.
Se si usa Hyper‑V, aggiornare anche gli Integration Services delle VM interessate e i driver paravirtualizzati.

Nota: il solo aggiornamento può risolvere molte regressioni in minifilter e percorsi di chiusura file.

Isolare o aggiornare FSLogix

In ambienti RDS/AVD, FSLogix è spesso nello stack I/O delle operazioni su VHD dei profili. Eseguire i seguenti passi:

Verificare versione: # Percorso tipico Get-Item "C:\Program Files\FSLogix\Apps\frxsvc.exe" | Select-Object FullName,@{n='ProductVersion';e={$_.VersionInfo.ProductVersion}}
Aggiornare ad almeno la release 2210 con hotfix recente (es. serie 2.9.8884.x) o superiore.
Test A/B disabilitando temporaneamente FSLogix su un nodo (o in maintenance window) per valutare la stabilità: Stop-Service frxsvc -Force sc.exe stop frxdrvvt sc.exe config frxsvc start= demand sc.exe config frxdrvvt start= demand Riavviare il nodo per scaricare il driver dal kernel Ripristino: sc.exe config frxdrvvt start= system sc.exe config frxsvc start= auto Start-Service frxsvc Attenzione: la disattivazione del driver può richiedere riavvio. Pianificare su un host di test o durante finestre di manutenzione.
Esclusioni AV/EDR: assicurarsi che cartelle e file FSLogix (in particolare .vhd/.vhdx dei profili) siano esclusi da scansione in tempo reale su host RDS e file server.
Condivisioni SMB: evitare deduplica sullo share dei profili e verificare che il file server sia supportato e aggiornato. Prediligere fixed‑size VHDX per ridurre frammentazione.

Driver Verifier mirato ai driver di terze parti

verifier.exe è lo strumento chiave per far emergere rapidamente l’autore del comportamento errato. Best practice:

Non attivarlo in modo indiscriminato su tutti i driver di sistema Microsoft.
Abilitarlo solo su terze parti e, se possibile, su una macchina di test o un nodo in rotazione.

Individuare i driver non Microsoft:

# Elenco minifilter caricati
fltmc filters

Elenco driver caricati con produttore

Get-WmiObject Win32_SystemDriver |
Select-Object Name,State,PathName,StartMode,DisplayName |
Sort-Object Name

Abilitare Verifier sui driver mirati:

verifier /reset
verifier /standard /driver frxdrvvt.sys veeamvfs.sys wdfilter.sys

Sostituire i nomi con quelli effettivamente presenti. Lasciare in esecuzione per almeno 24 ore o finché si riproduce il crash. Al successivo BSOD, l’analisi del dump dovrebbe indicare in chiaro il MODULE_NAME del driver colpevole.

Disabilitare Verifier dopo i test:

verifier /reset
shutdown /r /t 0

Controlli su filtri e stack I/O

Il bugcheck 0xE3 è tipicamente innescato in close path, quando filtri multipli interagiscono in modo non previsto. Mappa e valuta la catena:

fltmc filters
fltmc instances -v

Interventi tipici:

Aggiornare i componenti AV/EDR all’ultima engine e ridurre l’interposizione su VHD/VHDX.
Aggiornare agent di backup e driver file‑system driver (change block tracking, snapshot, ecc.).
Verificare componenti di cifratura, DLP, antimalware legacy o tool di “content indexing”.
In presenza di deduplica, considerare un test su volumi senza deduplica per i profili.

Integrità dei volumi e log di sistema

Esegui una validazione rapida su tutti i volumi, inclusi eventuali rimovibili o di staging:

# Per ogni volume
chkdsk C: /scan
chkdsk D: /scan
...

Nel registro eventi, controlla:

System: eventi Disk, Ntfs, storport, storahci, timeouts I/O.
Application: errori VSS, agent di backup, applicazioni che accedono a profili.
Microsoft‑Windows‑FSLogix: montaggi profilo, retry, errori di I/O su VHD.

Abilitare dump completi o live kernel

Il minidump spesso non basta. Abilita un dump più ricco:

# Attiva dump "Active" (o "Complete" se la dimensione pagina lo consente)
Automatic memory dump/Active spesso è un buon compromesso
wmic recoveros set DebugInfoType=7
Assicurati che la partizione di sistema abbia spazio sufficiente

In alternativa imposta i valori in HKLM\SYSTEM\CurrentControlSet\Control\CrashControl per il tipo di dump preferito. Per scenari avanzati, genera un Live Kernel Dump verso C:\Windows\LiveKernelReports tramite strumenti di diagnostica Microsoft o workflow WER; questo permette analisi senza fermare prolungatamente l’host.

Verifiche hardware

RAM: Windows Memory Diagnostic o strumenti vendor.
Storage: test I/O con carico sostenuto su volumi dati e profili; verifica latenza e retry.
RAID/HBA: firmware raccomandato, policy cache, coerenza con driver.

Analisi del dump: cosa cercare

Apri il dump con WinDbg e segui questo percorso:

!analyze -v
!thread
!locks
!verifier 3
kb
lmvm <nomedriversospetto>

!analyze -v: conferma del bugcheck E3 e modulo sospetto.
!locks: stato degli ERESOURCE e lock posseduti/non posseduti dal thread in crash.
!thread: IRP correnti e call stack del thread al momento dell’eccezione.
lmvm: versione esatta del driver, timestamp build e compagnia.

Tip: se nello stack appaiono funzioni Fat o FsRtl in chiusura, concentrati sui filtri sopra il file‑system driver.

Ottimizzazioni specifiche per RDS/AVD con FSLogix

Formato profilo: preferire VHDX fixed‑size per ridurre frammentazione e stress su allocazioni dinamiche.
Share SMB: collocare i profili su file server aggiornati e senza deduplica; applicare esclusioni AV server‑side per .vhd.
Policy FSLogix: rivedere impostazioni di montaggio, limite dimensione profilo e log di telemetria per individuare ritardi o retry.
Concorrenza: evitare scan full‑disk durante finestre di login di massa; pianificare backup a basso impatto.

Playbook decisionale

Usa questo albero per ridurre il tempo di isolamento:

Dopo l’ultimo CU il problema sparisce? Mantieni la baseline aggiornata e monitora; altrimenti continua.
Con FSLogix disattivato su un nodo i BSOD cessano? Aggiorna FSLogix e rivedi esclusioni AV; se persiste, apri caso con fornitore.
Con Driver Verifier attivo il dump punta un driver specifico? Aggiorna/sostituisci quel driver o disabilita la feature correlata; valida su nodo di test.
Eventi disco presenti? Esegui chkdsk, verifica storage e firmware; considera migrazione profili su storage affidabile.
Nessun responsabile individuato? Genera dump completi/live, raccogli ETW/WPR e coinvolgi supporto.

Comandi utili pronti all’uso

:: Filtri file‑system caricati
fltmc filters

:: Instanze per volume, utile per capire l’ordine dei filtri
fltmc instances -v

:: Verifier: reset e configurazione standard su driver mirati
verifier /reset
verifier /standard /driver  

:: Verifier: elenco impostazioni correnti
verifier /querysettings

:: Verifica rapida volumi
chkdsk /scan

:: Forzare riavvio immediato (post configurazioni Verifier)
shutdown /r /t 0

Checklist rapida da eseguire oggi

Aggiorna Windows Server 2022 all’ultimo CU e i firmware storage/NIC.
Aggiorna FSLogix ad almeno 2210 con hotfix recente; applica esclusioni AV per .vhd.
Abilita Driver Verifier sui driver terzi più sospetti; raccogli un nuovo dump.
Esegui chkdsk /scan e controlla gli eventi NTFS/Disk.
Se persiste, abilita dump completi o live, raccogli log e apri ticket al supporto competente con i dump allegati.

Domande frequenti

È sempre colpa di fastfat?

No. fastfat è spesso solo il punto in cui l’incongruenza esplode. Il responsabile reale è di solito un filter driver a monte della catena.

Che differenza c’è tra E3 e altri bugcheck I/O?

E3 indica rilascio di una risorsa non posseduta. Altri codici comuni: deadlock rilevati, accessi invalidi ad IRQL elevato, o violazioni in percorsi di paging. La cura è diversa e per questo serve un dump parlante.

Posso attivare Verifier su tutti i driver?

Sconsigliato in produzione: può introdurre overhead e nuovi crash “diagnostici”. Seleziona i driver non Microsoft e procedi per cerchi concentrici.

Se disabilito FSLogix, gli utenti perdono il profilo?

Se disattivi il driver/servizio, i profili VHD non vengono montati: pianifica su nodo di test, informa gli utenti e predisponi un fallback. Su host che rimangono in produzione, usa finestre di manutenzione.

Esempio di piano di stabilizzazione

Settimana	Azione	Esito atteso
Uno	Patch OS/firmware, aggiornamento FSLogix, esclusioni AV su VHD(X)	Riduzione immediata dei crash su gran parte dei nodi
Due	Driver Verifier su nodi canary; aggiornamento filtri backup/EDR	Individuazione driver problematico o conferma stabilità
Tre	Fine‑tuning storage e policy RDS/AVD; validazione su carico reale	Ritorno alla normalità e rollback del Verifier

Modello di richiesta dati per il supporto

Per accelerare la risoluzione con il supporto tecnico, prepara sempre:

Ultimo dump Active/Complete o Live Kernel del crash.
Output di fltmc filters e fltmc instances -v.
Versioni precise di FSLogix, agent AV/EDR, software di backup e loro driver kernel.
Eventi di sistema degli ultimi giorni (System, Application, Microsoft‑Windows‑FSLogix).
Topologia storage e configurazione dello share dei profili (SMB, deduplica, esclusioni AV).

Approfondimenti tecnici

Come si rompe un ERESOURCE

Sequenza tipica che porta a 0xE3:

Un thread del sistema o di un driver acquisisce un shared/exclusive lock su una risorsa del file‑system.
Un secondo filtro interferisce (ad esempio con un callback di close o cleanup) e sbilancia il conteggio di lock.
Alla chiusura, il driver “A” tenta di rilasciare una risorsa non più in suo possesso → violazione e bugcheck E3.

Il dump completo consente di ispezionare la struttura ERESOURCE e le liste di owner/waiter, chiarendo chi ha acquisito cosa e in quale ordine.

Conclusioni

Il bugcheck RESOURCENOTOWNED (0xE3) su Windows Server 2022 è quasi sempre sintomo di una collisione tra filter driver nello stack I/O. In contesti RDS/AVD con FSLogix il fattore di rischio aumenta per via dei profili in VHD(X) e dell’elevata concorrenza sul file‑system. Un approccio strutturato — patch OS/firmware, aggiornamento o isolamento FSLogix, Driver Verifier mirato, controllo integrità volumi e dump ricchi — consente nella maggior parte dei casi di eliminare il BSOD o di isolare con precisione il driver difettoso per una correzione definitiva.

Check‑list rapida

Aggiorna: ultimo CU Windows, firmware, driver storage/NIC.
FSLogix: almeno 2210 con hotfix recente; esclusioni AV sui VHD(X).
Driver Verifier su driver terzi; attendi un dump parlante.
chkdsk /scan ed esame Event Log.
Dump completi/live e apertura ticket se necessario.

Mettendo in campo questi passaggi il BSOD E3 tipicamente scompare o resta confinato a un componente preciso, facilitando il fix permanente.