Windows Updateが全更新0x80240034で失敗する時の復旧手順（FODOrOCPended地獄からの脱出）

Last updated at 2026-08-02Posted at 2026-08-02

はじめに

Windows Updateですべての更新（Defender定義・.NET・機能更新など）が 0x80240034 (WU_E_INSTALL_NOT_ALLOWED) で失敗し続ける、という事象に遭遇しました。

7ヶ月間更新が止まった末に原因を特定して復旧できたので、その診断手順と復旧手順を実ログ付きでまとめます。

本記事の内容は個人環境での実証に基づきます。レジストリ操作を含むため、実行は自己責任でお願いします。作業前に必ずバックアップを取りましょう。

TL;DR

項目	内容
症状	全更新が `0x80240034` でFAILED / イベント31「更新プログラムをダウンロードできませんでした」が繰り返す
根本原因	`dism ... /norestart` で実行した機能変更が再起動されず放置され、`FODOrOCPended=1`（保留中のFOD/OC操作）が残った
復旧	`dism /online /cleanup-image /revertpendingactions` → 再起動 → 全更新が通るようになる

症状

保留中の更新（Defender・.NET・Visual Studio・機能更新）が全部 0x80240034 でFAILED
WU履歴（QueryHistory）が全件 FAILED 0x80240034
イベントログ Microsoft-Windows-WindowsUpdateClient/Operational にイベント31が毎時繰り返し

[08/01/2026 16:24:12] FAILED 0x80240034 :: Windows 11, version 25H2
[08/01/2026 16:23:26] FAILED 0x80240034 :: 2026-07 .NET Framework セキュリティ パッチ (KB5101001)
[08/01/2026 16:17:26] FAILED 0x80240034 :: 悪意のあるソフトウェアの削除ツール x64 - v5.143 (KB890830)

0x80240034 は WU_E_INSTALL_NOT_ALLOWED ですが、この場合は「保留中の機能操作があるため、すべてのインストールが拒否されている」状態でした。

原因の構造

発端は、ある機能移行のため以下のDISMコマンドを /norestart 付きで実行したことでした（PowerShell履歴に残っていました）。

dism /online /disable-feature /featurename:VirtualMachinePlatform /norestart
dism /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux /norestart
dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /norestart

/norestart は「変更をキューに入れるが再起動はしない」という意味です。この状態で再起動せずに放置すると：

CBS（コンポーネントベースサービス）に保留トランザクションが残る
HKLM\...\Component Based Servicing\PackagesPending に FODOrOCPended=1 が立つ
C:\Windows\WinSxS\pending.xml が残り続ける
Windows Updateは「未完了の機能操作がある」と判断し、全更新を0x80240034で拒否し続ける

FODOrOCPended の FOD は Features-on-Demand、OC は Optional Component。この値が1だと、WUは一切インストールを許可しません。 まず最初に疑うべきポイントです。

診断手順（実コマンド付き）

1. 保留トランザクションの確認（最重要）

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending"

FODOrOCPended REG_DWORD 0x1 が見えたら原因確定です。サブキーには保留中のパッケージ名（HyperV系など）が並びます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending
    FirstMergedExecutionSequence    REG_DWORD    0x5fa
    FirstMergedExecutionClient    REG_SZ    DISM Package Manager Provider
    FODOrOCPended    REG_DWORD    0x1
    ...\Containers-Client-SDN-Package~31bf3856ad364e35~amd64~~10.0.26100.1
    ...\HyperV-Chipset-Package~31bf3856ad364e35~amd64~~10.0.26100.7623

2. pending.xml の確認

dir C:\Windows\WinSxS\pending.xml

通常は存在しないファイルです。存在して日時が最近 = 未処理の保留操作が残っている証拠です。

3. DISMログで「何を実行したか」を確認

findstr /C:"Executing command line" C:\Windows\Logs\DISM\dism.log

/norestart 付きDISMが実行されて放置されていないかを確認します。

4. Setupイベントログで機能変更の内容を確認

イベント7/8/13/14 + メッセージに Client id: DISM Package Manager Provider が見える場合、DISMによる機能変更が保留中です。

A reboot is necessary before the selectable update VirtualMachinePlatform ... can be turned off.

5. WU履歴で失敗の開始時期を特定

$s = New-Object -ComObject Microsoft.Update.Session
$s.CreateUpdateSearcher().QueryHistory(0, 30) | ForEach-Object {
    "{0} {1} :: {2}" -f $_.Date, $_.ResultCode, $_.Title
}

復旧手順

本命：DISM /RevertPendingActions（公式ルート）

管理者PowerShellで以下を実行します。

dism /online /cleanup-image /revertpendingactions

これは保留中の操作を「取り消す」公式コマンドです。未適用の機能変更（WSL無効化やHyper-V有効化など）が破棄され、保留状態が解除されます。

実環境での出力：

展開イメージのサービスと管理ツール
バージョン: 10.0.26100.5074
イメージのバージョン: 10.0.26100.7623
イメージの保留中の操作を元に戻しています...
操作が完了しました。保留中の操作を元に戻す処理は再起動後に試行されます。
操作は正常に完了しました。

exit code 0 でも「再起動後に試行されます」と出るので、必ず再起動します。

再起動後の確認：

# PackagesPending が消えている
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending'  # False

# pending.xml が消えている
Test-Path C:\Windows\WinSxS\pending.xml  # False

# スキャンが正常に戻る
$s = New-Object -ComObject Microsoft.Update.Session
$s.CreateUpdateSearcher().Search("IsInstalled=0").Updates.Count  # 正常に件数が返る

あとは普通に更新をインストールすれば全部通ります。

代替：レジストリ直クリア（公式DISMが使えない場合）

CBS系レジストリキーと C:\Windows\WinSxS は TrustedInstaller ACLで保護されており、管理者権限でも書き込み・削除が拒否されます（reg delete が「アクセス拒否」になる）。この方法はDISMが使えない場合の最終手段です。

SYSTEM権限のスケジュールタスクとして実行するとACLを回避できます。

schtasks /create /tn ClearFOD /tr "powershell -NoProfile -ExecutionPolicy Bypass -File C:\temp\clear.ps1" /sc once /st 23:59 /ru SYSTEM /f
schtasks /run /tn ClearFOD

clear.ps1 の中身：

# 必ず先にバックアップ
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending" C:\temp\PackagesPending.reg /y
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending" C:\temp\SessionsPending.reg /y
Copy-Item C:\Windows\WinSxS\pending.xml C:\temp\pending.xml.bak

# 削除
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending" /f
Rename-Item C:\Windows\WinSxS\pending.xml pending.xml.bak

WU COM API（PowerShell）の罠

更新をスクリプトで自動インストールする際にハマるポイントです。

罠1：Updatesプロパティに配列を直接代入してはいけない

# ❌ これだと IndexOutOfRangeException → Download() が 0x80240004
$dl.Updates = $targets

# ✅ UpdateColl に Add してから代入する
$coll = New-Object -ComObject Microsoft.Update.UpdateColl
foreach ($u in $targets) { [void]$coll.Add($u) }
$dl.Updates = $coll

罠2：QueryHistoryのResultCode

2=SUCCESS / 3=IN_PROGRESS / 4=FAILED / 5=ABORTED です。素の数値だと分かりにくいので変換しましょう。

罠3：非管理者シェルからは呼べない

Start-Process -Verb RunAs で昇格実行が必要です。UACポップアップが出るので、ユーザーの操作が要ります。

機能更新（OSのメジャーアップデート）の場合

Install() が RebootRequired=True を返したら、再起動するとセットアップフェーズに入ります。数回再起動して完了するのが正常です。

おまけ1：Docker Desktopが起動しない（Hyper-Vバックエンド編）

Docker Desktopの設定が WslEngineEnabled: false（Hyper-Vバックエンド）なのにHyper-V機能が無効だと、エンジンが起動せず500エラーになります。

バックエンドログのサイン：

[W] attempting recovery from engine failure: starting engine: engine linux/hyperv failed to start:
    checking preconditions: hyper-v feature is not enabled

設定確認：

// %APPDATA%\Docker\settings-store.json
"WslEngineEnabled": false

修正：

dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart

再起動すればHyper-Vエンジンが動きます（exit code 3010 = 成功+再起動必要）。

おまけ2：特定の更新（Visual Studio等）が無限に再提供される場合

「ダウンロードボタンを押しても押しても同じ更新が出てくる」問題。履歴はSUCCESSなのに IsInstalled=0 のまま。

疑うべきは「幽霊インスタンス」：VSの登録は残っているのに、実フォルダが存在しない状態です。

# vswhereでは「存在する」と出る
& "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -all -products * -format json

# でも実フォルダが無い！
Test-Path "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe"  # False

この状態だと：

WUの検出は「古いVSがいる」と判断して更新を出し続ける
更新エンジンは実体の無いインスタンスを更新できない → 毎回「成功」して毎回再提供

修正は幽霊インスタンスの登録抹消：

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe" uninstall --installPath "C:\Program Files\Microsoft Visual Studio\2022\Community" --quiet --norestart

これでWUの検出から消え、再提供が止まります。

補足：VSの管理者更新はWU APIの IUpdate.Hide() で非表示にできません（PowerShellのCOM相互運用では DISP_E_UNKNOWNNAME になります）。「非表示にしたい」場合は幽霊登録の除去やWSUS側での承認管理が必要です。

教訓

dism ... /norestart を実行したら必ず再起動まで完了させる。放置するとFODOrOCPendedが残り、全更新がブロックされます。
FODOrOCPended=1 は「保留中の機能操作」= 全更新ブロックの強力なサイン。0x80240034が出たら最初に確認しましょう。
保留操作の取り消しは DISM /RevertPendingActions が公式ルート。レジストリ直削除はACL的にほぼ不可能（SYSTEM権限が必要）。
トラブルシュート中に何度もUAC昇格が必要になるので、一連の作業は1本のスクリプトにまとめてUACクリック回数を減らすと効率的です。
「更新が無限に再提供される」場合は、インストール実体と登録の整合性（幽霊インスタンス）を疑いましょう。

まとめ

0x80240034 で全更新が止まる問題は、保留中のFOD/OC操作が原因であることが多いです。

診断: reg query ...\PackagesPending  →  FODOrOCPended=1 を確認
復旧: dism /online /cleanup-image /revertpendingactions  →  再起動

1コマンド+再起動で直るケースが多いので、同じ症状の方はまずこれを試してみてください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up