Nein, das bedeutet nicht, dass die Daten verloren gegangen sind. Es bedeutet einfach, dass das Zeitlimit für das IRP (IO Request Packet) abgelaufen ist, während das IO-System auf den Abschluss gewartet hat, und dass es erneut versucht wurde. Wenn ein Thread eine E / A-Operation startet, erstellt der E / A-Manager einen IRP, der die Operation darstellt, die das System durchläuft.
Das IRP wird im Ausgangszustand in einer Puffer- / Look-Aside-Liste gespeichert, sodass es erneut versucht werden kann, wenn es das erste Mal fehlschlägt. Dies bietet die Atomizität, die man von jedem Transaktionssystem erwarten würde, sodass wir sicherer sein können, dass Sie nicht eine Reihe von beschädigten oder unvollständigen Daten auf Ihre Festplatte schreiben.
Dieses Ereignis ist im Falle eines MPIO-Ausfalls absolut sinnvoll. Angenommen, Windows liest oder schreibt etwas aus dem SAN-Speicher. Die Anfrage wird versandt, und im selben Moment schneide ich eines der Kabel zum SAN. Diese Anforderung wird niemals abgeschlossen, und Windows versucht die Anforderung erneut. Diesmal folgt die Anforderung jedoch dem anderen Pfad.
Diese Ereignisse treten auch auf, wenn die Festplatten überlastet oder nur sehr langsam sind. Möglicherweise stellen Sie fest, dass diese Meldungen mit geplanten Sicherungen usw. übereinstimmen. Die Festplatte ist möglicherweise nur langsam und ausgelastet, und bei einigen zufälligen IRP-Ereignissen ist eine Zeitüberschreitung aufgetreten. Sie mussten es erneut versuchen. Das IRP könnte in einer Interrupt-Serviceroutine oder einem verzögerten Prozeduraufruf oder was auch immer hängen bleiben.
Ich konnte feststellen, dass viele IO-Filtertreiber in Ihrem Stack dieses Problem ebenfalls verschlimmern.
Es ist nicht so, dass dieses Verhalten in früheren Versionen von Windows nicht so aufgetreten ist, es ist nur so, dass Microsoft anscheinend beschlossen hat, diese Ereignisse in Win8 / Server 2012 zu melden.
Bearbeiten: Sie können die ausstehenden IRPs eines Threads mit einem Kernel-Debugger suchen: kd> !irp 1a2b3c4dWo Sie zuvor diese Adresse gefunden haben, indem Sie den Befehl ausgeben, der kd> !process 8f7d6c4aalle IRPs auflistet, die den diesem Prozess zugeordneten Threads zugeordnet sind. kd> !process 0 0um alle laufenden Prozesse aufzulisten.
Sobald Sie die Informationen zu einem IRP mit dem Befehl! Irp aufgelistet haben, können Sie leicht erkennen, welcher Treiber das IRP zuletzt verarbeitet hat, da >in der Liste ein Verweis darauf angezeigt wird . Um weitere Informationen darüber zu erhalten, was dieser Treiber mit diesem IRP getan hat, führen Sie einen Befehl aus, kd> !devobj 1a2b3c4d5e6fbei dem es sich um die tatsächliche Adresse des Geräteobjekts handelt.
Dann hat eine kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAStruktur mit der Adresse der PrivateFdoData Sie.
Jetzt können Sie die von PrivateFdoData gelieferte Datenstruktur von "Vollständiger TransferPacketsList" sichern.
Die Idee ist, dass Sie aufspüren, welcher Treiber was mit dem IRP getan hat, als es das letzte Mal gesehen wurde. Wenn das IRP zu lange AWOL ist, tritt eine Zeitüberschreitung auf und es wird von Anfang an ein neuer Versuch unternommen. Dies kann durch so viele Dinge verursacht werden ... sogar durch einen kosmischen Streustrahl. Wichtig ist jedoch, dass die Transaktion von Anfang an wiederholt wird und erst dann als abgeschlossen betrachtet wird, wenn der E / A-Manager dies bestätigt.
Oh, und es gibt auch thread-agnostische E / A, bei denen es sich um eine völlig andere Dose von Würmern handelt. :)
Für weitere Informationen zu diesem Thema empfehle ich dringend Kapitel 8, I / O-System, der 6. Ausgabe von Windows Internals von Mark Russinovich, Margosis, et al.
** Edit: ** Ich habe endlich die offizielle KB für diesen Fehler gefunden: http://support.microsoft.com/kb/2819485/EN-US
Der E / A-Vorgang sollte achtmal pro Minute wiederholt werden, bis Windows aufgibt.
Bearbeiten: Wie versprochen: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx