セキュリティ更新プログラム (KB5012170)が0x800f0922エラーで失敗するのはセキュアブートの設定が原因かもしれません

結論から申し上げますと、私の環境ではセキュアブートをOFFからONに変更するとKB5012170のインストールに成功しました。

その後、再度セキュアブートをOFFに戻しても特に問題なく稼働しています。

結論は以上です。

以下は蛇足です。

さて、当環境では火曜日以来、今月のWindows Updateでこんな問題が発生していました。

週末なので、そろそろ解決しようと思いました。

そこで、そのエラーコード0x800f0922を引き起こしているのは何やつかと尋ねると・・・

何度も失敗していますが、それはすべてKB5012170だそうです。

KB5012170とは何者かと尋ねると・・・

KB5012170: Secure Boot DBX のセキュリティ更新プログラム: 2022 年 8 月 9 日

だそうです。

セキュアブートは当環境では無効にしてあるので、まずは有効にしてみることにしました。

そのためにはUEFIの設定を変更する必要があるため、マザーボードごとに用語や手順が異なるかと思いますが、当環境のASRock H87 Pro4を例にしますと、まずはSecure Bootはこんな状態でした。

セキュア起動とか安全起動とか楽しい日本語になっていますが、これらはすべてSecure Bootを意味しています。

上の状態を以下の状態にしてあげます。

上記の画面は、セキュアブートを有効にして、「システムモード状態」を「Setup」から「デフォルト値で初期化した状態」を示しています。

これでセキュアブートが有効になるのですが、保存して再起動する前に、もう一か所だけ確認したほうがいい箇所があります。

それは「CSM(Compatibility Supported Module)」です。CSMはセキュアブートとは「混ぜるな危険」の関係なので、ちゃんとOFFにされているか確認したほうがよいでしょう。

CSMが有効になっている場合、例えばこんな感じになります。

これを、以下のように変更します。

この状態になっていることを確認したら、設定を保存して再起動し、Windowsを起動します。

そして、さっそくWindows Updateをかけてみたところ、

となって、無事KB5012170のインストールに成功しました。

履歴を参照すると、

きちんと「正しくインストールされました」となりました。

なお、よくよく見てみると、驚いたことに、「更新の履歴を表示する」といっているくせに、失敗の履歴はすべて削除されてしまいました。

そんなの履歴じゃないじゃん。

歴史修正主義者マイクロソフトさんなのでした。

おまけ：この問題をイベントビューアで確認すると、次のように記録されています。

インストールの失敗: エラー 0x8024200B で次の更新プログラムのインストールに失敗しました: 2022-08 x64 ベース システム用 Windows 10 Version 21H1 のセキュリティ更新プログラム (KB5012170)。

エラーコードまで違ってんじゃん!!

歴史改ざん主義者マイクロソフトさんなのでした。

さて、愉快なマイクロソフトさんの歴史観はさておいて、当環境の場合は自作のデバイスドライバに私のオレオレ証明書で署名をしています。

セキュアブートの仕事は起動時のドライバやOSのデジタル署名をマイクロソフト以外に許すか許さないかなので、セキュアブートは無効に戻さなくてはなりません。

セキュアブートは一度でも有効にしてWindowsを起動すると、BCD(Boot Configuration Data。Windows Vistaからの伝統で、二進化十進数の事じゃございません)からtestsigning項目がOFFにされてしまいます。

そこで、UEFI画面でセキュアブートを無効にした後、Windowsを起動したら再度testsigning項目をONにしてあげてWindowsを再起動する必要があります。

コマンドは次の通りです。

bcdedit /set testsigning on

以上、どなた様かに役立つかもしれないと思い、記録する次第です。

このような駄文をお読みいただいてありがとうございました。

MoUsoCoreWorkerがスリープを阻害する

ここ数か月か、Windows10がWindows Updateで何かしらｼｽﾃﾑがアップデートされて以後、スリープができなくなるという現象に見舞われています。

その際、powercfg.exe /requestsを実行してみると、

C:\WINDOWS\system32>powercfg /requests
DISPLAY:
なし。

SYSTEM:
なし。

AWAYMODE:
なし。

実行:
[PROCESS] \Device\HarddiskVolumeX\Windows\System32\MoUsoCoreWorker.exe
USO Worker

PERFBOOST:
なし。

ACTIVELOCKSCREEN:
なし。

という結果が得られる場合があります。

これは太字のMoUsoCoreWorker.exeがシステムに対して「スリープしちゃｲﾔﾝ」というお願いをし、それをシステムが聞き入れているという意味です。

「よし、MoUsoCoreWorkerが原因なんだな!ぶっ殺してやる!!」とか言ってタスクマネージャを起動してプロセスをkillする前に、まず試してもらいたいことがあります。

まず、このMoUsoCoreWorkerはWindows Updateの眷族で、Windows Updateとズブズブの関係です(そらそうだ)。

で、Windows Updateでアップデートを行わせたい場合、こいつが出張ってきてWindows Update本体(といえばいいのかな?)が活動中にシステムがスリープしてしまわないように邪魔をする仕事もします。

この時点で、新しいアップデートファイルがMS側に用意されていることはMoUsoCoreWorkerにはわかっています。

こういったケースの場合にMoUsoCoreWorkerによるスリープの阻害が発生していることを数回確認しました。

なお、これは、「オプションの品質更新プログラムがあります」という表示とは別物です。

重要なので再度繰り返させていただきますが、別物です。

ここからがお笑いなのですが、Windows Update本体はこの新しいアップデートファイルを何日も見つけられないまま「最新の状態です」と強弁し続ける場合があります。

つまり、オプション以外のアップデートがあることはMoUsoCoreWorkerにはわかっているが、それをユーザに提示できず、かつWindows Update本体がそのアップデートをダウンロードしてシステムを更新できないという状況が現出します。

これは、システムを再起動しても、「設定」画面の「更新とセキュリティ」の「Windows Update」画面で「更新プログラムのチェック」ボタンを連打しても変わらないことがあります。

そうなると、ユーザには何が原因なのか外見からはわかりません。

憎きはMoUsoCoreWorkerただ一人、きゃつを封じるためにはどんな手でも使わなくては!という短絡的な思考に走っちゃいけません。

まず「サービス管理ツール」を開いて次の二つのサービスを再起動してみてください。

サービス名	表示名
UsoSvc	Orchestrator Service の更新
wuauserv	Windows Update

すると、あらびっくり、これまで見えていなかった更新ファイルが急に見えるようになっちゃったりするのです。

(繰り返しますが、これは「オプションの品質更新プログラム」ではありません。)

そして、その見えていなかったファイルがいったん見えるようになりますと、Windows Updadeを介して更新できるようになります。

そして、更新すると、MoUsoCoreWorkerはおとなしくなり、以後はスリープを阻害することがなくなります。

私の経験では、これまで3回MoUsoCoreWorkerが出張ってきていたうち、3回ともこの方法で問題を解消できました。

以上、どなたか様の参考になれば幸いです。

ここまでお読みいただき、ありがとうございました。