BSOD 0x0000007E su Dell PowerEdge R740xd con Windows Server 2019 dopo espansione RAID 6: diagnosi e fix passo‑passo

Un server Dell PowerEdge R740xd con Windows Server 2019 va in BSOD 0x0000007E un minuto dopo l’avvio normale, subito dopo l’espansione di un RAID 6. In questa guida trovi una procedura concreta per isolare i driver responsabili, stabilizzare StorPort e rimettere il sistema in produzione in modo sicuro.

Indice

Contesto e sintomi

Il caso parte da un PowerEdge R740xd con Windows Server 2019. Il sistema operativo risiede su un RAID 1 invariato, mentre i volumi dati sono ospitati su un RAID 6 che è stato esteso da 16 a 24 dischi (OCE/OCR — Online Capacity Expansion/Reconfiguration). Dal primo riavvio successivo all’espansione, a circa 60–90 secondi dall’avvio normale, il server va in BSOD con SYSTEMTHREADEXCEPTIONNOTHANDLED (0x0000007E). In Modalità provvisoria l’avvio è regolare.

Cosa significa lo STOP 0x0000007E

SYSTEMTHREADEXCEPTIONNOTHANDLED indica che un thread in kernel-mode ha generato un’eccezione non gestita. Le cause più comuni sono driver difettosi o incompatibili, conflitti fra filter driver (backup/antivirus/antimalware) e lo stack I/O del disco (StorPort/miniport del controller), oppure firmware/BIOS che espongono combinazioni borderline quando l’hardware cambia (come dopo un’OCE). In presenza di Safe Mode funzionante, la probabilità che il problema sia legato a driver terzi o a un miniport storage sale sensibilmente, perché in provvisoria vengono caricati solo i componenti minimi e la maggior parte dei filtri è disabilitata.

Mappa delle cause probabili

Area	Possibile causa	Segnali tipici
Driver	Driver PERC/miniport SAS non allineato alla nuova topologia; filter driver di backup (es. CBT), antivirus, HIPS.	BSOD dopo il caricamento dei servizi; Eventi “disk/ntfs/storport”; Safe Mode OK.
Firmware/BIOS/ACPI	Residue incompatibilità con ACPI, caching/shadowing del BIOS o impostazioni UEFI/Option ROM.	Crash aleatori a freddo; comportamento diverso cambiando impostazioni di memoria.
File system / dischi	Errori logici emergenti in sincronizzazione RAID o subito dopo l’estensione del volume.	Eventi 129/153 StorPort, 11/51 Disk, 55 NTFS; performance irregolare; rebuild/bgi in corso.

Diagnosi rapida

Se devi ridurre subito il rischio di downtime, esegui nell’ordine:

Avvia in Modalità provvisoria e disabilita temporaneamente i servizi di backup e i relativi filtri (es. CBT) per i volumi dati.
Esporta i minidump da C:\Windows\Minidump e analizzali per individuare il modulo colpevole.
Aggiorna o ripristina il driver PERC/miniport alla versione consigliata per Windows Server 2019.
Controlla lo Stato RAID in iDRAC e attendi che BGI/rebuild finiscano prima di stressare l’I/O.
Applica gli aggiornamenti cumulativi di Windows Server e riavvia in manutenzione.

Procedura completa passo‑passo

Recuperare e analizzare i minidump

In Modalità provvisoria, copia i file .dmp da C:\Windows\Minidump\ su un percorso sicuro.
Apri il dump con WinDbg e lancia: !analyze -v lm kv Concentrati su MODULENAME, IMAGENAME e sullo stack. Se compaiono moduli come percsas3.sys, storport.sys, ntfs.sys oppure filtri come veeamfltr.sys, stcvsm.sys o driver antivirus, hai già una pista.
Se il bugcheck è riportato come 0x1000007E, trattalo allo stesso modo (variante equivalente).

Controllare Event Viewer

