Nie, nie oznacza to, że dane zostały utracone. Oznacza to po prostu, że upłynął limit czasu dla pakietu IRP (IO Request Packet), podczas gdy system IO czekał na jego zakończenie, więc próbowano go ponownie. Gdy wątek rozpoczyna dowolną operację we / wy, menedżer we / wy tworzy IRP, który reprezentuje operację przechodzącą przez system.
IRP zostaje zapisany w stanie początkowym na liście buforów / listy przeglądowej, dzięki czemu można go ponowić, jeśli zawiedzie po raz pierwszy. Zapewnia to atomiczność, jakiej można się spodziewać po każdym systemie transakcyjnym, dzięki czemu możemy być bardziej pewni, że nie dostaniesz wielu uszkodzonych lub niekompletnych danych zapisanych na dysku.
To zdarzenie ma idealny sens w przypadku awarii MPIO. Powiedzmy, że Windows idzie czytać lub pisać coś z pamięci SAN. Żądanie zostało wysłane, a jednocześnie przeciąłem jeden z kabli do sieci SAN. Żądanie nigdy się nie zakończy, więc system Windows spróbuje je ponownie, tylko tym razem wniosek podąży inną ścieżką.
Te zdarzenia występują również, gdy dyski są przeciążone lub po prostu bardzo wolne. Możesz zauważyć, że te wiadomości pokrywają się z zaplanowanymi kopiami zapasowymi itp. Dysk może być po prostu wolny i zajęty, a niektóre losowe IRP przekroczyły limit czasu i musiały spróbować ponownie. IRP może utknąć w procedurze obsługi przerwań, odroczonym wywołaniu procedury lub cokolwiek innego.
Widziałem, że na twoim stosie jest wiele sterowników filtrów we / wy, co dodatkowo pogarsza ten problem.
Nie chodzi o to, że takie zachowanie nie występowało tak jak we wcześniejszych wersjach systemu Windows, po prostu Microsoft najwyraźniej postanowił ujawnić te zdarzenia w Win8 / Server 2012.
Edycja: Możesz znaleźć zaległe IRP wątku z debuggerem jądra:, kd> !irp 1a2b3c4dgdzie wcześniej znalazłeś ten adres, wydając polecenie, kd> !process 8f7d6c4aktóre wyświetli wszystkie IRP powiązane z wątkami powiązanymi z tym procesem. kd> !process 0 0aby wyświetlić listę wszystkich uruchomionych procesów.
Po wyświetleniu informacji o IRP za pomocą polecenia! Irp można łatwo zauważyć, który sterownik ostatnio obsługiwał IRP, ponieważ będzie on >wskazywał na niego na liście. Następnie, aby uzyskać więcej informacji o tym, co ten sterownik robił z tym IRP, zrób to, kd> !devobj 1a2b3c4d5e6fgdzie jest rzeczywisty adres obiektu urządzenia.
Następnie kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAużyj adresu otrzymanej struktury PrivateFdoData.
Teraz możesz zrzucić strukturę danych AllTransferPacketsList, którą otrzymałeś od PrivateFdoData.
Chodzi o to, że śledzisz, co kierowca robił, co zrobił z IRP podczas ostatniej wizyty. Jeśli IRP zbyt długo AWOL, jest przekroczony limit czasu i ponawiane od początku. Przyczyną może być tak wiele rzeczy ... nawet zbłąkany promień kosmiczny. Ale ważne jest to, że transakcja zostanie ponowiona od początku i nie zostanie uznana za zakończoną, dopóki menedżer IO nie powie, że jest.
Aha, jest też niezależne od wątku IO, które jest zupełnie inną puszką robaków. :)
Do dalszej lektury na ten temat bardzo polecam rozdział 8, System I / O, Windows Wewnętrzne wydanie 6, Mark Russinovich, Margosis i in.
** Edycja: ** W końcu znalazłem oficjalną KB dla tego błędu: http://support.microsoft.com/kb/2819485/PL
Operację We / Wy należy ponowić 8 razy, raz na minutę, aż system Windows się podda.
Edycja: zgodnie z obietnicą: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx