Windows Updateが動作していて、フォアグラウンドの作業が重く、しかもWindows Updateがなかなか進まない状況に遭遇したことはありませんか。画面をただ眺めているだけでは、進んでいるのか、いないのかが分からず、結局失敗して時間の無駄に終わるということも……。他にすることがなく、時間を持て余しているのなら、進んでいることが分かる詳細を追跡してはいかがでしょうか(本稿の最後に注意点というかオチがあります)。
今回は、2017年6月に書いた以下の記事のアップデート版です。以下の記事では、Windows Sysinternalsの「Process Monitor(Procmon)」ツールを使用して、Windows Updateによる「品質更新プログラム」のインストール実行中のアクティビティーを調査し、その処理プロセス(過程)を筆者なりに想像して、大量のディスクI/Oが行われている実態を見える化しました。
今回はそれを補足する、別のモニター方法を紹介します。なお、Windows 10 April 2018 Update(バージョン1803)のような「機能更新プログラム」を対象にしたものではありません。Windows 10で「設定」アプリの「更新とセキュリティ」にある「Windows Update」では、更新プログラムを手動でチェック、利用可能な更新プログラムが見つかった場合は、ダウンロードやインストールの進行状況を見ながら更新を進めることができます。
しかし、ダウンロードの準備中、ダウンロード中、インストールの準備中、インストール中のパーセンテージが増えるのを見ているだけでは、手持ち無沙汰です。時には、まるで止まっているかのように進行が遅いこともあります。何らかの問題が発生していて、実際に止まっていることもあるかもしれませんが、ほとんどの場合は、恐らく何らかの処理が進行中です。数時間、あるいは半日といった長い時間、ただ眺めているだけでは、他にすることがなかったとしても、時間の無駄です。
また、更新を完了するために再起動が要求される場合、「設定」アプリで監視できるのは“再起動を開始するところまで”です。この後の進捗(しんちょく)状況は、コンソール画面に表示される「Windowsの準備をしています コンピューターの電源を切らないでください」「更新プログラムを構成しています XX% 完了 コンピューターの電源を切らないでください」という表示で把握できますが、なかなか進まないと「本当は止まっているんじゃないのか」「電源を切るしかないのか」と不安はどんどん増していきます。順調に進んでいるように見えて、最後の最後に「更新プログラムを構成できませんでした 変更を元に戻しています」なんて表示されるかもしれません。
皆さん、Windowsのパフォーマンスが気になるときには、「タスクマネージャー」の「パフォーマンス」タブを開いて状況を確認することがあると思います。このタブ表示の下方に「リソースモニターを開く」というリンクがあるのに気が付いていますか(画面1)。
タスクマネージャーの「プロセス」タブや「詳細」タブでは、CPU、メモリ、ディスク、ネットワークの使用率の高いプロセスを識別することができますが、そのトレンドは分かりません。一方、「パフォーマンス」タブはコンピュータ全体の情報を示すものであり、細かいところまで分かりません。
「リソースモニター」を使用すると、プロセス一覧とグラフ表示を同時に参照しながら調べることができ、フィルター条件を設定して詳細なアクティビティーをモニターすることができます。
例えば、Windows Updateを実行中にリソースモニターの「ディスク」タブを開き、ディスクへの読み取り/書き込み操作の激しいプロセスを調べると、「System」(システムプロセス)、「svchost.exe(netsvcs)」(netsvcグループの複数のサービスをホストするプロセス)、「TiWorker.exe」(Windows Modules Installer Workerプロセス)といったプロセスが見つかるはずです。これらのプロセスを選択してフィルタリングすると、次のような場所に対する読み取り、または書き込み操作が大量に行われている様子が分かるでしょう(画面2)。
ディスク性能が低い場合はこれらのI/Oによって、ディスクのアクティブ時間が100%になり、キューがたまった状態が続いて、Windows Updateがなかなか進まないという状況が考えられます。もし、同じような場所に対して、マルウェア対策ソフトウェアのリアルタイム保護プロセス(Windows 10標準のWindows Defenderを使用している場合は「MsMpEng.exe」)が大量のI/Oを行っている場合は、リアルタイム保護を一時的に停止する、あるいは「C:\Windows\SoftwareDistribution」や「C:\Windows\WinSxS」ディレクトリを除外対象に設定することで、ディスクI/O性能を改善できるかもしれません。
リソースモニターの「ネットワーク」タブに切り替えると、アクティブなネットワーク接続や送受信量を、プロセスでフィルタリングして参照できます。Windows Updateの進行状況が「ダウンロード中 XX%」だったとしても、実はディスクI/Oの方に時間を取られていて、ダウンロードがほとんど行われていないという時間帯もあります(画面3)。
Windows Updateのダウンロードには「svchost.exe(netsvcs)」が関わっています。プロセスIDを調べることで、このプロセスが「Windows Update(wuauserv)」「UsoSvc(Update Orchestrator Service)」「BITS(Background Intelligent Transfer Service)」「DoSvc(Delivery Optimization)」をホストしているものと分かるはずです(画面4)。
リソースモニターでWindows Updateのアクティビティーを参照して見慣れてくれば、後どれくらいで完了するか予想がつくかもしれません。例えば、「C:\Windows\Software\Download」ディレクトリのサブディレクトリ内で、大量のファイルがアルファベット順に処理されている様子が見えたりします。「設定」アプリでは更新プログラムのダウンロードが進行中になっているのに、ダウンロードではなくインストールが進んでいるのを見たことがあります(2018年6月、Windows 10 バージョン1703でのこと。このときは失敗後、再試行で成功)。
「設定」アプリではWindows Updateが進行中の表示なのに、リソースモニターでは具体的なディスクI/OやネットワークI/Oが全く見られないという場合、何らかの障害でストップしている可能性があります。その場合は、Windowsを再起動したり、「SoftwareDistribution」ディレクトリをリセットしたりすることで、解消する場合があります。「SoftwareDistribution」ディレクトリのリセットについては、本連載第96回を参考にしてください。
Windows Updateでは、更新プログラムで更新された新しいバージョンのバイナリファイルが「C:\Windows\WinSxS」ディレクトリにコピーされます。例えば、「C:\Windows\System32」ディレクトリ内のシステムファイルは更新で直接書き換えられることはなく、「C:\Windows\WinSxS」ディレクトリ内にある最新バージョンのシステムファイルに対するハードリンクの付け替えで行われます。
コマンドプロンプトで次のコマンドラインを実行してみてください。「fsutil hardlink list」は、ファイルに存在するハードリンクを列挙します。その結果、「C:\Windows\System32\ntdll.dll」とは別の存在を「C:\Windows\WinSxS」ディレクトリ内に確認できるでしょう。
fsutil hardlink list c:\windows\system32\ntdll.dll
「C:\Windows\WinSxS」ディレクトリのパスを前方一致で参照してみると、複数バージョンの「ntdll.dll」が見つかります。現在の「C:\Windows\System32\ntdll.dll」は、存在する最新の「ntdll.dll(10.0.16299.402)」を参照していることが分かります(画面5)。「C:\Windows\SxS」ディレクトリに複数のバージョンが存在する理由は、更新プログラムのアンインストールでロールバックできるようにするためです。
なお、ハードリンクとは、ローカルボリューム上の単一のファイルに対する複数のパスのことです。複数のパスがあったとしても、ファイルの実体は1つであり、ディスク領域を余計に消費するものではありません。また、最初に作成されたパスでファイルが配置されるわけですが、複数のハードリンクが作成されている場合、パスが作成された順番に関係なく、どれが本物というわけでもありません。そのファイルを参照する全てのハードリンクが削除されると、そのファイルはボリューム上から削除されます。
更新を完了するために再起動が要求される場合(累積的な品質更新プログラムの場合は必須)、ハードリンクの付け替えは再起動時に行われます。その進行状況を示すものはローカルコンソールの出力しかありません。しかし、Procmonのブートログ機能を利用することで、再起動後の起動直後から、Windowsが起動してユーザーがログの記録を停止するまでのイベントをトレースすることが可能です。
それには、Windows Updateによる再起動の前にProcmonを開き(「/noconnect」オプションを付けると、現在のアクティビティーのイベント収集を開始しないで開くことができます)、「Options」メニューから「Enable Boot Logging」を選択します(画面6)。その後、Procmonは終了して構いません。Procmonは、イベントを収集するためのカーネルモードドライバを次回起動時に早い段階で開始するようにシステムに仕込みます。
Windows Updateによる再起動が完了し、ログオンしたら、Procmonを開始します。すると、収集されたブートログを保存するように求められるので、パスを指定して保存します。このとき、Procmonで参照可能な形式(.PML)に変換する処理にしばらく時間がかかります。また、大量のログが変換、記録されるため、ログのファイルサイズも大きくなることに注意してください。
ログの変換が完了すると、Procmonのウィンドウにシステム起動直後からの大量のイベントが表示されます。あまりにも大量なので、Procmonの通常のフィルター機能を使っても、解析するのは至難の業です。
そんなときは、プロセスツリー機能を利用すると便利です。「Tools」メニューから「Process Tree」を選択すると、システム起動時から作成されたさまざまなプロセス一覧と、親子関係、プロセスの開始から終了(または継続中)を時間軸で参照できます。システム起動の中ほどから始まり、最後の方まで続く「TiWorker.exe」(プロセスID 4936)が、Windows Updateの処理に関係していることは、誰でも直感的に分かるでしょう(画面7)。
このプロセスを選択して「Include Subtree」ボタンをクリックすると、このプロセスとさらにその子プロセスを含むフィルターを自動設定できます。その結果、「C:\Windows\WinSxS」ディレクトリの下に対するアクティビティーを参照することができます(画面8)。詳細な解析は、時間のある方にお任せします。
今回紹介したモニター方法は、筆者がWindows Updateによる“品質更新プログラム”のインストールトラブルに遭遇した際、たびたび利用してきました。全く動いていなかったということを発見したことはありますが、これで特定の問題を発見したことはありません。
しかしながら、「止まっているんじゃないか」というWindows Updateの処理が、確かに進んでいるのが分かることで、安心できるのではないでしょうか。なお、リソースモニターやProcmonのブートログ機能を使用すると、これら自身が使用するリソース(CPU、メモリ、ディスク)の影響で、ただでさえなかなか進まないWindows Updateが、さらにスローダウンすることは大いにあり得ます。
岩手県花巻市在住。Microsoft MVP:Cloud and Datacenter Management(Oct 2008 - Sep 2016)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows Server 2016テクノロジ入門-完全版』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.
Server & Storage 記事ランキング