Windows Server 2022: come risolvere l’Event ID 153 (I/O operation retried) con diagnosi hardware, firmware e file system

Su Windows Server 2022 Datacenter l’Event ID 153 (“The I/O operation at logical block address … for Disk X was retried”) indica che le operazioni disco sono state ritentate per timeout. Qui trovi una guida operativa, con priorità, script e check per capire se il problema è hardware, firmware/driver o logico, e come risolverlo in modo sicuro.

Indice

Cos’è l’Event ID 153 e perché compare

Quando il sistema registra l’Event ID 153 nel registro System con origine Disk, significa che almeno un’operazione di I/O verso un’unità di sistema non ha risposto in tempo ed è stata ritentata dal driver. Per l’utente questo si manifesta spesso con rallentamenti, applicazioni che sembrano “sospese”, servizi che non rispondono e, nei casi peggiori, riavvii anomali e bugcheck (schermata blu) correlati a errori di storage irrecoverable.

Nella grandissima maggioranza dei casi, la radice del problema è fisica (disco degradato, cavo/backplane difettoso, controller/HBA in crisi, alimentazione instabile, SAN/iSCSI con percorsi flapping). Più raramente è solo un problema logico del file system. Per questo è fondamentale partire dall’hardware, raccogliere prove, aggiornare firmware/driver e solo dopo eseguire interventi sul file system.

Sintomi tipici osservabili

Picchi di latenza disco e applicazioni che rispondono a scatti.
Eventi nel registro System: 7 (Bad Block), 11 (Controller), 129 (Storport reset), 153 (I/O ritentato).
Riavvi imprevisti o bugcheck frequenti (es. 0x7A KERNELDATAINPAGEERROR, 0xF4 CRITICALOBJECT_TERMINATION), spesso associati a problemi di storage.
In ambienti virtualizzati, l’errore può comparire nel guest anche se l’origine è nel path del datastore a livello host.

Checklist rapida per iniziare (senza rischi)

Metti al sicuro i dati: verifica lo stato dei backup e, se possibile, esegui un backup/coerenza snapshot prima dei test invasivi.
Raccogli informazioni senza cambiare nulla: eventi di sistema, contatori performance, stato SMART/affidabilità dei dischi.
Identifica con precisione “Disk X”: mappa il numero del disco dell’evento con il drive fisico (slot/seriale), per evitare sostituzioni sbagliate.
Se il server è in cluster/VM: verifica anche lato host, HBA, switch, multipath e storage array.

Piano d’azione prioritizzato

La tabella seguente riassume cosa fare, in che ordine e con quale obiettivo. È costruita per ridurre il rischio operativo e accelerare la diagnosi.

