Windows Server 2019: guida completa per risolvere BugCheck 0xC0000005 (BSOD)

Il tuo Windows Server 2019 si riavvia con schermate blu ricorrenti e codice 0xC0000005? In questa guida pratica trovi una procedura tecnica, passo‑passo, per individuare il driver o il componente in modalità kernel che causa l’accesso a memoria non valida e riportare il server a piena stabilità.

Indice

Contesto e sintomi

Il comportamento tipico è un riavvio improvviso ogni pochi giorni, spesso durante finestre di backup, scansioni antivirus o carichi batch notturni. Nel BugCheck (BSOD) compaiono eccezioni con codice 0xC0000005 (Access Violation): un driver o un componente in kernel mode ha tentato di leggere/scrivere un indirizzo non valido.

Event Viewer → System: Event ID 41 (Kernel-Power) e Event ID 1001 (BugCheck).
File dump generato in C:\Windows\MEMORY.DMP o in %SystemRoot%\Minidump.
Pattern temporali: spesso allineati a job pianificati (backup, scansioni, snapshot, sincronizzazioni RAID).

Perché 0xC0000005 è così frequente

L’eccezione 0xC0000005 è generica: non indica da sola “chi” ha causato l’errore, ma “cosa” è accaduto (accesso a memoria non autorizzato). Nei crash di Windows Server 2019 questa eccezione è spesso incapsulata in bugcheck come:

BugCheck	Nome	Quando si manifesta	Componenti spesso coinvolti
0x0000001E	KMODEEXCEPTIONNOT_HANDLED	Eccezione non gestita in kernel mode (es. access violation).	Driver di storage/NIC, filtri antivirus/backup, miniport RAID.
0x0000007E	SYSTEMTHREADEXCEPTIONNOTHANDLED	Thread di sistema fallisce su istruzione non valida.	Driver di filtro file, HBA, dedup, soluzioni EDR.
0x00000050	PAGEFAULTINNONPAGEDAREA	Accesso a pagina non valida in memoria non paginabile.	RAM instabile, driver che dereferenziano puntatori invalidi.
0x0000003B	SYSTEMSERVICEEXCEPTION	Eccezione in routine di servizio di sistema.	Stack grafico RDP, filtri rete, antivirus.

La chiave è correlare il modulo che ha lanciato l’eccezione con l’operazione in corso al momento del crash. La tabella seguente riassume le cause probabili e aggiunge esempi specifici utili in produzione.

Principali cause e segnali

Ambito	Dettagli ed esempi concreti	Segnali da cercare
Driver	Incompatibilità o corruzione (non solo Fujitsu; includere controller RAID/HBA Broadcom/LSI, Intel RSTe, driver NIC come e1x/ixgbe/vmxnet3, filtri file di antivirus/EDR, driver di backup/snapshot).	Stack trace con moduli `*.sys` di terze parti, crash sotto carico I/O o rete, aggiornamenti recenti.
Aggiornamenti di sistema	Cumulative update/SSU mancanti che correggono difetti del kernel, di `storport.sys`, `tcpip.sys`, `ntfs.sys`.	Build OS obsoleta (Server 2019 = 17763.x), UBR basso, fallback di driver in modalità legacy.
Hardware	RAM difettosa o borderline, dischi con contatori SMART in crescita, firmware RAID/SSD/NIC obsoleto, alimentazione o BBU/Cachecade instabili.	Errori ECC, riduzione link PCIe, log RAID con time‑out o patrol read aggressivo.
File di sistema	Corruzione di librerie di sistema `.sys`/`.dll` caricate da driver o servizi; driver mancanti in driver store.	SFC/DISM che riparano file, eventi SideBySide o CodeIntegrity.

Percorso di troubleshooting consigliato

Seguire il flusso nell’ordine: stabilizza, raccogli evidenze, analizza, correggi, verifica. Questa sequenza copre oltre il 90% delle cause tipiche in ambienti Windows Server 2019.

