Não, isso não significa que os dados foram perdidos. Significa simplesmente que o IRP (IO Request Packet) atingiu o tempo limite enquanto o IO System aguardava sua conclusão e, portanto, foi tentado novamente. Quando um thread inicia qualquer operação de E / S, o gerente de E / S cria um IRP para representar a operação conforme ela passa pelo sistema.
O IRP é armazenado em seu estado inicial em uma lista de buffer / look-aside, para que possa ser tentada novamente se falhar na primeira vez. Isso fornece a atomicidade que se esperaria de qualquer sistema transacional para que possamos ter mais confiança de que você não obterá muitos dados corrompidos ou incompletos gravados em seu disco.
Este evento faz todo o sentido no caso de uma falha no MPIO. Digamos que o Windows leia ou escreva algo do armazenamento SAN. A solicitação é enviada e, no mesmo instante, eu cortei um dos cabos para a SAN. Essa solicitação nunca será concluída e, assim, o Windows tentará a solicitação novamente, somente que, desta vez, a solicitação seguirá o outro caminho.
Esses eventos também ocorrem quando os discos estão sobrecarregados ou muito lentos. Você pode notar que essas mensagens coincidem com backups agendados, etc. O disco pode estar lento e ocupado, e algum IRP aleatório atingiu o tempo limite e teve que tentar novamente. O IRP pode estar ficando preso em uma rotina de serviço de interrupção, ou uma chamada de procedimento adiada, ou o que quer que seja.
Eu pude ver muitos drivers de filtro de E / S em sua pilha exacerbando esse problema também.
Não é que esse comportamento não tenha ocorrido exatamente como nas versões anteriores do Windows, mas sim que a Microsoft aparentemente decidiu exibir esses eventos no Win8 / Server 2012.
Editar: Você pode encontrar os IRPs pendentes de um thread com um depurador de kernel: kd> !irp 1a2b3c4d , onde você encontrou esse endereço anteriormente emitindo o comando kd> !process 8f7d6c4a , que listará todos os IRPs associados aos encadeamentos associados a esse processo. kd> !process 0 0 para listar todos os processos em execução.
Depois de listar as informações sobre um IRP usando o comando! irp, você poderá identificar facilmente qual driver tratou pela última vez o IRP porque ele terá um > apontando para ele na lista. Em seguida, para obter mais informações sobre o que o driver estava fazendo com esse IRP, faça um kd> !devobj 1a2b3c4d5e6f , onde esse é o endereço real do objeto do dispositivo.
Em seguida, faça um kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA usando o endereço da estrutura PrivateFdoData que você obteve.
Agora você está pronto para despejar a estrutura de dados AllTransferPacketsList que você obteve de PrivateFdoData.
A idéia é, você está rastreando o que o motorista estava fazendo com o IRP da última vez que foi visto. Se o IRP for AWOL por muito tempo, ele será expirado e tentado novamente desde o início. Isso pode ser causado por tantas coisas ... até mesmo um raio cósmico perdido. Mas o importante é que a transação será repetida desde o início e não será considerada completa até que o gerente de IO diga que é.
Ah, e há também IO agnóstico de thread, que é uma lata de worms completamente diferente. :)
Para mais informações sobre este tópico, eu altamente recomendo o capítulo 8, Sistema I / O, do Windows Internals 6ª edição, de Mark Russinovich, Margosis, et al.
** Editar: ** Eu finalmente encontrei a KB oficial para este erro: link
A operação IO deve ser repetida 8 vezes, uma vez por minuto, até que o Windows desista.
Editar: conforme prometido: link