In Registri di Windows > Sistema filtra gli ultimi minuti prima del crash. Eventi utili:

StorPort: 129 (reset di dispositivo), 153 (ritardi I/O), 11 (controller), 12 (inizializzazione).
Disk/NTFS: 55 (coerenza FS), 98/157 (rimozione spazio/percorso), 51 (errore di pagina).
Service Control Manager: driver/servizi che non si avviano o si arrestano inaspettatamente.

Prendi nota dell’ordine temporale: se i messaggi StorPort precedono il BSOD di pochi secondi, lo stack storage è il primo sospetto.

Aggiornare o ripristinare i driver critici

Su R740xd sono comuni PERC H740P/H840 (miniport percsas3). Agisci così:

Identifica versioni e filtri caricati: driverquery /v /fo table > C:\Temp\driverquery.txt fltmc filters pnputil /enum-drivers > C:\Temp\drivers.txt Cerca riferimenti a PERC, SAS, HBA, filtri di backup/antivirus.
Allinea il miniport PERC: installa la versione più recente firmata per Windows Server 2019 e compatibile con l’hardware. Se il problema è iniziato subito dopo un aggiornamento, valuta un rollback alla build precedente da Gestione dispositivi → Controller di archiviazione → Proprietà → Driver → Ripristina driver.
HBA/SAS expander: aggiorna eventuali driver HBA e il firmware degli expander/backplane via iDRAC o strumenti di gestione.
Filtri terzi: se il dump o i registri puntano a minifilter (backup CBT, antivirus), disabilita temporaneamente i loro servizi e riavvia. Confermato il miglioramento, reinstalla o aggiorna alla release compatibile.

Driver Verifier (opzionale ma risolutivo)

Usalo solo su driver non‑Microsoft e in una finestra di manutenzione: il sistema potrebbe crashare di proposito per evidenziare il colpevole.

In Modalità provvisoria: verifier /reset verifier /standard /driver nome_driver.sys
Riavvia in modo normale e attendi il BSOD esplicativo (riporterà il driver verificato). Se entri in boot‑loop, rientra in provvisoria e verifier /reset.

Impostazioni BIOS/UEFI e ACPI

Disabilita Memory Caching/Shadowing (se presenti) e salva.
Verifica che il Boot Mode sia UEFI e che le legacy option ROM siano disattivate (coerenza con l’installazione del sistema).
Assicurati che la mappatura MMIO e le impostazioni NUMA non siano state alterate da aggiornamenti o profili “performance” aggressivi.

Coerenza disco e file system

Un’OCE su RAID 6 attiva attività di Background Initialization e possibilmente Patrol Read. Finché non è “Optimal”, evita carichi intensi.

Esegui controlli file system: chkdsk C: /f /r chkdsk D: /scan Per i volumi di sistema, il controllo verrà schedulato al riavvio.
Monitora in iDRAC/OMSA lo stato dei virtual disk (BGI/Rebuild/Optimal) e i contatori di errori. Se un disco fallisce, escludilo e ricostruisci il set.

Patch di sistema e hotfix

Applica gli aggiornamenti cumulativi di Windows Server 2019 e le eventuali SSU. Diverse build migliorano la stabilità di StorPort e MPIO in presenza di grandi LUN/VD con topologie miste. Verifica:

winver
Get-HotFix | Sort-Object InstalledOn | Select-Object -Last 10

Test hardware esteso

Esegui SupportAssist / ePSA in pre‑boot con test di memoria estesi e diagnostica controller/dischi. Errori ECC ripetuti o latenze anomale su un canale SAS possono manifestarsi come crash software: rimuovi il componente difettoso e ripeti i test.

Indizi pratici per individuare il colpevole

