Windows Server 2016 で 2025年7月の更新プログラム KB5062064 / KB5062799 を適用しようとして、catadnew.cpp 0x00000057 のエラーで失敗するケースが報告されています。本記事では原因の整理と、現場で実際に有効だった対処手順を順番つきで解説します。
現象の整理：catadnew.cpp 0x00000057 で更新が失敗する
問題のパターンは次のようなものです。
- 対象OSは主に Windows Server 2016（オンプレ / クラウド問わず）。
- 2025年7月配信の更新プログラム
- KB5062064（.NET Framework 4.8 累積更新）
- KB5062799（Servicing Stack Update：SSU）
C:\Windows\System32\catroot2\dberr.txtにcatadnew.cpp at line #1252 encountered error 0x00000057が多数出力される。- Windows Update サービス（wuauserv）等を再起動しても状況は変わらない。
- 再起動後に「更新に失敗しました」「変更を元に戻しています」→ 再起動ループになりかけるケースもある。
このログは、更新処理の中でカタログデータベース（Catroot2）を扱うモジュール catadnew.cpp が「無効なパラメーター（ERROR_INVALID_PARAMETER, 0x00000057）」を検知して処理に失敗していることを示しています。
KB5062064 / KB5062799 の役割と位置づけ
今回問題になっている 2 つの KB は、どちらも Windows Server 2016 を最新状態に保つうえで重要な更新です。
| KB番号 | 対象 | 種類 | 概要 |
|---|---|---|---|
| KB5062064 | Windows 10 Version 1607 / Windows Server 2016 | .NET Framework 4.8 累積更新 | 2025年7月の .NET 4.8 セキュリティ・信頼性更新。TypeDescriptor などのライブラリの信頼性向上を含む。公式ドキュメントの「Known issues in this update」には現時点で既知の問題は記載されていません。 |
| KB5062799 | Windows 10 Version 1607 / Windows Server 2016 | Servicing Stack Update（SSU） | 更新をインストールする「サービシングスタック」の品質改善。最新の SSU を入れておかないと、将来の累積更新が正しく提供・適用されない場合があると明記されています。 |
どちらの KB も、Windows Server 2016 を今後もパッチ適用可能な状態に保つうえで避けて通れません。そのため、catadnew.cpp エラーでブロックされると実運用への影響は大きくなります。
0x00000057（ERROR_INVALID_PARAMETER）と catadnew.cpp の意味
0x00000057 は Windows 共通のエラーコードで、定数名 ERROR_INVALID_PARAMETER に対応します。日本語では「パラメーターが間違っています」です。
一方、ログに登場する catadnew.cpp は、Cryptographic Services（暗号化サービス） の内部でカタログデータベース（Catroot2） を操作するコンポーネントを指すソースファイル名です。
| 要素 | 役割 | 今回のエラーとの関係 |
|---|---|---|
| Catroot2 フォルダー | 更新プログラムやドライバーのセキュリティカタログのデータベース（CatalogDB）が置かれる場所 | ここに破損や不整合があると、カタログ読み書き処理のパラメーターが異常になり 0x00000057 を引き起こしやすい |
| catadnew.cpp | CatalogDB を更新・参照するコンポーネントの一部（ソースファイル） | Catroot2 の DB に対して「不正なパラメーター」を伴う操作を検出すると、dberr.txt にログを残して処理中断 |
| Cryptographic Services | 署名の検証、カタログ管理などを司る Windows 標準サービス | サービスの動作不良や内部 DB 破損があると、更新プログラムの署名検証フェーズで失敗する |
つまり今回のケースは、特定の KB に固有の不具合というより「カタログ DB（Catroot2）や更新コンポーネント側の不整合」が KB5062064 / KB5062799 の適用タイミングで表面化していると見るのが自然です。
これは KB5062064 / KB5062799 の既知不具合なのか？
2025年11月時点で、Microsoft の公式サポート記事（KB5062064 / KB5062799）を確認すると、「Known issues in this update」には特に問題は掲載されていません。
一方、Microsoft Q&A では、まさに次のような投稿が存在します。
- 「Windows Update Failing – catadnew.cpp Error 0x00000057 with KB5062064 and KB5062799 – server stuck on recovery」
- 症状・ログは本記事で説明している内容とほぼ同じ。
- 回答としては「Catroot2 / SoftwareDistribution の再生成」「DISM / SFC の実行」「最新 SSU の事前適用」「クリーンブートでの再試行」といった、いわゆる更新コンポーネントの標準的なリセット手順が提示されています。
つまり、
- 公式 KB として「既知の不具合」と明示はされていない
- しかし Q&A やフォーラムでは複数の同様事象が報告されており、標準的な更新リセット手順で解消するケースが多い
という位置づけです。「KB にバグがある」というより、サーバー側のカタログ DB・サービススタック・イメージ状態のどこかに潜んでいた問題が、今回の KB で露呈したと捉えるのが現実的です。
推奨対処フロー（この順番で実施）
ここからは、現場での再現例や Microsoft Q&A の回答内容を踏まえて、実務的に再現性の高いフローを整理します。
| ステップ | 目的 | 優先度 |
|---|---|---|
| 1. 更新コンポーネントの初期化 | Catroot2 / SoftwareDistribution の破損・不整合を解消 | 最優先 |
| 2. DISM / SFC によるイメージ修復 | コンポーネントストア、システムファイルの整合性を回復 | 高 |
| 3. 最新 SSU の先入れ | サービシングスタックを最新状態にしてから累積更新を入れる | 高 |
| 4. クリーンブートで再試行 | セキュリティ製品・監視ツール等の干渉を排除 | 中 |
| 5. 手動（オフライン）適用 | WSUS などを介さずスタンドアロンで適用 | 中 |
更新コンポーネントの初期化（SoftwareDistribution / Catroot2 の再生成）
まずは Catroot2 と SoftwareDistribution をリセットして、CatalogDB の破損を洗い流します。管理者権限の コマンド プロンプトで実行してください。
net stop wuauserv
net stop bits
net stop cryptsvc
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 Catroot2.old
net start cryptsvc
net start bits
net start wuauserv
- サービスを停止してからフォルダーを
.oldにリネームすることで、次回の Windows Update 時に新しいデータベースとキャッシュが自動生成されます。 - 「別のプロセスが使用中です」等でリネームに失敗する場合は、
- サーバーを再起動してすぐ同じコマンドを打つ
- または セーフモード / クリーンブートで起動してから実行
| フォルダー | 役割 | リセットの効果 |
|---|---|---|
| SoftwareDistribution | 更新プログラムのダウンロードキャッシュ / 一時ファイル | 壊れたキャッシュを再取得させることで、ダウンロード・展開フェーズの不具合を解消 |
| Catroot2 | 更新・ドライバー署名の CatalogDB を保存 | 破損したカタログ DB を捨て、新しい DB を作り直すことで catadnew.cpp のエラーを回避 |
DISM と SFC によるイメージ修復
Catroot2 を再生成してもエラーが再発する場合は、Windows のコンポーネントストアやシステムファイル自体に破損がある可能性があります。続けて DISM / SFC を実行します。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
- DISM は
C:\Windows\WinSxSを中心としたコンポーネントストアをチェック・修復し、不整合を自動的に補修します。 - SFC は保護されたシステムファイルを検査し、破損していればキャッシュから正常なコピーに置き換えます。
- WSUS 環境・プロキシ経由の場合、
/RestoreHealthが外部ソースにアクセスできずエラーになることがあります。可能であれば、一時的に- インターネットに直接出られるネットワークに接続
- または /Source で OS メディアを指定
DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess
DISM / SFC で「破損が検出・修復された」と出たあとに再起動し、その状態で KB5062064 / KB5062799 の再適用を試します。
最新 Servicing Stack Update（SSU）の手動適用
SSU は「更新エンジンそのものの更新」です。古い SSU のまま累積更新だけを入れようとすると、今回のような謎の失敗に繋がることがあります。
- Microsoft Update カタログで KB5062799 を検索し、対象 OS（Windows Server 2016 x64）向けの .msu をダウンロード。
- サーバー上の任意のフォルダー（例：
C:\Temp）に保存。 - 管理者権限のコマンドプロンプトで以下を実行。
wusa.exe C:\Temp\KB5062799.msu /quiet /norestart
インストールが完了したら再起動し、その上で KB5062064 などの累積更新を適用します。
| 確認ポイント | 確認方法 |
|---|---|
| SSU が入っているか | [コントロール パネル] – [プログラムと機能] – [インストールされた更新] で KB5062799 を検索 |
| 順序 | SSU → 累積更新（KB5062064 等）の順に適用されているか確認 |
クリーンブートでの再試行
ウイルス対策ソフト、EDR、監視エージェント、バックアップエージェントなどが、更新中のファイルやカタログをロックしてエラーを誘発するケースもあります。その場合は クリーンブートでの試行が有効です。
msconfigを実行。- [サービス] タブで「Microsoft のサービスをすべて隠す」にチェックを入れ、残っているサードパーティ製サービスをすべて無効化。
- [スタートアップ] タブで不要な常駐を無効化。
- 再起動後、GUI から Windows Update を実行するか、
wusa.exeで KB を再適用。
EDR 製品などはベンダーの提供する「メンテナンスモード」「サイレンスモード」がある場合も多いため、インストール完全停止ではなくメンテナンスモードを利用した方が安全なこともあります。
手動適用（スタンドアロン / オフライン）
WSUS や構成管理ツール経由の配信で失敗する場合、まずは個別サーバーでの手動適用を試すと切り分けが容易になります。
.msu をそのまま適用する例
wusa.exe C:\Temp\KB5062064.msu /quiet /norestart
.cab を展開して DISM で適用する例
expand -F:* C:\Temp\KB5062064.msu C:\Temp\KB5062064\
DISM /Online /Add-Package /PackagePath:C:\Temp\KB5062064\*.cab
この方法で成功する場合、WSUS 側の承認や配布ルール、もしくは中継プロキシの問題の可能性が高くなります。
それでも改善しない場合に確認したいポイント
上記一連のフローを通しても catadnew.cpp 0x00000057 が解消しない場合、以下を追加で確認すると切り分けが進みます。
ログの精査
| ログファイル | パス | 見るべきポイント |
|---|---|---|
| dberr.txt | C:\Windows\System32\catroot2\dberr.txt | catadnew.cpp のエラーメッセージとエラーコードのパターン（0x00000057 の他に JET エラーなどが混じっていないか） |
| CBS.log | C:\Windows\Logs\CBS\CBS.log | 該当 KB のインストール試行時間帯のエントリ。特定の .cat / .mum ファイルでエラーになっていないか。 |
| DISM.log | C:\Windows\Logs\DISM\dism.log | DISM /RestoreHealth 実行時のエラー詳細（ソース不足、アクセス拒否など）。 |
| ReportingEvents.log | C:\Windows\SoftwareDistribution\ReportingEvents.log | 更新のインストール結果（0x800xxxxx のようなエラーコード）が記録される。GUI では見えない細かいエラーコードを把握可能。 |
特定の .cat ファイル名が繰り返し登場する場合、その更新だけを一度アンインストール → 再適用することで解消するケースもあります。
最近適用した更新のアンインストール
直前に別の累積更新やドライバー更新を入れている場合、それが CatalogDB をおかしくした可能性も否定できません。一時的にそれらをアンインストールしてから再度 KB5062064 / KB5062799 を試すのも一案です。
- 通常起動でアンインストールできない場合は、回復環境（WinRE）から
dism /imageを用いた削除も検討します。 - ただし、役割サーバー（AD DS、SQL Server、Exchange など）では副作用も大きいため、事前のバックアップ・スナップショット取得は必須です。
「更新が全く提供されない」系の既知事象との切り分け
2025年後半には、Windows Server 2016 で SSU（KB5062799）は入っているのに、それ以降の累積更新が一切提供されないという別種の事象も報告されています。
これは「更新が提供されない」ケースであり、今回のように インストール途中で catadnew.cpp エラーが出てロールバックするケースとは別物です。ただし背景としては同じく「サービシングスタック周辺の挙動」が絡んでいるため、SSU の適用状態や Windows Update の設定を一緒に見直す価値はあります。
インプレース修復（上書きインストール）を検討するライン
Catroot2 の再生成、DISM / SFC、SSU 先入れ、クリーンブート、スタンドアロン適用をすべて試しても状況が変わらない場合、OS イメージ全体の一部が深刻に壊れている可能性があります。
業務影響が大きいサーバーであれば、最終手段として インプレース修復（上書きセットアップ）を検討します。
- 現在の OS と同じエディション・ビルドの Windows Server 2016 セットアップメディアを準備。
- サーバーにマウントし、
setup.exeを実行。 - 「個人用ファイルとアプリを引き継ぐ」を選択してインストールを進める。
この方法は、ドメイン参加状態や多くのアプリ・設定を維持したままOS コンポーネントをほぼ入れ直すイメージです。ただし、
- バックアップ／スナップショットを必ず取得
- サーバー役割によっては追加の再構成が必要になる可能性がある
- ダウンタイムが比較的長くなる
といったデメリットもあるため、十分なメンテナンス時間とロールバック手段を確保したうえで実施してください。
運用上の注意とベストプラクティス
今回の catadnew.cpp 0x00000057 問題に限らず、Windows Server 2016 のパッチ管理では次のような運用ルールを作っておくとトラブル時のリスクを下げられます。
メンテナンスウィンドウとスナップショットの徹底
- 本番サーバーにパッチを入れる際は、必ず明示的なメンテナンスウィンドウを設定する。
- 仮想環境（Hyper-V / VMware / Azure など）では、更新前にスナップショットやチェックポイントを取得。
- 物理サーバーでは、少なくともシステムボリュームのイメージバックアップをスケジュールしておく。
テスト環境での先行適用
- 可能であれば、本番と同じ役割構成（AD DS / SQL / Exchange など）を持つ ステージング環境を用意。
- Patch Tuesday（日本時間では水曜）後、まずはステージングに適用して 1～2 日動作を観察。
- 致命的な問題が出ないことを確認してから本番へ展開する。
セキュリティ製品との連携
- ウイルス対策・EDR・バックアップなどのベンダーが提供する「推奨除外パス」を確認し、少なくとも
C:\Windows\SoftwareDistributionC:\Windows\System32\catroot2
- 更新作業時には「メンテナンスモード」を活用し、更新後に確実に元に戻す運用フローをドキュメント化しておきます。
トラブルシューティング手順のテンプレート化
今回紹介したような手順を、社内向けの標準手順書としてまとめておくと、将来別の KB で同様の CatalogDB エラーが出たときにも素早く対応できます。
| カテゴリ | チェック項目 | 備考 |
|---|---|---|
| 更新コンポーネント | SoftwareDistribution / Catroot2 のリセットを実施済みか | ログに catadnew.cpp エラーがある場合は最優先で実施 |
| イメージ健全性 | DISM / SFC を実行済みか | エラー時は OS メディアからのソース指定も検討 |
| SSU | 最新の SSU がインストール済みか | KB5062799 など、公式に案内されている SSU を確認 |
| サードパーティ製品 | クリーンブートでの再試行を行ったか | EDR / 監視エージェントの影響を切り分け |
| ログ | dberr.txt / CBS.log / DISM.log / ReportingEvents.log を確認済みか | 特定ファイル名・エラーコードが繰り返し出ていないか |
まとめ：Catroot2 / 更新コンポーネントの再構築が鍵
catadnew.cpp 0x00000057 は、見慣れないエラーコードの組み合わせに見えますが、実態としては CatalogDB（Catroot2）や更新コンポーネントの不整合が露呈した結果であることがほとんどです。
- 公式 KB（KB5062064 / KB5062799）では現時点で「既知の不具合」とはされていない。
- しかし Microsoft Q&A やフォーラムには同様の報告があり、Catroot2 / SoftwareDistribution の再生成 → DISM / SFC → SSU 先入れ → クリーンブート / 手動適用 の順で対処すると解消するケースが多い。
- 再発防止には、メンテナンスウィンドウの確保、スナップショットやバックアップ、セキュリティ製品の除外設定・メンテナンスモード活用といった運用面の整備も重要。
「更新が当たらない＝OS を入れ直すしかない」と考える前に、まずは本記事のフローを上から順に試してみてください。多くの場合、Catroot2 / 更新コンポーネントの再構築で問題は解決可能です。
コメント