Priorità	Azione	Scopo / Dettagli	Evidenze attese
1. Conferma rapida dell’hardware	Avvia i tool diagnostici del vendor (es. HP SSA/SSACLI, Dell DST/OMSA, Lenovo XClarity, LSI/Broadcom MegaRAID Storage Manager). Ispezione fisica: cavi SAS/SATA, backplane, connettori, alimentazione ridondata, ventole e temperatura dello chassis.	Ricerca di settori danneggiati, errori del controller, surriscaldamento, instabilità di alimentazione.	Stato disco “Predictive Failure” o “Degraded”, errori PHY/CRC elevati, warning su backplane o PSU.
2. Controllo SMART e log di sistema	PowerShell (Esempi): # Stato fisico e affidabilità Get-PhysicalDisk \| Select FriendlyName, MediaType, SerialNumber, HealthStatus, OperationalStatus, Size Contatori di affidabilità (necessita Ruoli/RSAT Storage) Get-PhysicalDisk \| Get-StorageReliabilityCounter \| Select FriendlyName, Temperature, Wear, ReadErrorsTotal, WriteErrorsTotal, ReadLatencyMax, WriteLatencyMax Eventi critici nel registro System Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(7,11,129,153)} \| Select TimeCreated, Id, ProviderName, Message \| Sort TimeCreated -Descending Se disponibile, usa anche `smartctl -a` per un report SMART approfondito.	Rilevare pre-failure, latenze anomale, timeout I/O e pattern temporali degli eventi.	Eventi 7/11/129/153 ravvicinati, valori SMART in peggioramento, temperature alte o errori totali in crescita.
3. Aggiornamento firmware/driver	Firmware dischi, backplane/enclosure, controller RAID/HBA; BIOS/UEFI e chipset. Driver storport/HBA aggiornati e coerenti con il firmware.	Bug e incompatibilità sono una causa comune di I/O ritentati identici all’ID 153.	Riduzione/azzeramento degli eventi 153 dopo update; latenza più stabile ai contatori disco.
4. Test sul percorso di storage	Sposta temporaneamente il disco su un’altra porta/slot o su un controller diverso (se possibile). In SAN/iSCSI: verifica link, switch, SFP, zoning, frame/CRC, multipathing (MPIO), queue depth e policy. Confronta i percorsi: se il problema segue il disco → disco guasto; se resta sulla porta → porta/cavo/backplane.	Isolare il componente guasto lungo il path (disco, cavo, porta, controller, shelf/enclosure, fabric).	Pattern coerenti (es. cambiata la porta, spariscono gli errori → porta/cavo difettosi).
5. Verifica logica del file system	`chkdsk /scan` per una verifica online preliminare (NTFS). `chkdsk /f /r` solo in maintenance window con volume offline. Se ReFS: `refsutil scrub /volume :` e verifica dell’integrità. VSS/CSV: controlla writer e stato CSV se in cluster.	Event 153 può comparire anche dopo I/O interrotti che causano corruzione logica: riparare la struttura del file system.	Registro Application e System puliti dopo la riparazione, nessun nuovo 153 riconducibile a logica.
6. Monitoraggio post-intervento	Performance Monitor: `Avg. Disk sec/Transfer`, `Avg. Disk sec/Read`, `Avg. Disk sec/Write`, `Current Disk Queue Length`. Controlla Event ID 7/11/129/153 nelle 24–48 ore successive.	Confermare che la latenza sia rientrata e gli eventi non ritornino.	`Avg. Disk sec/Transfer` < 0,015 s (SAS/SSD) e assenza di nuovi 153.
7. Pianificazione della sostituzione	Se dopo i passi 1–5 gli errori persistono o SMART indica “FAILING NOW”, sostituisci solo il disco o il controller guasto. Sostituisci l’intero server solo se: più dischi/controller sono danneggiati, il modello non è più supportato o emerge un difetto sistemico (alimentazione/backplane).	Evitare sostituzioni massive inutili riducendo downtime e costi.	Componenti sostituiti con seriale/firmware documentati; stabilità confermata dal monitoraggio.

Mappare “Disk X” con il disco fisico giusto

Uno degli errori più costosi è rimuovere il disco sbagliato. Usa la seguente procedura per correlare l’indice Disk dell’evento con slot, seriale e LED del carrier:

Individua l’indice Windows del disco (quello citato nell’evento): Get-Disk | Select Number, FriendlyName, SerialNumber, UniqueId, BusType, PartitionStyle, OperationalStatus
Collega l’indice con il disco fisico: # Mostra slot/Enclosure quando disponibili Get-PhysicalDisk | Select FriendlyName, SerialNumber, HealthStatus, OperationalStatus, @{n='Location'; e={$_.PhysicalLocation} }
Se hai un controller RAID, usa l’utility del vendor per accendere l’LED “locate” sul carrier del disco interessato (opzione “blink/identify”).
Traccia completa da volume a disco: # Dato un volume (es. E:) $vol = Get-Volume -DriveLetter E $part = Get-Partition -Volume $vol $disk = Get-Disk -Number $part.DiskNumber $disk | Format-List *

Analisi dei log e filtraggio mirato

Per analizzare rapidamente gli eventi più rilevanti, crea una vista personalizzata in Event Viewer (System → Create Custom View) con gli ID: 7, 11, 129, 153. In alternativa, usa PowerShell:

# Ultimi eventi critici storage
$ids = 7,11,129,153
Get-WinEvent -FilterHashtable @{LogName='System'; Id=$ids; StartTime=(Get-Date).AddDays(-7)} |
  Select TimeCreated, Id, ProviderName, Message | Sort TimeCreated -Descending

Osserva i pattern temporali (burst in finestre ristrette, correlazione con backup, snapshot, manutenzioni, switch path SAN) e il dispositivo citato. Un’ondata di 129 (reset) seguita da 153 (ritento) è spesso indizio di path instabile.

Firmware e driver: verifica e best practice