Stabilizzazione sicura
- Disabilita il riavvio automatico su errore: System Properties → Startup and Recovery. Così fotografi il BSOD e verifichi la generazione del dump.
- Imposta Automatic memory dump e verifica spazio su C: (consigliato ≥ 25–30 GB liberi).
- Se il crash si verifica durante carichi intensi, riduci temporaneamente la concorrenza dei job (meno thread/stream I/O, nessun snapshot concorrente) per mitigare l’impatto mentre indaghi.
Allinea patch di sistema
- Installa SSU e CU più recenti. Verifica la build: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ReleaseId, CurrentBuild, UBR Se la UBR è molto arretrata, aggiorna.
Analizza il dump
- Copia C:\Windows\MEMORY.DMP su un PC di test.
- Apri in WinDbg (Preview o X64): .symfix .reload !analyze -v .kv lmtn !thread !verifier 3 Annota: MODULENAME, IMAGENAME, STACKTEXT, DEFAULTBUCKET_ID.
Driver e firmware
- Allinea chipset, storage, rete, BIOS/UEFI, RAID controller, SSD/NVMe, HBA e schede di rete.
- Se il problema è iniziato dopo un aggiornamento, ripristina la versione precedente del driver coinvolto.
- Inventario rapido: pnputil /enum-drivers > C:\Temp\drivers.txt Get-WmiObject Win32_PnPSignedDriver | Sort-Object DriverDate -Descending | Select-Object DeviceName, DriverVersion, DriverDate, Manufacturer | Export-Csv C:\Temp\DriverInventory.csv -NoTypeInformation
Diagnostica hardware
- RAM: avvia Windows Memory Diagnostic in modalità estesa o esegui memtest86 per più passaggi.
- Dischi: chkdsk C: /r Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object FriendlyName, ReadErrorsTotal, Wear, Temperature Usa strumenti del vendor (es. Fujitsu) per RAID/SSD e controlla log di patrol read, media error, time‑out.
Integrità file di sistema sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
Event Viewer e correlazioni
- Filtra System su 41 (Kernel-Power) e 1001 (BugCheck). Aggiungi 6005/6006/6008 per sequenza di arresto/avvio.
- PowerShell per timeline: $ids = 41,1001,6005,6006,6008 Get-WinEvent -FilterHashtable @{LogName='System'; Id=$ids} | Select-Object TimeCreated, Id, ProviderName, Message | Sort-Object TimeCreated | Export-Csv C:\Temp\BSOD_Timeline.csv -NoTypeInformation
Driver Verifier (uso cauto)
- Attiva nelle ore di manutenzione: verifier /standard /all Riproduci il problema, poi analizza il nuovo dump. Disattiva con: verifier /reset Se la macchina non avvia, entra in Safe Mode e disattiva da lì.
Apri ticket con il vendor quando necessario
- Invia dump, versioni firmware e pacchetti driver; spesso esistono hotfix mirati per controller RAID/NIC.

Preparazione accurata del dump

Tipo di dump: “Automatic memory dump” è un buon compromesso. Per bug sporadici Full può aiutare, ma richiede più spazio.
Pagefile: lascia il file di paging su C: gestito dal sistema (necessario per dump completi/automatici).
Persistenza: verifica HKLM\SYSTEM\CurrentControlSet\Control\CrashControl (valori CrashDumpEnabled, Overwrite).
Crash manuale: su console KVM abilita CrashOnCtrlScroll per forzare un dump quando il sistema non risponde: HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters "CrashOnCtrlScroll"=dword:00000001 Premere due volte Ctrl+Scroll Lock sul dispositivo fisico/virtuale.
Simboli in WinDbg: .symfix .reload /f Senza simboli corretti la call stack può risultare fuorviante.

Interpretare l’analisi di WinDbg

Un output tipico di !analyze -v contiene:

EXCEPTION_CODE: se 0xC0000005, controlla READ/WRITE e l’indirizzo di violazione.
MODULENAME / IMAGENAME: il candidato principale. Confronta con lmtn per data e percorso.
STACK_TEXT: segui il flusso fino alla chiamata incriminata; cerca pattern come storport!RaidUnit... → vendorRaid.sys → nt!KiPageFault.

Comandi utili:

!thread               ; thread corrente e IRP eventualmente in volo
!irp <addr>           ; ispeziona richieste I/O
!devstack <device>    ; catena di driver (filtri) su un dispositivo
!verifier 3           ; driver monitorati e violazioni registrate
k, kn                 ; call stack (simboli e offset)
r                     ; registri CPU (verifica puntatori nulli)