BSOD solo in avvio normale: quasi sempre un driver o filtro terzo. Il dump dovrebbe indicare il modulo (image_name) o un contesto che ci arriva indirettamente (ntfs.sys “colpito” dallo stack storage).
Eventi 129/153 prima del crash: latenza/disconnessione sul percorso disco → controlla cavi SAS, backplane, firmware, miniport e filtri.
Crash dopo 60–90 secondi: molti filtri si attivano dopo il logon/servizi; il timing suggerisce un driver di terze parti che intercetta l’I/O su volumi dati appena enumerati (post‑OCE).

Comandi pronti all’uso

Raccolta log rapida

:: Eventi sistema ultimi 30 minuti
wevtutil epl System C:\Temp\System.evtx /ow:true /q:"*[System[TimeCreated[timediff(@SystemTime) <= 1800000]]]"

:: Driver installati (CSV)
driverquery /v /fo csv > C:\Temp\driverquery.csv

:: Filtri file system attivi
fltmc filters > C:\Temp\fltmc.txt

Boot logging

bcdedit /set {default} bootlog Yes
:: Il file sarà in C:\Windows\ntbtlog.txt

Driver Verifier

:: Elenca i driver verificati
verifier /querysettings

:: Disattiva in caso di boot-loop
verifier /reset

Tabella decisionale: aggiornare o tornare indietro?

Situazione	Azione consigliata	Motivo
Crash iniziato dopo update PERC	Rollback del driver alla build precedente	Regressione di compatibilità con la nuova topologia.
Dump con filtri backup/antivirus nello stack	Disabilita/aggiorna o reinstalla i filtri	I filtri intercettano IRP su volumi espansi causando eccezioni.
Eventi 129/153 e BGI in corso	Attendi stato “Optimal”, limita workload	Latenza da ricostruzione può triggerare timeout StorPort.
ePSA segnala errori memoria/disco	Sostituisci componente, ricostruisci RAID	Guasto hardware mascherato da errori software.

Procedura operativa dettagliata

Pre-salvataggio: in provvisoria, crea un restore point e un backup del volume di sistema. Esporta driver correnti (pnputil /export-driver *).
Analisi dump: annota IMAGE_NAME e l’offset dell’eccezione. Se l’exception code è 0xC0000005 (Access Violation), il crash è compatibile con dereferenziazioni improprie tipiche dei driver.
Verifica filtri: con fltmc identifica l’ordine di attacco. Disinstalla o disabilita filtri sospetti e riavvia.
Driver storage: ripristina o aggiorna PERC/miniport con pacchetti dedicati a Server 2019, quindi riavvia. Evita driver “universali” non certificati.
BIOS/UEFI: disattiva caching/shadowing, conferma UEFI puro, salva e riavvia.
File system: esegui chkdsk con correzione; per i volumi dati pianifica gli interventi fuori orario.
Windows Update: applica le CU recenti e riavvia.
Test: sotto carico progressivo (lettura/scrittura sequenziale → random), verifica che non compaiano nuovi eventi 129/153/11/55 per almeno 24 ore di esercizio.

Segnali che confermano la soluzione

Nessun BSOD in avvio normale e assenza di eventi 129/153 per 24–72 ore.
Stato iDRAC dei virtual disk su Optimal, Patrol Read completato senza errori.
Driver PERC allineato e filtri aggiornati; fltmc mostra solo i filtri attesi.
Prestazioni I/O stabili (latency p95 coerente con la baseline pre‑espansione).

FAQ

Perché in Modalità provvisoria il server non crasha?

Safe Mode carica lo stack storage essenziale e disattiva la maggior parte dei filter driver e servizi terzi. Se il problema scompare, il focus va spostato su driver e filtri non Microsoft.

È normale vedere `ntfs.sys` nello stack del dump?

Sì: ntfs.sys è spesso la vittima, non la causa. Segui la catena di chiamate e il MODULE_NAME effettivo del crash; spesso è un miniport o un filtro.

Devo aggiornare prima firmware o driver?