Coerenza firmware/driver: aggiorna il firmware del controller (RAID/HBA) e installa il driver raccomandato per quella versione. Evita mix “driver nuovo + firmware molto vecchio”.
Dischi e backplane: controlla firmware dei dischi (specialmente SAS/SSD enterprise) e dell’enclosure/backplane; aggiorna se il vendor ha fix per timeout/CRC.
BIOS/UEFI e chipset: bug del microcodice PCIe o della gestione energetica possono impattare le code I/O. Imposta il piano energetico su Prestazioni elevate; disabilita “PCIe Link State Power Management” dove appropriato su server.
Policy cache del controller: attiva Write Back solo se il controller è protetto (BBU/Capacitor). Una cache non protetta aumenta il rischio di corruzione in caso di fault.

Diagnosi differenziata: storage diretto vs SAN/iSCSI

Storage diretto (SAS/SATA/NVMe)

Controlla errori PHY/CRC nei log del controller (indicativi di cavi/backplane). Sostituisci il cavo o cambia slot per verificare se l’errore segue il disco.
NVMe: monitora temperature e throttling; verifica firmware del drive e dell’NVMe backplane/switch. Timeout NVMe possono manifestarsi come pause improvvise.
RAID: se uno stripe member ha errori, il volume può rimanere online ma con ritardi estesi. Pianifica rebuild o sostituzione preventiva.

SAN/iSCSI/FC

Multipath (MPIO): verifica che tutti i path siano Active/Optimized e che il round-robin/policy sia raccomandata per lo storage target. Path flapping = eventi 129/153.
Fabric e switch: controlla link down/up, SFP degradati, errori CRC, buffer credit, zoning/VSAN. Cambia porta o SFP per esclusione rapida.
Queue depth: in workload elevati, una coda insufficiente provoca backoff e retry. Adegua QD secondo raccomandazioni dello storage.
Jumbo/iSCSI: MTU incoerenti causano ritrasmissioni e latenze: allinea MTU end-to-end o torna a 1500 per test.

File system: quando e come intervenire

NTFS: esegui chkdsk /scan per un check online. Se emergono problemi, pianifica chkdsk /f /r (offline). Non eseguire /r su volumi potenzialmente ospitati su dischi fisicamente difettosi: prima sostituisci l’hardware.
ReFS: usa refsutil scrub e i log di integrità. ReFS può isolare corruzioni singole, ma se l’hardware è instabile l’errore ricompare.
VSS/CSV: controlla writer VSS e stato CSV. Su cluster, verifica che il CSV non stia facendo redirected I/O prolungato (indizio di path guasto).

Monitoraggio e soglie consigliate

Contatore	Target (guida pratica)	Interpretazione
`Avg. Disk sec/Transfer`	< 0,015 s (SAS/SSD); < 0,020–0,025 s (SAS 10k); < 0,050 s (SATA 7.2k)	Valori superiori e persistenti indicano colli di bottiglia o errori di percorso.
`Avg. Disk sec/Read / Write`	Simili alle soglie sopra	Se sale solo Write, sospetta cache/firmware del controller; solo Read: disco degradato o path saturato.
`Current Disk Queue Length`	<= numero di dischi sottostanti (regola molto generale)	Code sistematicamente alte con 153 → timeouts/ritenti.

Runbook operativo (passo-passo)

Backup e finestra di manutenzione: assicurati di avere un ripristino rapido. Se possibile, snapshot coerenti con applicazioni.
Raccolta informazioni iniziale: # Panoramica dischi e affidabilità Get-PhysicalDisk | Select FriendlyName, SerialNumber, HealthStatus, OperationalStatus Get-PhysicalDisk | Get-StorageReliabilityCounter | Select FriendlyName, Temperature, ReadErrorsTotal, WriteErrorsTotal, Wear Eventi storage ultimi 3 giorni Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(7,11,129,153); StartTime=(Get-Date).AddDays(-3)} | Select TimeCreated, Id, Message | Sort TimeCreated -Descending KPI rapidi Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Transfer' -SampleInterval 2 -MaxSamples 15
Esclusione guasti facili: cambia cavo/porta/slot; se il problema segue il disco, etichettalo come sospetto.
Aggiornamento firmware/driver: aggiorna in blocco coerente (controller + dischi + BIOS/chipset). Riavvia programmato se necessario.
Retest e monitoraggio: verifica eventi e KPI; se gli eventi cessano, mantieni il monitoraggio 48 ore.
Intervento sul file system: esegui chkdsk o refsutil solo dopo aver escluso cause fisiche.
Sostituzione mirata: se SMART indica Failing o gli errori persistono, sostituisci il componente guasto. Documenta seriali/firmware.

