https://error-daizenn.hatenablog.com/entry/2025/12/17/214646

Windows 11 23H2から24H2に上げようとして、Windows Updateが途中で失敗して「0xC1900101」が出る。これ、最近かなり見かけます。Microsoft LearnのQ&Aでも、23H2→24H2の更新がこのコードで止まり「どのドライバーが犯人か知りたい」という相談が2025年9月8日（UTC）に投稿されました（日本時間だと9月9日早朝）。 (Microsoft Learn)
この記事は、同じ沼にハマった人が「まず何を疑うべきか」「どうやって犯人を特定するか」「今すぐできる回避策はどれか」を、コメントで情報交換しやすい形でまとめたものです。ちなみに24H2はOSビルド26100系、23H2は22631系が目安になります。 (Microsoft Learn)

いま起きていること：23H2→24H2で0xC1900101、そしてロールバック

0xC1900101は「だいたいドライバー絡みでアップグレードが巻き戻った」系の超ざっくりエラーです。 (Microsoft Learn)
体感としては、インストールの終盤で再起動を挟んだあと「更新を元に戻しています」になりがち。Redditでも「再起動後に回復が走って、数回やって自動で戻る」みたいな報告が出ています。 (Reddit)
これが厄介なのは、画面に出る0xC1900101だけだと“原因の粒度”が粗すぎること。つまり「犯人は誰だ？」に答えてくれない。

原因の正体：ドライバーだけじゃない、でも中心はドライバー

Microsoftの公式ドキュメントでも、0xC1900101は「互換性のないドライバーがあると起きやすい」と整理されています。 (Microsoft Learn)
ただし現場では、ドライバー単体というより「ドライバー＋周辺要素」の合体事故が多いです。たとえば、古いセキュリティソフト（security software／セキュリティ対策）や暗号化（encryption／暗号化）、仮想化系（virtualization／仮想化）ユーティリティが“ブート直前”に割り込むと、結果としてドライバー相当の失敗に見えることがあります。Microsoft Learn側の回答でも、Setupact.logやSetuperr.logなどログ確認に寄せる流れが定番です。 (Microsoft Learn)

まず結論：犯人探しはSetupDiagがいちばん早い

「どのドライバーが原因？」に最短で近づくなら、SetupDiag（セットアップ診断）でログを解析するのが近道です。 (Microsoft Learn)
SetupDiagはWindowsセットアップログを見て「失敗したフェーズ（phase／段階）」や、引っかかった互換性要因をレポートにしてくれます。ここで“具体名”が出ると一気に勝ちゲーになります。逆に出ない場合でも、次に読むべきログの場所が絞れます。

手順：ドライバー名までたどり着く王道ルート

0xC1900101は「ログを見れば、意外と犯人が書いてある」タイプです。 (Microsoft Learn)

(1) Windows Updateの失敗後、いったん通常起動まで戻します。
(2) SetupDiag（セットアップ診断）をMicrosoftの手順どおり入手して実行します。 (Microsoft Learn)
(3) 出力されるSetupDiagResults.log（結果ログ）を読み、Driver（ドライバー）やCompatibility（互換性）に関する記述がないか探します。 (Microsoft Learn)
(4) 追加で掘るなら、セットアップログの定番どころ、setupact.logとsetuperr.logを確認します。ログの場所はフェーズで変わりますが、案内として「setupact.logが特に有用」とMicrosoftが説明しています。 (Microsoft Learn)
(5) もし「FIRST_BOOT（最初の起動）」や「SYSPREP_SPECIALIZE（システム構成の特殊化）」っぽい文言が出るなら、直前に読み込まれたドライバーやサービスに当たりをつけます。これは“わりと典型”です。 (Microsoft Learn)

ここまでやって「ドライバー名が出た」なら、次の一手はシンプルで、更新・無効化・削除のどれか。出なかったら、周辺機器（USB機器とか、外付けストレージ）を全部外して最小構成で再挑戦、が現実的です。なんか地味だけど効くんだよな…これが。

公式側の“いまの立ち位置”：根本修正より「原因を潰してから来てね」寄り

