Windows 11 23H2から25H2更新で0xC1900101-0x40017が出る原因と切り分け軸

本記事の対象となる事象は、Windows 11（23H2）から25H2への機能更新（Feature Update）で、エラーコード 0xC1900101 - 0x40017 が繰り返し発生し、更新がロールバック（元の状態へ復帰）するケースです。周辺機器の取り外しや、セキュリティ対策がWindows Defenderである点、空き容量が十分にある点を満たしていても失敗する例があり、単純な容量不足や外部機器起因だけでは整理できません。そこで、エラーが示す範囲、更新の仕組み、典型原因、ログの見方という順で論点を組み立てます。

• 0xC1900101-0x40017が示す範囲は「ドライバー系」と更新フェーズ
• 23H2から25H2への更新方式が、失敗の出方を左右する
• 周辺機器を外しても残る典型原因は「常駐ドライバー」と起動経路
• ログで「どのドライバーが落としたか」を確定する見方
• 「再試行を増やす」より「前提条件の整列」を先に置く理由

0xC1900101-0x40017が示す範囲は「ドライバー系」と更新フェーズ

0xC1900101で始まるエラーは、Microsoftの案内上「通常はドライバーのエラー」に分類されます。 (マイクロソフトサポート)
つまり、Windows Update自体が壊れているという断定ではなく、更新処理の途中で特定のドライバーやデバイス制御が破綻した可能性が中心になります。

一方で「-0x40017」という後段のコードは、失敗が起きた局面を示す手がかりとして扱われます。Microsoft Learn（Q&A）の事例では、画面メッセージとして「BOOT操作中のエラー」「SECOND_BOOTフェーズで失敗」といった表現が併記されるケースが確認できます。(Microsoft Learn) 以上を踏まえると、初回の展開（ファイルコピー）だけではなく、再起動後に起動構成やドライバー読み込みが切り替わる局面で落ちる構図が見えます。

そのため、USB機器を外しても改善しない場合は、内部に常駐する仮想デバイスやフィルタードライバー、ストレージ／ネットワークなど「外さずに残る要素」が焦点になります。ただし、同じコードでも実際の原因は複数に分岐しうるため、次章では23H2→25H2という更新経路の前提を整理します。

23H2から25H2への更新方式が、失敗の出方を左右する

25H2は2025年9月30日に提供開始と報じられており、24H2と近い構成を前提に配布される設計が説明されています。 (PC Watch)
この点から、23H2→25H2は「段差」が比較的大きくなりやすく、途中で24H2系のコンポーネントに切り替わる過程で相性問題が表面化しやすい、という整理が可能です。

ただし、25H2は更新履歴ページが個別に用意され、既知の問題（Known issues）をWindows Release Health（リリース健全性）で追跡する導線が示されています。(マイクロソフトサポート) つまり、端末固有の問題だけでなく、特定の更新プログラム（KB）や特定構成で発生する不具合が存在しうる前提がある、ということになります。

他方、更新が「何度も同じ箇所で戻る」現象は、更新プロセスが保護機構としてロールバックを選択している状態です。この結果、ユーザー側の操作としては再試行を重ねやすい一方、原因が同一であれば同一箇所で失敗が再現します。そうすることによって、時間は消費されるが情報は増えない、という状態になりやすいため、次章の「原因カテゴリの棚卸し」と次々章の「ログでの確証」が重要な判断材料になります。

周辺機器を外しても残る典型原因は「常駐ドライバー」と起動経路

0xC1900101-0x40017が継続するケースでは、外部機器よりも内部ドライバーの競合・古さ・フィルター構造が中心論点になりやすいです。 (マイクロソフトサポート)
周辺機器を外しているのに改善しない、空き容量も十分、対策ソフトも標準（Defender）という条件がそろうと、残りやすいのは「インストール時にも読み込まれるドライバー群」です。

具体的には、(1) ストレージ関連（NVMe/IRST/RAID、暗号化やドライブ保護に付随するフィルター）、(2) ネットワーク関連（VPN、仮想NIC、パケットフィルター）、(3) 仮想化・エミュレーション系（仮想オーディオ、仮想MIDI、RAMディスク等）、(4) 古い周辺機器ドライバーの残骸、が分類軸になります。言い換えると、デバイスマネージャー上の見える機器だけでなく、カーネルに入る補助ドライバが更新時に影響しうる、という整理です。

なお、Microsoft Learn（Q&A）では、ブランドPC（メーカー製）ではBIOSとドライバー更新の影響が指摘され、SFC/DISMといった整合性確認が並列で語られています。(Microsoft Learn) ただし、これらは一般論であり、どれが本件の決定打かはログで裏取りが必要です。そこで次章では、アップグーレド失敗時に残るログの位置と、読み取る観点をまとめます。

ログで「どのドライバーが落としたか」を確定する見方

同じエラーコードでも、setupログ上の失敗点を確定すると原因が「特定ドライバー」まで落とし込める場合があります。 (Microsoft Learn)
更新失敗は、画面に出るコードよりもログの記述が具体的です。特にSECOND_BOOTやBOOT操作が出る場合、再起動後に読み込まれたドライバー、または起動構成の切替に関与したコンポーネントが疑われます。

そのため、ログは「どのフェーズで」「何を読み込み」「どのエラーで停止したか」を並べる形で読みます。要点を整理すると、Panther系（セットアップ本体）とRollback系（戻し処理）の2系列で、同じ時刻帯のエラー行を突き合わせるのが基本になります。なお、Microsoft側も0xC1900101系をドライバー起因として整理しており、個別後段コードの有無にかかわらず切り分けの方向性は一致します。(マイクロソフトサポート)

ただし、ログに製品名が直接出ない場合もあります。その場合は、INF名、サービス名、デバイスインスタンスIDなど間接情報から同定する手順になります。次章では、原因カテゴリに対応する「整合性・起動・ドライバー」の確認方法が、どのように位置づけられているかを制度面から整理します。

「再試行を増やす」より「前提条件の整列」を先に置く理由

再試行の回数が増えても、原因が同一のままなら失敗点は固定されるため、前提条件の整列が実務上の確認点となります。 (マイクロソフトサポート)
本記事が示す状況では、空き容量が十分、周辺機器も外しているため、一般的な初動対処の一部はすでに満たされています。そうすると、残る論点は「内部ドライバー」「起動構成」「既知の問題」のいずれに寄せて検証するか、という設計になります。

まず、ドライバー起因というMicrosoftの分類に沿うなら、更新前後で読み込まれるドライバーの差分が中心です。次に、SECOND_BOOT/BOOT操作の示唆に沿うなら、ストレージ・暗号化・UEFI設定といった起動パスの要素が中心になります。さらに、25H2側の既知の問題という観点では、特定KBや特定構成での問題が公開されている可能性を前提に、更新履歴とRelease Healthの情報を突き合わせます。(マイクロソフトサポート)

ただし、これらは相互に排他的ではありません。たとえば、ストレージドライバーの互換性問題は「ドライバー」でもあり「起動」でもあります。この結果、切り分けの順序としては、(1) ログで失敗点を特定し、(2) 該当カテゴリ（ドライバー／起動／既知問題）に寄せ、(3) 変更点の最小化を意識しながら再評価する、という流れが合理的になります。以上を踏まえると、0xC1900101-0x40017は「更新機能の不具合」と一括りにするより、失敗局面（SECOND_BOOT）と分類（ドライバー系）を同時に扱うことが、整理軸として適合します。