No, ciò non significa che i dati siano stati persi. Significa semplicemente che l'IRP (IO Request Packet) è scaduto mentre l'IO System aspettava che si completasse, quindi è stato riprovato. Quando un thread inizia qualsiasi operazione IO, l'IO Manager crea un IRP per rappresentare l'operazione mentre passa attraverso il sistema.
L'IRP viene archiviato nel suo stato iniziale in un elenco buffer / di ricerca, in modo che possa essere riprovato se fallisce la prima volta. Ciò fornisce l'atomicità che ci si aspetterebbe da qualsiasi sistema transazionale in modo da poter essere più sicuri che non si otterrà un mucchio di dati corrotti o incompleti scritti sul disco.
Questo evento ha perfettamente senso in caso di errore MPIO. Supponiamo che Windows vada a leggere o scrivere qualcosa dalla memoria SAN. La richiesta viene inviata e nello stesso istante taglio uno dei cavi alla SAN. La richiesta non verrà mai completata e quindi Windows tenterà nuovamente la richiesta, solo che questa volta seguirà l'altro percorso.
Questi eventi si verificano anche quando i dischi sono sovraccarichi o semplicemente molto lenti. Potresti notare che questi messaggi coincidono con i backup pianificati, ecc. Il disco potrebbe essere lento e occupato e alcuni IRP casuali sono scaduti e hanno dovuto riprovare. L'IRP potrebbe rimanere bloccato in una routine di servizio di interruzione, in una chiamata di procedura differita o altro.
Potrei vedere un sacco di driver filtro IO nel tuo stack esacerbare anche questo problema.
Non è che questo comportamento non si sia verificato in questo modo nelle versioni precedenti di Windows, è solo che Microsoft ha deciso di presentare questi eventi in Win8 / Server 2012.
Modifica: puoi trovare gli IRP in sospeso di un thread con un debugger del kernel:, kd> !irp 1a2b3c4ddove hai precedentemente trovato quell'indirizzo emettendo il comando kd> !process 8f7d6c4ache elencherà tutti gli IRP associati ai thread associati a quel processo. kd> !process 0 0per elencare tutti i processi in esecuzione.
Dopo aver elencato le informazioni su un IRP usando il comando! Irp, puoi facilmente individuare quale driver ha gestito l'IRP per ultimo perché avrà un >puntamento ad esso nell'elenco. Quindi, per ottenere maggiori informazioni su ciò che quel driver stava facendo con quell'IRP, fai un indirizzo kd> !devobj 1a2b3c4d5e6fdove si trova l'oggetto reale del dispositivo.
Quindi fai un kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAusando l'indirizzo della struttura PrivateFdoData che hai.
Ora sei pronto per scaricare la struttura di dati AllTransferPacketsList ottenuta da PrivateFdoData.
L'idea è che stai rintracciando quale driver stava facendo cosa con l'IRP l'ultima volta che è stato visto. Se l'IRP è AWOL per troppo tempo, è scaduto e riprovato dall'inizio. Ciò può essere causato da così tante cose ... persino un raggio cosmico vagante. Ma la cosa importante è che la transazione verrà ritentata dall'inizio e non sarà considerata completa fino a quando il gestore IO non lo dirà.
Oh, e c'è anche IO indipendente dal thread che è una lattina di worm completamente diversa. :)
Per ulteriori approfondimenti su questo argomento, consiglio vivamente il capitolo 8, Sistema I / O, della sesta edizione di Windows Internals, di Mark Russinovich, Margosis, et al.
** Modifica: ** Ho finalmente trovato il KB ufficiale per questo errore: http://support.microsoft.com/kb/2819485/EN-US
L'operazione IO deve essere ripetuta 8 volte, una volta al minuto, fino a quando Windows non si arrende.
Modifica: come promesso: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx