更新が失敗した Windows Update はスリープ中でも再試行されるらしい ・・・。
前回は、スリープ中のノート PC（Dynabook）がかなり熱くなって驚いた話を書いた。
その時は nacl64.exe の CPU パワー消費量の大きさが強く印象に残ったものだから、書いているあいだ中ずっと、その親プロセスの Google Chrome （Chrome）が Dynabook の睡眠を破っているんじゃないか、という疑念が頭を離れなかった。
しかし、もし勘違いで Chrome に責任を押し付けてしまったのならば Chrome に申し訳ないので、記事をアップした直後から、Chrome を終了せずにスリープを開始して、Windows のツールの Process Monitor（プロセスモニター）とイベントビューアーを使って観察を続けている。
すると先日、スリープを中断したのは Windows Update であって、Chrome が動き出したのはその結果だったことをうかがわせる観察結果を得たので、今回はその件について書くことにする。
観測の結果：
観察日付：2015 年 11 月 23 日
使用ノート PC： dynabook T552/58GKD（Windows 8.1）
- 12 時 50 分頃スリープ開始。
- スリープ開始から約 2 時間後、BITS 開始によりスリープが中断される。
- BITS のプロパティが手動に変更され、引き続き更新ファイルのダウンロードと Windows Update が実行された。
- スリープが中断されると同時に、Chrome や Norton Internet Security などの他のプロセスも活動を再開。
- Windows Update 終了（39 件の失敗）。
- 引き続き BITS のプロパティが自動に変更され、更新ファイルのダウンロードの再試行が開始された。
- ダウンロード終了直後スリープが自動的に再開された。スリープ中断からここまで約 3 分間。
- 15 時ちょうどスリープ終了。
※カバー閉じでスリープ開始。カバー開けでスリープ終了。
※BITS ：Background Intelligent Transfer Service（バックグラウンドインテリジェント転送サービス）。
Windows Update がこんなに失敗していたとは気が付かなかった。
スリープ中にアップデートが開始されたことより、むしろそっちの方にビックリして Windows Update 関連のイベントを調べたところ、毎日数回にわたってこの 39 件のアップデート失敗・再試行を繰り返していたことが分かった。
当日（11 月 23 日）だけでもスリープ前に 失敗・再試行を 2 回繰り返していて、スリープ終了とほぼ同時に、またしても更新再試行 ⇒ 失敗と、中々忙しい状況だ。
39 件の失敗のうち、26 件が Windows 8 の組み込みアプリ（Windows アプリ）の更新失敗だったことは確認できたが、残りの 13 件についてはまだ確認していない。でもシステムの重要な更新じゃないことは確かだ。
エラーコードは 0x80073D0A が 38 回、0x80070057 が 1 回という内訳になっていた。
自動メンテナンスの設定、タスクスケジューラ登録ソフトウエアなどの再確認：
自動メンテナンス、Windows Update、タスクスケジューラなどを確認してみたが、先の観測時間内に起動されるアップデート関連のタスクは見つけられなかった。
自動メンテナンス、Windows Update の設定：
- 自動メンテナンス実行時刻の設定は 午前 3 時（11 月 23 日の時点で） 。
- 項目 [スケジュールされたメンテナンスによるコンピューターのスリープ解除を許可する] のチェックは OFF 。
- Windows Update の設定は自動インストール。同時に Microsoft Update も実行するようになっている。
タスクスケジューラ登録ソフトウエアの状況：
- タスクスケジューラに当該時間内に起動予定のソフトウエアの登録なし。
この場合の有効な対策とは・・・：
スリープを中断させた Windows Update（※） がスケジュールにより起動されたものじゃないことは分かった。
更新が失敗した場合には、該当する更新のダウンロードとインストールが再試行されることも分かったが、そのルールが分からない・・・。
有効な対策ということになると、それは Windows アプリや他のプリインストールソフトウエアの更新を成功させるしかないということになるのだが、実はこれが、色々やってみて全部失敗という情けなさなのだ。
なので、今は Windows Update の設定で Microsoft Update を自動実行しないようにして観測を続けている。
この件はもう少し調べるつもりだが、対策と言えるような成果が得られるかどうかは分からない。何となく PC をリフレッシュするしか手段は残されていないような気がする。
あたりまえだが、Microsoft Update の自動実行を停止すると Windows アプリ等の更新の失敗は発生しない。
スリープ中の更新再試行はこれで完全に回避できるので「スリープ中の PC が過熱する」という現象に限って言えば、これは立派な対策と言えなくもない。
※厳密に言えば、いっしょに実行された Microsoft Update の方。
観測に使ったツール：
2 種類の Windows ツール：
- イベントビューアー
- プロセスモニター
※イベントビューアーは Windows の標準付属ツールだが、プロセスモニターは専用サイトからダウンロードする必要がある。ダウンロード先は前回の記事を参考にして頂きたい。
※プロセスモニターの詳細な使い方を知りたい人は、次の参考サイトを訪問されると良い。私も一読して、ものすごく精緻な説明を展開されているのに驚いた。強くお勧めする。
参考サイト：
観測の手順：
スリープ開始：
- 1）プロセスモニターを起動する。
- 2）[Process Monitor のフィルタ] ダイアログを表示して、不要なフィルタを使用不能に設定 / 削除するか、またはすべてのフィルタをリセットする。
- 3）PC のスリープを開始する。
スリープ終了：
- 4）PC のスリープを終了する。
- 5）プロセスモニターのイベントキャプチャーを停止する。
- 6）イベントビューアーでスリープ開始時刻と終了時刻を取得する。
- 7）[Process Monitor のフィルタ] ダイアログの [これらの条件に一致する項目を表示] ドロップダウンで [日付と時刻（&）] を選択する。
- 8）スリープ開始 / 終了時刻を使ってフィルタを設定する。
- 9）結果を保存する。
プロセスモニターの日付によるフィルタリング（参考）：
プロセスモニターの項目 [日付と時刻（&）] の値を使って、キャプチャーしたイベントに時間帯のフィルターをかけるのだが、ちょっと勘違いしやすいので注意が必要だ。
- 時間帯の設定
実際にイベントビューアーで取得したスリープ開始 / 終了時刻は次のとおり。
- 開始時刻：2015/11/23 12:49:33
- 終了時刻：2015/11/23 15:00:32
するとフィルターの設定は次のようになる。
- フィルターの設定
フィルター対象項目：[日付と時刻（&）]：
- [more than] 2015/11/23 12:49:32.9999999 なら [Include]
- [more than] 2015/11/23 15:00:33.0000000 なら [Exclude]
※間違いがあったので 2 段目の [Exclude] 項目の時刻を訂正した（2015/12/22）。
私は最初、終了時刻の [Exclude] のところを [less than] … [include] とやってしまった。
これは SQL の「Between 開始時刻 And 終了時刻」のつもりなワケだが、実際にやってみると分かるが、それだとキャプチャー開始から終了までのすべてのイベントが表示されてしまう (^^;)。
プロセスモニターとイベントビューアーについては、もう少し丁寧（ていねい）な説明が必要と思うので、それは近日中に項を改めて書くことにしたい。