Ambienti virtualizzati e cluster

Hyper-V/VMware: aggiorna integration tools/VM tools e driver paravirtuali. Se l’errore è nel guest, controlla anche i log dell’host (datastore, HBA, path).
CSV (Cluster Shared Volumes): verifica se i volumi entrano in redirected I/O. Eventi di rete/SMB Direct e MPIO possono innescare 153 a cascata.
Pass-through/RDM: i retry possono derivare da path flapping esterno alla VM: analizza fabric/switch.

Riduzione del rischio e prestazioni

Cache coerente: attiva write-back solo con protezione energetica della cache (BBU/Capacitor).
Paging e posizionamento file: preferisci il pagefile su disco locale affidabile. Evita di collocare file VHDX o database su dischi con warning.
MPIO sano: abilita path verification e mantieni un intervallo di verifica ragionevole per scoprire path “morti” senza impatto eccessivo.
Energia e raffreddamento: PSU ridondate e in buona salute; temperature sotto i limiti raccomandati riducono i retry.

FAQ operative

Devo sostituire tutto il server?

No, quasi mai. L’Event 153 nella maggior parte dei casi si risolve sostituendo il componente sul percorso di storage (disco/cavo/porta/controller) o aggiornando firmware/driver. Cambia l’intero server solo se ci sono indizi di difetto sistemico, obsolescenza o molteplici componenti guasti.

Posso lanciare subito `chkdsk /f /r`?

Meglio di no. Prima escludi il guasto fisico, altrimenti rischi di stressare ulteriormente un disco al collasso e peggiorare la corruzione. Usa /scan come verifica online preliminare.

Come interpreto i contatori di affidabilità?

L’aumento regolare di ReadErrorsTotal/WriteErrorsTotal, temperature alte e Wear vicino al limite su SSD sono indicatori di sostituzione imminente. LatencyMax molto elevata spiega i retry (Event 153).

Perché vedo 153 nel guest ma l’array host è sano?

Il guest registra il sintomo (operazione ritentata) anche se la causa è nel path del datastore (host HBA, fabric, array). Analizza layer per layer.

Comandi utili (pronti all’uso)

# 1) Mappa rapida dei dischi con stato
Get-PhysicalDisk | Select FriendlyName, SerialNumber, MediaType, HealthStatus, OperationalStatus

2) Affidabilità dettagliata

Get-PhysicalDisk | Get-StorageReliabilityCounter |
Select FriendlyName, Temperature, ReadErrorsTotal, WriteErrorsTotal, Wear, ReadLatencyMax, WriteLatencyMax

3) Eventi storage ultimi 7 giorni

Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(7,11,129,153); StartTime=(Get-Date).AddDays(-7)} |
Select TimeCreated, Id, ProviderName, Message | Sort TimeCreated -Descending

4) KPI latenza in tempo reale (30 secondi)

Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Transfer' -SampleInterval 1 -MaxSamples 30

5) Check NTFS online

chkdsk C: /scan

6) ReFS scrub

refsutil scrub /volume E:

7) Export eventi per RMA

wevtutil epl System C:\Temp\System.evtx

Script “tutto-in-uno” per raccolta prove

Usa lo script seguente per comprimere in un unico file le informazioni da inviare al supporto o da archiviare come baseline.

$out = 'C:\Temp\SupportBundle'
New-Item -ItemType Directory -Path $out -Force | Out-Null

Eventi storage

Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(7,11,129,153); StartTime=(Get-Date).AddDays(-14)} |
Export-Csv "$out\events_storage.csv" -NoTypeInformation -Encoding UTF8

Dischi e affidabilità

Get-PhysicalDisk | Select FriendlyName, SerialNumber, HealthStatus, OperationalStatus, Size |
Export-Csv "$out\physicaldisk.csv" -NoTypeInformation -Encoding UTF8
Get-PhysicalDisk | Get-StorageReliabilityCounter |
Export-Csv "$out\reliability.csv" -NoTypeInformation -Encoding UTF8