Mantieni parità fra firmware e driver: se aggiorni il firmware PERC/backplane, porta con te il miniport Windows corrispondente. Se la regressione è improvvisa, prova prima il rollback del driver per confermare l’ipotesi.

Posso usare Driver Verifier in produzione?

Solo in finestre di manutenzione, su driver non Microsoft e con la possibilità di rientrare in provvisoria. Verifier serve a far emergere l’errore, non a evitarlo.

Best practice per future espansioni RAID

Manutenzione pianificata: prevedi finestre ampie per OCE/OCR e test post‑espansione.
Allineamento preventivo: aggiorna prima driver PERC e firmware, poi esegui l’espansione.
Backup verificato: mantieni copie recenti e testate, soprattutto dei volumi di sistema.
Monitoraggio attivo: durante BGI/rebuild, limita i carichi e monitora Event Viewer e iDRAC.
Change management: documenta versioni, tempi e metriche di performance per facilitare eventuali rollback.

Checklist finale

Minidump analizzati, modulo sospetto identificato.
Eventi System raccolti e archiviati.
Driver PERC/HBA aggiornato o ripristinato.
Filtri di backup/antivirus verificati, aggiornati o disattivati.
BIOS/UEFI rivisti: caching/shadowing disattivati; UEFI coerente.
CHDSK completato su volumi critici, nessun errore pendente.
Windows Server 2019 aggiornato con le CU recenti.
ePSA/SupportAssist senza errori hardware.
iDRAC: RAID in stato Optimal, nessuna ricostruzione attiva.

Conclusioni

Il binomio “BSOD 0x0000007E subito dopo OCE su RAID 6” è quasi sempre la somma di driver storage/filtro non allineati e carico elevato su un array in ribilanciamento. Lavorando in provvisoria, partendo dai minidump e riallineando miniport PERC, filtri e impostazioni BIOS/UEFI, il ripristino è rapido e duraturo. Completa con verifiche su file system e diagnostica hardware, quindi monitora gli event log finché la situazione resta stabile per alcune giornate operative.

Appendice: procedure operative dettagliate

Esportare ed esaminare rapidamente gli eventi significativi

# PowerShell – Eventi critici/errore in 2 ore
$since = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2,3; StartTime=$since} |
  Sort-Object TimeCreated |
  Format-Table TimeCreated, Id, ProviderName, LevelDisplayName, Message -Auto

Inventario dei driver storage

# PowerShell – Driver PnP firmati
Get-WmiObject Win32_PnPSignedDriver |
  Where-Object {$_.DeviceClass -match 'SCSI|HBA|Storage|System'} |
  Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer |
  Sort-Object DeviceName

Verifica stato RAID via sistema operativo

Se utilizzi CLI di gestione (es. strumenti PERC/OMSA), esegui la query dei virtual disk per confermare Optimal e l’assenza di errori nei canali SAS. In mancanza, almeno controlla regolarmente i contatori di errori dal sistema operativo e gli eventi StorPort.

Ripristino d’emergenza

Se un nuovo driver peggiora la situazione: Ripristina driver da Gestione dispositivi o Ripristino configurazione di sistema (in provvisoria).
Se non riesci a rientrare: abilita il menu avanzato di avvio e carica Ultima configurazione nota funzionante o Ripristino da immagine.

Suggerimenti operativi aggiuntivi

Piano di ripristino rapido: custodisci backup recenti dei volumi critici e un driver pack offline con versioni stabili.
Rollback d’emergenza: se l’aggiornamento driver non è risolutivo, effettua rollback e raccogli evidenze (dump, eventi, versioni) per escalation.
Best practice nelle espansioni RAID: esegui patching di driver/firmware prima dell’OCE; pianifica con buffer temporali; fai post‑checks strutturati.

Questa guida è pensata per chi gestisce ambienti di produzione Windows Server su hardware Dell PowerEdge e desidera una traccia d’intervento ripetibile, focalizzata sui BSOD 0x7E legati allo stack storage dopo espansioni RAID.