SFCは正常なのにDISMが0x800f081fで失敗する原因と直し方：KB5037763が「未適用・適用不可」と出るケースまで整理

SFC（sfc /scannow）で「整合性違反なし」と出るのに、DISM（DISM /Online /Cleanup-Image /RestoreHealth）だけが 0x800f081f で落ちる──この組み合わせは珍しくありません。SFCが見ているのは主に“稼働中のシステムファイル”、一方DISMは“修復用の部品（コンポーネントストア）”まで含めて診断・修復するため、SFCが平気でもDISMだけが「修復素材が見つからない（0x800f081f）」状態になり得ます。Microsoft Learn+1

さらにCBS.log上で KB5037763 が絡んで見えるのに、更新履歴には無く、カタログから入れようとしても「この更新プログラムはお使いのコンピューターに適用されません」になる──これも“よくある落とし穴”です。KBはOSの種類・ビルド・エディション・前提パッチで適用可否が決まり、別OS向け（例：Server 2016向け） や 既に上位の累積更新で包含（superseded） されていると「適用不可」になります。KB5037763自体は、少なくとも Windows Server 2016（OS Build 14393系）向け累積更新 として公開されています。マイクロソフトサポート

• SFCは正常なのにDISMが0x800f081fで失敗する原因と直し方：KB5037763が「未適用・適用不可」と出るケースまで整理
  • 0x800f081fの正体：SFCとDISMの守備範囲が違う
  • CBS.logでKB5037763が見えても「インストール済みとは限らない」
  • まずは“状況確認”を最短でやる（ログ採取含む）
  • 修復の本命：ISO（install.wim/esd）を“完全一致”で指定する
    • 手順（例）
  • Windows Updateコンポーネントの不整合を整える（オンライン修復派の人向け）
  • 「KBが未適用なのにCBSに出る」「手動適用が適用不可」への実務的な考え方
  • どうしても直らない時の現実解：インプレース修復（上書き修復）
  • まとめ：今回の症状は“よくある”が放置はリスク、最短は「一致ISOで/Source修復」

0x800f081fの正体：SFCとDISMの守備範囲が違う

• SFC：壊れた“実ファイル”を、ローカルの修復イメージ（WinSxS等）から差し替える。

• DISM：その修復イメージ（コンポーネントストア）自体が壊れていないかも含めて直す。

つまり、コンポーネントストア側に欠損があると、SFCは「今動いているファイルはOK」と言いつつ、DISMは「直すための部品が無い」と言って止まります。0x800f081fは典型的にこの状態です。Microsoft Learn+1

CBS.logでKB5037763が見えても「インストール済みとは限らない」

CBS.logには“どの部品（パッケージ）を参照したか”が出ます。ここでKB番号が出ても、次の理由で「更新履歴に無い」「適用不可」になり得ます。

• OSが別系統：KB5037763が想定しているOS（例：Server 2016）と、実機のOS（Server 2019/2022など）が違う。マイクロソフトサポート

• 累積更新の包含：すでにより新しい累積更新が入り、単体KBは適用対象外。

• 前提条件不足：SSU（Servicing Stack Update）など前提が揃わず、手動適用が弾かれる。

• WSUS/ポリシー環境：Windows Updateの参照先が制限され、DISMがオンラインで部品を取れない。

「サーバーは正常に動いているがDISMだけ失敗」という状況は、将来の更新適用や機能追加（.NET有効化等）で詰まる種になるので、可能なら原因を潰しておく価値があります。

まずは“状況確認”を最短でやる（ログ採取含む）

管理者のコマンドプロンプトで、まず以下を実行します。

エラーが再現するなら、ログ位置を押さえます。Microsoftの案内どおり、主にここです。Microsoft Learn

• C:\Windows\Logs\DISM\dism.log

• C:\Windows\Logs\CBS\CBS.log

次に、OSの正確なバージョン（ビルド） を確認します。

ここで「自分のOSがServer 2016（14393系）なのか、2019（17763系）なのか…」が確定します。KB5037763は少なくともServer 2016の累積更新として案内されているため、別ビルドなら「適用不可」で自然です。マイクロソフトサポート

修復の本命：ISO（install.wim/esd）を“完全一致”で指定する

0x800f081fは「オンライン修復の取得元が無い」ことが多いため、同一ビルドのISO から修復ソースを与えるのが定石です。Microsoftや各種手順でも、/Source 指定で直るケースが広く共有されています。Microsoft Learn+2Super User+2

手順（例）

1. 対象OSと同じエディション/言語/ビルドのISOを用意してマウント（例：D:）

2. D:\sources\install.wim または install.esd を確認

3. install.wim内のインデックスを確認（エディションにより番号が違う）

4. ソース指定で修復（例：Index 1 を使う場合）

ポイントは3つです。

• ISOが“同じビルド”であること（ここがズレると直りません）

• /LimitAccess を付けて、Windows Updateに行かずローカルを優先する

• install.esdしか無い場合はESD指定でも可（環境によりWIM化が必要なことも）

Super Userなどでも/Source:WIM:指定で解決した例が定番として残っています。Super User

Windows Updateコンポーネントの不整合を整える（オンライン修復派の人向け）

オンライン（Windows Update経由）で直したい場合、更新コンポーネントの一時不整合が原因のこともあります。一般的な流れは次の順で試すのが安全です。

1. コンポーネントクリーンアップ

2. 再起動後に再度

DISMのガイドでも、DISM→SFCの順で整える説明がよく採られます。Windows Central

「KBが未適用なのにCBSに出る」「手動適用が適用不可」への実務的な考え方

• 更新履歴に無い＝絶対未適用ではありません。累積更新は内部的に多数のパッケージを含み、CBSが参照したKB名が“単体適用”と一致しないことがあります。

• 「適用不可」＝壊れているではなく、ほとんどは「OSが違う／すでに包含／前提不足」です。

• KB5037763はMicrosoftのサポート記事でServer 2016向け累積更新として提供されています。自分のOSビルドが違うなら弾かれるのが正常です。マイクロソフトサポート

どうしても直らない時の現実解：インプレース修復（上書き修復）

ログ上でコアの修復が進まず、/Source でも改善しない場合、インプレースアップグレード（上書き修復） が最短で確実なことがあります。Microsoftコミュニティでも「通常手段で修復できないならISOを用いたインプレース」を案内する回答が見られます。Microsoft Learn
サーバー運用では検証・バックアップ・停止計画が絡むため慎重さは必要ですが、「DISMが永続的に壊れていて将来の更新が詰まる」状態を抱えるより、計画的に直す価値は高いです。

まとめ：今回の症状は“よくある”が放置はリスク、最短は「一致ISOで/Source修復」

• SFCが正常でもDISMが0x800f081fになるのは、修復元（コンポーネントストア）側の欠損で起きる。Microsoft Learn+1

• CBS.logにKB5037763が見えても、OSや包含状況次第で「更新履歴に無い」「適用不可」になり得る。KB5037763はServer 2016向け累積更新として案内されている。マイクロソフトサポート

• 直すなら、同一ビルドのISOをマウントして/SourceでDISM修復が最も成功率が高い。Super User+1

この流れで進めれば、「エラーは出るが運用はできている」という中途半端な状態から、更新・保守まで含めて安心できる状態に戻せます。