KPI snapshot

Get-Counter '\PhysicalDisk()\Avg. Disk sec/Read','\PhysicalDisk()\Avg. Disk sec/Write',
'\PhysicalDisk(*)\Current Disk Queue Length' -SampleInterval 1 -MaxSamples 10 |
Export-Counter -Path "$out\counters.blg"

Informazioni sistema

Get-ComputerInfo | Out-File "$out\computerinfo.txt" -Encoding UTF8
(Get-Disk | Format-List * | Out-String) | Out-File "$out\disk_detail.txt" -Encoding UTF8

Compress-Archive -Path "$out*" -DestinationPath "$out.zip" -Force
Write-Output "Bundle creato: $out.zip"

Motivazione tecnica (perché l’approccio funziona)

Event 153 = sintomo di timeout: l’I/O è ritentato perché l’hardware o il path non ha risposto nei tempi attesi. Per questo la priorità è stabilizzare il percorso fisico.
Bugcheck e corruzione: i riavvii improvvisi sono spesso collegati a bugcheck generati da errori di storage non recuperabili. Rimuovendo le cause hardware riduci cascate di errori logici.
Prova ed esclusione: spostare porta/slot, aggiornare firmware/driver e misurare latenza dopo l’intervento permette di distinguere tra guasto fisico, incompatibilità software o problemi logici residui.

Suggerimenti aggiuntivi e buone pratiche

Backup prima di test invasivi: chkdsk /f /r e aggiornamenti firmware vanno eseguiti solo con backup recenti e verificati.
Paging e timeout HBA in ambienti lenti: mantieni il file di paging su disco locale affidabile; valuta time‑out HBA più lunghi quando il backend ha latenze notevolmente variabili (solo se raccomandato dal vendor).
Documentazione per RMA: conserva stampa di firmware/driver, seriali sostituiti, export eventi, temperature e contatori di affidabilità pre/post intervento.

Albero decisionale sintetico

Event 153 presente →
- Ci sono Event 7/11/129 correlati? Sì → concentra la diagnosi sull’hardware/driver/path.
- SMART/affidabilità OK, firmware vecchi? Sì → aggiorna firmware/driver e riprova.
- Gli errori seguono il disco spostato di porta? Sì → sostituisci disco; No → sospetta porta/cavo/backplane/controller.
- Solo dopo esclusione fisica → chkdsk/refsutil sul volume.

Quando sostituire l’intero server

Sostituisci l’intero server solo se:

Più componenti critici (dischi, controller, backplane, PSU) risultano guasti o con errori intermittenti non isolabili.
Il modello è fuori supporto e non sono più disponibili firmware/parti.
Ci sono difetti sistemici (alimentazione, chassis, backplane) che rendono instabile il percorso I/O anche dopo sostituzioni mirate.

In tutti gli altri casi, la sostituzione mirata (disco, cavo, controller) è la strategia più rapida, economica e a minor rischio.

Verifica finale (post‑fix)

Traccia 24–48 ore di log System per Event 7/11/129/153: devono essere assenti o drasticamente ridotti.
Monitora KPI latenza: Avg. Disk sec/Transfer entro le soglie del tuo profilo di storage.
Conferma nessuna corruzione nuova: chkdsk /scan o refsutil scrub senza errori.
Archivia un Support Bundle post‑fix (stessa procedura dello script sopra) come baseline.

Conclusioni operative

Conferma hardware con diagnostica vendor e ispezione fisica → è il passo che risolve più casi.
Aggiorna firmware/driver prima di qualunque intervento logico; molte catene di retry scompaiono con versioni stabili.
Esegui chkdsk solo dopo aver escluso guasti fisici.
Sostituisci il componente difettoso e monitora: il server intero si cambia solo per obsolescenza o multi‑guasti non isolabili.

In sintesi

Conferma hardware → raccogli prove con tool diagnostici.
Aggiorna firmware/driver → spesso risolve i retried I/O (Event 153).
Esegui chkdsk solo dopo avere escluso il guasto fisico.
Sostituisci il componente difettoso; l’intero server si cambia solo se obsoleto o con più punti di guasto.

Nota: se operi in ambienti regolati (sanità/finanza/PA), conserva log, checklist di approvazione e risultati di test a dimostrazione della due diligence tecnica.