Windows 8.1でアップデートの検索が完了しない問題――公式ツールが効かないときの解決策

最近、奇妙な問題に悩まされています。これまでのWindows関連記事をお読みの方ならご存じかもしれませんが、比較的新しいLenovo Ideapad Y50-70ノートPCでWindows Update（WU）機能に不具合が発生し、システムイメージを古い状態へ完全復元する羽目になりました。これ自体も貴重な教訓となりました。ただ、その復元作業ではUEFI・ATI・Windows 8.1の組み合わせによる大きな壁にも直面しましたが、こちらはなんとか乗り越えることができました。

ところが、その出来事から数週間後、ノートPCが騒がしくなっていることに気づきました。CPUファンが過剰に稼働していたのです。理由はありました。プロセッサの使用率は約13%、つまり論理スレッド1本分がほぼ占有されており、その正体はWUサービスも制御しているsvchost.exeプロセスだったのです。また更新処理がこけているのだと悟りました。実際、Windows 8.1はどれだけ待ってもアップデートの検索を完了しなくなっていました。何としても直す必要がありました。

問題の詳細

症状はシンプルです。Windows 8.1がアップデートをチェックするものの、永遠に完了せず、システムは高いCPU使用率のままビジー状態が続きます。つまり更新プログラムをインストールできず、この機能を重視するユーザーなら行き詰まりを感じ、不安になるかもしれません。

私の場合、問題は2016年5月の更新サイクルと、その後のロールアップ更新パッチ公開の間のどこかの時点で発生しました。それ以降、新しいドライバーの導入やハードウェアの追加はしていません。推測するに、Windows Updateが必要なパッチの一つを見失い、見つけられないままループにはまり込んでいるのだと思われます。どこかの更新サイクルで、重要なデータが何らかの理由で欠落してしまったのでしょう。あくまで仮説ですが。

ログには明白なエラーはほとんどありません。ただ一つを除いて――以下のエラーはあなたのケースとは直接関係ないかもしれませんが、この記事を読んでいるということは、ここで記録した情報の一部が参考になっている可能性があります。

Windows Store failed to sync machine licenses. Result code 0x80070002

このエラーの意味をネットで調べると、情報はジャングルのように乱雑でした。提案や選択肢を一つずつ丁寧に確認していく必要があります。興味があれば、WUのエラーコード一覧を参照したり、自分のエラーコードを検索したりできます。ただし数百件の結果が出てきて、そのどれもがあなたのケースとは異なるはずです。

解決策の模索――公式の手法はどれも効果なし

おそらくこの話全体で最も皮肉な部分です。ネット上の情報を片っ端から読み込みました。インターネットは6つほどの手がかりを提示してくれました――その大半はMicrosoft公式の提案やツールでしたが、どれも問題を解決できませんでした。このガイドの網羅性のため、まずすべて紹介し、その上で実際に効果のあった方法に焦点を当てます。繰り返しますが、以前のイメージへの復元やバックアップからの戻しの話ではありません。真の原因を突き止めて解決することが重要です。古い時点のスナップショットに戻っても数日後にはまた壊れるのでは、時間の無駄でしかありませんから。

トラブルシューターの使用

Windows 7以降には便利なトラブルシューティングウィザードが標準搭載されており、自動的な手順で問題の修復を試みられます。初心者ユーザーや、システム内部を深く掘り下げたくない人には手軽なソリューションです。

トラブルシューターはエラー0x80070490を発見して修復したと報告しました。イベントログに記録されていたコードとは別のものです。更新履歴も完全にリセットされましたが、それは問題ありません。WUは必要に応じてインデックスを再構築します。しかし、これでも問題は解決しませんでした。

DISMの実行

次に試したのは、展開イメージのサービスと管理（DISM）ツールです。このユーティリティはプロフェッショナルやシステム管理者向けに設計されており、Windowsに組み込まれているため追加インストールは不要です。公式の手順では以下のコマンドが案内されています。

C:\windows\system32>DISM.exe /Online /Cleanup-image /Restorehealth

DISMをしばらく実行すると完了し、「エラーを修復した」と主張しました。しかし実際には何も修復されていませんでした。

C:\windows\system32>DISM.exe /Online /Cleanup-image /Restorehealth

Deployment Image Servicing and Management tool
Version: 6.3.9600.17031

Image Version: 6.3.9600.17031

[==========================100.0%==========================]
The restore operation completed successfully. The component store corruption was repaired.

The operation completed successfully.

C:\windows\system32>

Windows Updateエラー修正ウィザード

オンラインの対話型ウィザードから利用できる最新のWU診断ツールも試しました。トラブルシューターとよく似たツールですが、実際にはるかに徹底的な診断を行い、さらに多くのエラーを検出したようでした。なお、エラーコードは常に変動していました。また0x80244019が時折現れましたが、これは単にWUサービスが停止していたためで、サービスを開始すれば解消されるものでした。

しかし、診断ユーティリティが「修復した」とする多数の項目にもかかわらず、状況は一切変わりませんでした。途中での再起動の有無にかかわらずWUは固まったまま、CPU使用率は12〜13%の水準を維持し続けました。

PowerShell PSWindowsUpdateモジュール

公式のPSWindowsUpdateモジュールも試しました。PowerShell経由で更新を取得し、コア機能の内在的な問題を回避できるはずのツールです。かなり魅力的に思えました。Kapil Arya氏による非常に実用的なWUエラー対策ガイドの手順に従いましたが、残念ながら前進はありませんでした。なお、そのチュートリアルはやや異なる種類の問題を扱っている点にも留意が必要です。

Set ExecutionPolicy RemoteSigned
Import-Module PSWindowsUpdate
Get-WUInstall

単体パッチ KB3138615

