ほっとしたのもつかの間、12月の月次更新プログラムのWindowsUpdateが自動実行されましたが、なぜかインストール後の更新プログラムを構成で7%まで進行した後、リブートを経て「更新プログラムを構成できませんでした」となりました。エラーコードは、"0xE0000100" でした。PowerShellで"Get-WindowsUpdateLog" を実行して"WindowsUpdate.log" を抽出して確認しましたが、原因につながる詳細なログは、残っていませんでした。
世の中の事例を調べてはみましたが解決策は見つかりませんでしたので、まずは、WindowsUpdateカタログから個別の更新プログラム（kb4592438で検索）をダウンロードし、単独実行して、ログの採取を試みました。ログは、"C:\Windows\Logs\CBS\CbsPersist_2020xxxxxxxx.log" にありました。その内容を注意深く確認したところ、下記のように、"DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]"であることがわかりました。
2020-12-14 11:19:59, Info CBS Perf: Doqe: Install started.
2020-12-14 11:19:59, Info CBS Doqe: [Forward] Installing driver updates, Count 646
2020-12-14 11:19:59, Info CBS Progress: UI message updated. Operation type: Update. Stage: 0 out of 0.
Percent progress: 7.
2020-12-14 11:20:01, Info CBS DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Doqe: Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Er
ror]
2020-12-14 11:20:01, Info CBS Perf: Doqe: Install ended.
2020-12-14 11:20:01, Info CBS Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Error CBS Shtd: Failed while processing non-critical driver operations queue. [HRES
ULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info CBS Shtd: Rolling back KTM, because drivers failed.
このエラーに関するドライバーインストールのログが無いか調べてみると、"C:\Windows\INF\setupapi.dev.log" であることがわかり内容を確認すると、下記のようにinfファイル中のsignatureに問題があるとのエラーでした。対象のファイルを確認すると先頭のバイトが壊れて、正常なinfファイルになっていませんでした。infファイルは、sfcの対象になっていないようで、"Update Sequence Array" の不整合によるfixup処理によりで先頭のバイトが破損した可能性があります。MFTの構造上、1クラスタ内に収まる小さなファイルの場合、発生しやすいと考えられます。
前記で使用したmountされているWindowsイメージから同じファイルを見つけ、前記の手順で上書き復元をしたところ、無事更新プログラムが正常に実行できました。
>>> [Install Driver Updates]
>>> Section start 2020/12/10 15:41:19.614
cmd: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.680_none_
e72768c3263f99bc\TiWorker.exe -Embedding
sto: Image State = Specialized
sto: Image Architecture = amd64
sto: Image OS Version = 10.0.19042
sto: Image Product Type = WinNT
sto: Transaction = CbsDriversAndPrimitives
sto: Driver Updates = 646
! inf: Unable to load INF: 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdca
e9b5f\kdnic.inf'(e0000100)
! inf: Error 0xe0000100: The style of the INF is different than what was requested.
!!! inf: Invalid INF 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kd
nic.inf', must contain [Version] section and have signature "$Windows NT$". Code = 1001
!!! sto: Failed to get version info for driver update 'C:\WINDOWS\System32\DriverStore\FileRepository\kd
nic.inf_amd64_6649425cdcae9b5f\kdnic.inf'. Error = 0xE0000100
<<< Section end 2020/12/10 15:41:22.020
<<< [Exit status: FAILURE(0xe0000100)]
やっとPCの不調を復旧できたようです。
同じようなWindowsUpadeトラブル事例を検索してみた感想では、ログ解析方法が明らかにされていないのか、原因の特定が難しいのか、効果があるかもしれない対策方法を列挙したり、自動修復プログラムを紹介したりすることが散見されていました。当たるも八卦当たらぬも八卦状態です。パソコンメーカーのサポートでも同じレベルでした。特に日本のマイクロソフトのサポート情報は、エラーコードに対応した対策に言及せず、うまくいった事例を紹介しているだけが多いようで、役に立たないことが多いと感じました。米国のマイクロソフトのサポート情報ほうが有用な感じでした。
WindowsUpadeトラブルは様々な要因で頻発する傾向があり、マイクロソフトがエラーコードの意味やそのエラーコードに対応した対策を公開するか、修復可能範囲を広げるDISM等の機能強化を提供してくれたら多くのユーザが助かるかと感じたのは、私だけではないと思います。マイクロソフトのサポートが大変になるので、ユーザがあまりやりたくない新規再インストールに仕向けようとしているのではと、勘繰りたくもなります。
いずれにしても、今後はバックアップを頻繁に行いたいと思います。ログの解析方法など、参考にしていただければと思います。
（再クロール更新：2022/12/22）