Microsoftの案内は一貫して「まず互換性（主にドライバー）を解消してからアップグレードしてね」というスタンスです。 (マイクロソフトサポート)
つまり、0xC1900101自体を“1発で直す魔法”は出にくい。代わりに、Windows Updateトラブルシューター（troubleshooter／問題解決ツール）やシステム修復など、周辺から崩していく導線が公式サポートにまとまっています。 (マイクロソフトサポート)

要注意：24H2は「Intel SST」で引っかかる個体がいた（いまは解消方向）

24H2はIntel Smart Sound Technology（SST／インテルの音声制御系）ドライバー互換性が原因で、配信保留（safeguard hold／保護措置）になった事例が公式に記録されています。 (Microsoft Learn)
この件は「SSTドライバーを10.30.00.5714以降、または10.29.00.5714以降に更新すると解決」と、MicrosoftのリリースヘルスやPCメーカー（Dellなど）も明記しています。 (Microsoft Learn)
ニュース側でも、Intel第11世代あたりで長く止まっていた問題が2025年9月下旬に“解決した”趣旨で報じられました。 (TechRadar)

ここ、地味に重要です。あなたのPCがSST絡みの保留に該当していると、Windows Updateに24H2が出てこない、もしくは出ても失敗しやすい、みたいな挙動になりえます。更新を急がないなら、まずドライバーを整えてからのほうが安全。

「どの人が該当？」対象ユーザーのざっくり目安

個人PCでも企業PCでも起こるけど、特に“メーカー製ノート＋音声/電源/管理系ドライバー多め”は当たりやすい印象です。 (Microsoft Learn)
企業（enterprise／企業）だと、EDR（endpoint detection and response／端末監視）やVPN、端末暗号化が入っていて、アップグレード時のブート周りに食い込みやすい。一般ユーザーだと、古い周辺機器ドライバーやオーディオ、ストレージが濃いです。あと、don’t（しないで）と言われてもつい挿しっぱなしのUSBドングル、あれも疑いどころ。

いま効きやすい回避策：コメント欄で伸びるのはここ

「成功した人」の共通点は、ログで当たりを付けて“1個ずつ潰した”ケースが多いです。 (Microsoft Learn)
ただ、みんなの報告が集まると再現性が見えるので、ここから先はフォーラム風にいきます。あなたの環境、よかったら置いてってください。たぶん誰か助かる。私も助かる（本音）。

みんなの報告テンプレ（コピペして編集OK）

0xC1900101は環境差が大きいので、情報が揃うほど“犯人候補”が絞れます。
Windows 11の現在バージョン（23H2など）とOSビルド（例：22631.x）
アップグレード方法（Windows Update／ISO／インストールアシスタント）
失敗のタイミング（何％、何回目の再起動、ロールバック有無）
SetupDiagResults.logに出たキーワード（Driver名、INF名、デバイス名など）
CPU世代とオーディオ周り（Intel SSTの有無、サウンドドライバーの版）

よくある「成功報告」パターン（あなたはどれに近い？）

SST更新で通った、セキュリティソフト外したら通った、周辺機器外したら通った、この三強になりがちです。 (Microsoft Learn)
TechCommunityでも、0xC1900101-0x30018のように拡張コード付きで、ドライバー/ハード互換性を疑う流れが出ています。 (Microsoft Tech Community)
Reddit側の「3回やって自動で戻る」系は、FIRST_BOOT寄りのにおいがします。もちろん断定はできないけど、ログに出る言葉が似てること多いんですよね。 (Reddit)

まとめ：0xC1900101は“ただの失敗”じゃなく、ログへの招待状

24H2更新の0xC1900101は、ほぼ「互換性（主にドライバー）を片付けてから来て」というメッセージです。 (Microsoft Learn)
最初にSetupDiag（セットアップ診断）、次にsetupact.log（セットアップ動作ログ）。ここで名前が出たら、そのドライバーを更新するか止める。それでもダメなら、SSTのような“公式に既知の地雷”を踏んでないか、24H2の既知の問題ページを確認する。 (Microsoft Learn)
あなたの0xC1900101、拡張コード（例：0x30018みたいな後半）や、SetupDiagの出力、よかったらコメントで共有して。こっそりでいいので。誤字ってもいいので。私もたまに誤字るしね、まじで。