単体配布のWUパッチKB3138615も試しました。直接ダウンロードはできず、Microsoft Update Catalogを経由する必要がありましたが、それは特に問題ありません。パッチは正常に実行・インストールされましたが、それでも更新を取得することはできませんでした。

その他の試み

DEP設定の変更も試しました――正直なところ意味がなく、ネット上の記事で根拠なく繰り返されるオカルト的な対処法に思えます。当然ながら効果はありませんでしたが、徹底を期すために確認しました。

試さなかった唯一の手段は、WUコンポーネントの手動リセットです。これは長時間かかる骨の折れる作業で、事態を悪化させるリスクもあります。しかも、こうした操作はすべてスクリプト化可能であり、本来ならトラブルシューターや診断ツールに組み込まれているべきものです。おそらく実際に組み込まれています。よって却下しました。

実際に効果のあった解決策：Autopatcher

ついに、非公式ツールを使ってWUの修復を試みることにしました。かなり思い切った手段です。システム管理にサードパーティ製ユーティリティを推奨したり信頼したりすることは、普段の私ならありません。しかし今回は失うものが何もなかったため、試してみることにしました。Autopatcherとの付き合いは以前からありました。Windows 7の更新が異常に遅い問題を回避するために使おうとしたことがあり、その後、2016年夏にMicrosoftが正式な修正をリリースするまでのつなぎとして活用していたのです。

Autopatcherをダウンロードし、重要・任意を問わずすべてのWindows Updateを取得させると、合計2.1GBものデータになりました。まず、実際にいくつかインストールできるかテストしました。1月のAdobe Flash Player修正など数件を試したところ、正常に動作し、以降の起動では適用済みのホットフィックスがリストから確かに除外されていました。

驚いたのは、2014〜2015年の古い修正プログラムが大量にリストアップされたことです。Windowsはこれらをインストールしておらず、インストールが必要とも認識せず、提供すらしていなかったはずのものです。すべてインストールすることに決めました。Autopatcherは問題なく処理を完了しました。再起動後も一部はリストに残っていましたが、これは他の更新に置き換えられたためと思われます。何より重要なのは、Windows Updateが再び正常に動作するようになったことです！Autopatcherが実行・適用しようとした内容が、システムを苛んでいたループをついに解消したに違いありません。欠落していたホットフィックスが適用されたか、破損したライブラリが置き換えられ、サービスが通常業務を再開できたのでしょう。馬鹿げた話に聞こえますが、古い更新をすべて適用することが実際に奏功したのです。

別のマシンでも同じ問題が発生

この記事を執筆中、公開直前に、全く同じ症状の同一問題がAsus Vivobookでも発生しました。そこで同じ手法を用い、Autopatcherで確実に問題を解決できました。

厄介なことに、この問題は繰り返し再発します――WUはしばらくすると、システム更新の検索を勝手に止めてしまうのです。幸い、複数回にわたり、まったく異なる2台のシステムでAutopatcherが安定した良好な結果をもたらしてくれました。実行して任意の更新をインストールするだけで、その後はシステムが通常の高速なWU動作を取り戻します。

このことから分かるのは、ここで起きている現象がWindows 8.1固有の問題だということです。この半ば自動化されたOSの評価が良くなるわけでも、Windows 10へアップグレードする動機になるわけでもありません。むしろ逆です。陰謀論的な憶測はさておき、ベンダーが自社の主力製品の重要コンポーネントにおける根本的な問題を解決できない、あるいは解決する意思がないのであれば、今後のリリースを使う気にはなれません。

同じ問題に直面している方へのアドバイス――問題が消えることを期待してOSをアップグレードしないでください。消えるかもしれませんが、それは回避策であって解決策ではありません。私の手法もある意味ではハックですが、WU機能を本来あるべき姿で取り戻せる点は優れています。とにかく、2台の異なるWindows 8.1マシン、異なるハードウェア、異なるベンダー、さらには異なるソフトウェア構成で、同じ問題が発生しました。これは純粋なOS側の問題です。焦る必要も、自分を責める必要もありません。Autopatcherでグリッチを修正し、通常の運用を再開してください。信頼性が高く安全で、過去5〜6ヶ月間に10回以上テスト済みの手法です。非常に有効です。

まとめ

今回行った対応を誇りに思うわけではありません。しかし、公式ツールのどれ一つとして有用な働きをせず、結局はサードパーティ製ソフトによる強引なアプローチがループの突破に成功したというのは、実におかしな話です。システムの再インストールで直った可能性もありますが、疑わしいところです。そもそも以前のイメージへの復元は一時的な効果しかなく、システムを狂わせていたのは別の要因だったはずです。

全体として、AutopatcherやWSUS Offlineが正攻法だとは思いません。しかし、どうしても必要なら、更新が一切入らないシステムや壊れたWUを抱えたシステムよりははるかにましでしょう。それでも、多くのことを学べました。各種エラーへの対処法、複数のトラブルシューティングツールの使い方、PowerShellの小技、その他の細かな知識、そして予想外にもAutopatcherによる「全適用」で解決するという展開。まさに物語のどんでん返しです。

同様の問題に遭遇した場合は、まず簡単な対処から始め、徐々に大掛かりな変更へと進んでください。まず公式ユーティリティを試し、それでも改善しなければAutopatcherを検討しましょう。結果には満足しており、たとえ本来あるべき挙動ではないにせよ、このプログラムへの信頼は深まりました。更新の適用を求めたのに、結果的にWindows Updateそのものを修理してしまったのです。この一件全体の詩的なパラドックスがお分かりでしょうか？ここ数年のWindows 7や8.1の問題群を見ていると、Microsoftにはこの極めて重要な機能にもっと注力してほしいと切に願います。本チュートリアルが、あなたの正気を取り戻す一助となることを願っています。それでは、また。