回答:
いいえ、データが失われたという意味ではありません。これは、IOシステムが完了するのを待っている間にIRP（IO要求パケット）がタイムアウトしたことを意味し、再試行されました。スレッドがIO操作を開始すると、IOマネージャーは、システムを通過する操作を表すIRPを作成します。
IRPは初期状態でバッファ/ルックアサイドリストに保存されるため、最初に失敗した場合に再試行できます。これは、トランザクションシステムに期待される原子性を提供するため、ディスクに書き込まれた破損したデータや不完全なデータを大量に取得することはないと確信できます。
このイベントは、MPIOに障害が発生した場合に最適です。WindowsがSANストレージから何かを読み書きするとします。要求がディスパッチされ、同時に、SANへのケーブルの1つが切断されました。その要求は決して完了しないため、Windowsは要求を再試行しますが、今回は他のパスをたどります。
これらのイベントは、ディスクが過負荷になっている場合や、本当に遅い場合にも発生します。これらのメッセージは、スケジュールされたバックアップなどと一致する場合があります。ディスクが遅くてビジーであり、ランダムなIRPがタイムアウトになり、再試行する必要がありました。IRPは、割り込みサービスルーチン、遅延プロシージャコールなどでスタックしている可能性があります。
スタック内に多数のIOフィルタードライバーがあることも、この問題を悪化させていることがわかりました。
この動作が以前のバージョンのWindowsでこのように発生したわけではなく、MicrosoftがWin8 / Server 2012でこれらのイベントを明らかにすることを明らかにしただけです。
編集：カーネルデバッガーでスレッドの未処理のIRPを見つけることができます：kd> !irp 1a2b3c4d、kd> !process 8f7d6c4aそのプロセスに関連付けられたスレッドに関連付けられたすべてのIRPを一覧表示するコマンドを発行することにより、以前にそのアドレスを見つけました。kd> !process 0 0実行中のすべてのプロセスをリストします。
！irpコマンドを使用してIRPに関する情報を一覧表示する>と、リスト内でそれを指し示すため、IRPを最後に処理したドライバーを簡単に見つけることができます。次に、そのドライバーがそのIRPで行っていたことに関する詳細情報を取得kd> !devobj 1a2b3c4d5e6fするには、それがデバイスオブジェクトの実際のアドレスである場所を実行します。
次に、kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA取得したPrivateFdoData構造体のアドレスを使用してを実行します。
これで、PrivateFdoDataから取得したAllTransferPacketsListデータ構造をダンプする準備ができました。
アイデアは、あなたが最後に見たときにIRPで何をしていたのかを追跡しているということです。IRPが長すぎる場合、タイムアウトになり、最初から再試行されます。これは非常に多くのものによって引き起こされる可能性があります...迷い宇宙線ですら。しかし重要なことは、トランザクションが最初から再試行されることであり、IOマネージャーがそうするまで完了したとは見なされません。
また、スレッドに依存しないIOもありますが、これはまったく異なるワームです。:)
このトピックの詳細については、Mark Russinovich、MargosisなどのWindows Internals 6th editionの第8章I / Oシステムを強くお勧めします。
**編集：**最終的にこのエラーの公式KBを見つけました：http : //support.microsoft.com/kb/2819485/EN-US
IO操作は、Windowsが停止するまで、1分間に1回、8回再試行する必要があります。
編集：約束どおり：http : //blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
いいえ、別のメッセージが表示されます。データを正常に保存できなかった場合、アプリケーションレイヤーの1つが例外をスローします。
Windows Server 2012（またはWindows Server 2008 R2の場合は修正プログラム2819485）より前は、システムはこれらのタイムアウトが発生したときに静かに再試行しました。メッセージの目的は、これらの発生に関する可視性を高めることです。これらは容量の問題またはドライバーの欠陥を示している可能性があり、iSCSIの場合、他のオペレーティングシステムの欠陥は遅延に起因する可能性があります。
外部（直接接続されていない）ストレージの場合、過去の一部のベンダーはタイムアウト値を、たとえば60秒に増やしました。ただし、iSCSIイニシエーターなどの上位層コンポーネントによるデフォルトの再試行回数を考えると、システムがフェイルオーバーを開始するまでに数分かかることがあります。それは明らかに準最適な動作です。
詳しくは：
SCSIミニポートドライバーのレジストリエントリ
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
Microsoftは、storport.sys操作のしきい値を指定する機能を提供する更新プログラムをリリースしました。
この更新プログラムをインストールした後、ストレージへのI / Oの待ち時間がしきい値以上になったときにイベントをログに記録できます。しきい値はユーザーが設定できます。この操作は、アダプタードライバーレベルで実行されるため、SANにパフォーマンスの問題があるかどうかを確認できます。その後、ストレージベンダーに連絡して問題を解決できます。
注：この更新プログラムは、Windows 7およびWindows Server 2008 R2で提供されていた機能を復元します。この機能を有効にすると、しきい値は100ナノ秒（0.0001ミリ秒）で測定されます。さらに、次の値がイベントに記録されます。
BuildIoDuration：MINIPORTがこのリクエストのビルドI / O機能に 費やした時間の長さStartIoDuration：MINIPORTがこのリクエストのI / O機能の開始に費やした時間の長さ DataTransferLength：バイト単位の転送サイズ
Windows Server 2012のStorport.sysドライバーのログ機能を改善する更新プログラム
http://support.microsoft.com/kb/2819476
Windows 8およびWindows Server 2012の累積的な更新：2013年4月
http://support.microsoft.com/kb/2822241