Focus su storage e rete

Nella pratica, gran parte dei 0xC0000005 su server deriva da stack storage o rete.

Stack storage

Controller RAID/HBA con miniport Storport. Aggiorna firmware e driver in coppia. Verifica politiche di cache (Write‑Back/Write‑Through) e stato BBU.
SSD/NVMe: controlla throttling termico, firmware, log SMART. Evita mix eterogenei in array sensibili.
Filtri file: soluzioni EDR/AV, dedup, agenti di backup. Valuta esclusioni per percorsi di lavoro (database, VHDX, file temporanei).

Stack rete

Allinea driver NIC e disabilita temporaneamente offload avanzati (LSO/LRO, RSS, VMQ) per test A/B: Get-NetAdapterAdvancedProperty -Name * | Where-Object DisplayName -match 'Offload|RSS|VMQ' | Format-Table Name, DisplayName, DisplayValue -Auto
Se usi teaming o QoS, verifica che la modalità corrisponda allo switch fisico.
In ambienti virtualizzati, confronta versioni di VMware Tools / vmxnet3 o integrazioni Hyper‑V.

Server virtualizzato

Hyper‑V: assicurati che il livello di configurazione VM sia aggiornato; controlla gli Integration Services inclusi nell’OS. Evita snapshot prolungati su workload I/O‑intensivi.
VMware: aggiorna Tools e valuta, per test, l’uso di E1000E o LSI Logic SAS al posto di vmxnet3/pvscsi per isolare il problema driver.
Pass‑through (SR‑IOV/HBA): se presente, prova una VM senza pass‑through per escludere firmware/driver fisici.

Procedure diagnostiche concrete

Raccogli un pacchetto di evidenze

New-Item -ItemType Directory C:\Temp\BSOD -Force | Out-Null
Copy-Item C:\Windows\MEMORY.DMP C:\Temp\BSOD -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | 
  Out-File C:\Temp\BSOD\OS_Build.txt
pnputil /enum-drivers &gt; C:\Temp\BSOD\drivers.txt
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1001,6005,6006,6008} |
  Export-Csv C:\Temp\BSOD\SystemEvents.csv -NoTypeInformation
Get-PhysicalDisk | Get-StorageReliabilityCounter |
  Export-Csv C:\Temp\BSOD\StorageHealth.csv -NoTypeInformation
ipconfig /all &gt; C:\Temp\BSOD\network.txt
Get-NetAdapter | Format-List * | Out-File C:\Temp\BSOD\netadapters.txt

Verifica file di sistema

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Eventi personalizzati in Event Viewer

Crea una Custom View in System con ID 41, 1001, 6005, 6006, 6008, esporta e condividi il .evtx quando apri un ticket.

Driver Verifier senza sorprese

Attiva in finestre di minor carico e su server con accesso locale/ILO.
Seleziona standard settings; evita DDI compliance e randomized low resources su produzione a meno di indicazioni precise.
Prevedi recovery: se dopo l’attivazione il server va in boot loop, usa F8 → Safe Mode per eseguire verifier /reset.

Risoluzioni tipiche per scenari comuni

Scenario	Soluzione mirata	Verifica
Crash durante backup su volume dedup/RAID	Aggiorna driver miniport RAID + firmware controller/SSD, allinea agent di backup, valuta esclusioni percorso temporaneo.	Dump mostra catena `storport → vendorRaid.sys → nt!KiPageFault`.
BSOD sotto carico di rete	Aggiorna NIC; disattiva temporaneamente LSO/RSS/VMQ; rivedi teaming; controlla firmware switch.	Stack con `ndis.sys`/`tcpip.sys` e driver NIC; nessun errore storage.
Access violation legata ad antivirus/EDR	Aggiorna o sostituisci il driver del filtro; imposta esclusioni per database, VHDX, cartelle di lavoro ad alta I/O.	Modulo incriminato `.sys` del vendor sicurezza in MODULE_NAME*.
RAM borderline	Memtest esteso con più passaggi; sostituzione moduli; verifica canali e frequenze supportate dal server.	Episodi aleatori, errori ECC sporadici, bugcheck variabile.

Best practice operative

Lascia il dump su “Automatic” per avere prove, ma evita di saturare il disco di sistema.
Allinea BIOS, BMC/iRMC, RAID, NIC prima dei driver di sistema; le versioni devono essere supportate in coppia.
Quando rimuovi un driver difettoso, pulisci il driver store se necessario: pnputil /delete-driver oemXX.inf /uninstall /force
Evita più filtri sullo stesso stack (es. due EDR contemporanei, doppio filtro di cifratura).
Annota sempre data/ora di ogni modifica: permette rollback rapidi e correlazioni affidabili.

Checklist immediata

Patch OS all’ultima CU/SSU.
Inventario e aggiornamento chipset, storage, rete, BIOS/UEFI.
sfc e DISM completati senza errori.
Dump recenti analizzati con !analyze -v, modulo sospetto identificato.
Eventi 41/1001/6008 correlati a finestre di carico specifiche.
Se necessario, Driver Verifier usato in sicurezza e poi disattivato.
Ticket al vendor con pacchetto evidenze (dump, firmware, log RAID, timeline).

Domande frequenti

È sempre un problema di RAM? No. La RAM difettosa può causare access violation, ma nella pratica i 0xC0000005 su server sono spesso legati a driver di storage/rete o filtri file.

Quale dump impostare? Automatic/Kernel è la scelta standard in produzione; passa a Full per casi rari o quando lo stack è pesantemente offuscato da filtri.

Posso usare il server mentre eseguo Driver Verifier? È rischioso: verifica in finestre controllate e con accesso alla console, poiché il Verifier può forzare crash più rapidi dei driver difettosi.

Il bugcheck è iniziato dopo un aggiornamento driver: torna alla versione precedente del solo driver coinvolto e conferma con un test A/B.

Template per richiesta al vendor

• Modello server / seriale
* OS build (17763.x + UBR) e data ultime CU/SSU
* Versioni BIOS/BMC/RAID/NIC/SSD
* Tipo di storage (RAID livello, cache policy, BBU)
* Carichi tipici (backup, AV, batch) e orari dei crash
* Ultimi 2–3 MEMORY.DMP + minidump e CSV timeline eventi
* Inventario driver (DriverInventory.csv) e drivers.txt di pnputil

Errori da evitare

Rimuovere “a caso” più driver insieme: cambia una variabile alla volta.
Disabilitare gli aggiornamenti di sicurezza come soluzione permanente: crea più problemi di quanti ne risolva.
Ignorare firmware: spesso la correzione è nel microcodice del controller, non nel driver.
Tenere attivi più agenti di sicurezza in parallelo sullo stesso host.

Conclusioni

Un crash ricorrente con 0xC0000005 su Windows Server 2019 è risolvibile con un approccio strutturato: allineamento di sistema, analisi WinDbg, verifica mirata di driver e firmware, diagnosi hardware e correzione puntuale. Seguendo il percorso proposto — aggiornando, isolando i filtri, testando l’hardware e validando le modifiche con nuovi dump — tornerai a una piattaforma stabile e prevedibile per i tuoi carichi di produzione.

Appendice: comandi rapidi

Obiettivo	Comando
Verifica build OS	`winver` o PowerShell su `CurrentVersion\UBR`
Forza crash manuale	Abilita `CrashOnCtrlScroll`, poi premi due volte `Ctrl`+`Scroll Lock`
Analisi dump	`!analyze -v`, `lmtn`, `!thread`, `k`
Inventario driver	`pnputil /enum-drivers` e WMI `Win32_PnPSignedDriver`
Integrità OS	`sfc /scannow` e `DISM /RestoreHealth`
Diagnostica dischi	`chkdsk /r` e `Get-StorageReliabilityCounter`
Driver Verifier	`verifier /standard /all` → `verifier /reset`
Timeline eventi	PowerShell con `Get-WinEvent` su ID 41/1001/6005/6006/6008

Implementando la sequenza sopra (eliminare driver difettosi, testare hardware, aggiornare system software) si coprono oltre il 90% delle cause tipiche di bugcheck in Windows Server 2019. La parte cruciale è sempre la stessa: lasciare tracce (dump, timeline, inventario) e cambiare una variabile per volta.