Windows展開メディアが0xc0430001で起動しないときのboot.stl更新方法

2026年7月の更新を既存のWindows展開メディアへ統合した後、USBやISO、PXEからWinPEを起動するとエラーコード0xc0430001で停止する場合、最初に確認すべきファイルはboot.stlです。

対処の要点は、更新対象と同じWindowsバージョン・同じアーキテクチャのboot.stlを、展開メディアの\EFI\Microsoft\Boot\boot.stlへ配置することです。Microsoftは、Update WinPEスクリプトでメディア全体を更新する方法を推奨しています。緊急対応では、更新済みOSのWindows\Boot\EFIフォルダーから手動コピーする方法も公式に案内されています。(マイクロソフトサポート)

目次

最初に結論:差し替えるboot.stlの場所

Windows展開メディアが0xc0430001で起動しない場合は、次の組み合わせを確認します。

確認項目内容
差し替えるファイルboot.stl
取得元更新済みOSの%SystemRoot%\Boot\EFI\boot.stl
展開メディア上の配置先\EFI\Microsoft\Boot\boot.stl
一致させる条件Windowsバージョンとアーキテクチャ
Microsoft推奨方法Update WinPEスクリプトでboot.wimを含めて更新
手早い公式対処更新済みOSから展開メディアへ手動コピー

たとえば、USBメディアがE:ドライブとして認識されている場合、コピー先は次の場所です。

E:\EFI\Microsoft\Boot\boot.stl

コピー元は通常、更新済みWindowsの次の場所です。

C:\Windows\Boot\EFI\boot.stl

ただし、C:固定ではなく、実際のWindowsフォルダーを示す%SystemRoot%を使う方が安全です。

Microsoft Learnの公式サンプルでは、更新済みboot.wim内のWindows\Boot\EFI\boot.stlを取り出し、展開メディアの\EFI\Microsoft\Boot\boot.stlへコピーしています。対象ファイルがメディアに存在しない場合でも、新規に配置する処理です。(Microsoft Learn)

対象となるWindows 11と2026年7月更新

今回の展開時の注意事項は、2026年7月14日に公開された次の更新で案内されています。(マイクロソフトサポート)

Windowsバージョン更新プログラム更新後のOSビルド
Windows 11 24H2KB510165026100.8875
Windows 11 25H2KB510165026200.8875
Windows 11 26H1KB510164928000.2525

主に影響を確認すべき環境は、次のような管理者向けの展開環境です。

  • 累積更新プログラムを統合したWindowsインストールUSB
  • ISOを加工して作成したWindows展開メディア
  • 更新済みのboot.wimを使用するWinPE
  • Microsoft Configuration ManagerやMDTなどで使用するブートメディア
  • PXE起動用に独自更新した展開イメージ
  • オフライン環境向けにDynamic Updateを事前統合したメディア

一方、通常のWindows Update適用後に、内蔵ストレージ上のWindows自体が0xc0430001で起動しなくなったケースは、同じ問題とは限りません。

この記事の対処は、USB、ISO、PXEなどのWindows展開メディアからWinPEを起動できないケースが対象です。通常使用しているWindowsが起動しない場合に、システムドライブやEFIシステムパーティションへ安易にboot.stlをコピーしてはいけません。

0xc0430001が発生する原因

boot.stlは、Secure Bootの検証処理で使用されるファイルです。Microsoftによると、展開メディアへDynamic Updateなどを統合するときは、更新したイメージと対応するboot.stlをメディアへ含める必要があります。

次のいずれかに該当すると、展開メディアからの起動に失敗し、0xc0430001が表示される可能性があります。

  • 展開メディアにboot.stlが存在しない
  • boot.wimを更新したが、メディア側のboot.stlを更新していない
  • Windows 24H2のメディアへ別バージョンのboot.stlをコピーした
  • x64メディアへ異なるアーキテクチャ用のファイルをコピーした
  • 古いOSから取得したboot.stlを、7月更新統合後のメディアに残している

Microsoftは、boot.stlについて、更新するイメージのWindowsバージョンおよびアーキテクチャと一致させる必要があると説明しています。(マイクロソフトサポート)

boot.wimだけ更新しても対処が完了しない理由

Windows展開メディアでは、boot.wim内部と、メディア直下のEFIフォルダーは別の領域です。

公式のUpdate WinPEサンプルは、次の順序で処理しています。

  1. sources\boot.wimをマウントする
  2. WinPEへ累積更新プログラムを適用する
  3. 更新済みWinPEからboot.stlを取得する
  4. boot.wimを保存する
  5. 取得したboot.stlをメディアの\EFI\Microsoft\Bootへコピーする

したがって、install.wimboot.wimへ累積更新プログラムを適用しただけでは、メディア外側のboot.stlが古いまま残る可能性があります。メディアのルート側にある次のファイルまで必ず確認してください。(Microsoft Learn)

\EFI\Microsoft\Boot\boot.stl

Microsoft公式の2つの対処方法

方法向いている環境特徴
Update WinPEスクリプト毎月メディアを更新する組織、複数拠点への配布、PXE展開boot.wimやブート関連ファイルをまとめて更新できる
boot.stlの手動コピーすぐにUSBメディアを復旧したい、対象メディアが少ない短時間で対応できるが、バージョン確認を手作業で行う必要がある

継続的にWindows展開メディアを保守する場合は、Update WinPEスクリプトを利用する方が安全です。一度だけ作成したUSBメディアを急いで修正する場合は、手動コピーが現実的です。

方法1:Update WinPEスクリプトで展開メディアを更新する

Microsoftが推奨しているのは、公式のDynamic Update適用手順に含まれるUpdate WinPE処理です。

元のメディアを作業フォルダーへコピーする

ISOをマウントしたドライブは読み取り専用です。そのままではファイルを差し替えられないため、内容をローカルの作業フォルダーへコピーします。

公式サンプルでは、概ね次の構成を使用します。

C:\mediaRefresh
├─ oldMedia
├─ newMedia
├─ packages
└─ temp

oldMediaには元の展開メディアを保存し、newMediaを実際の更新対象にします。障害発生時にやり直せるよう、元のISOやUSBの内容は直接変更しない方が安全です。

対応する更新パッケージを用意する

公式手順では、主に次のパッケージを使用します。

  • 累積更新プログラム
  • Setup Dynamic Update
  • Safe OS Dynamic Update
  • 必要に応じて言語パックやFeatures on Demand

Dynamic Updateパッケージは、原則として累積更新プログラムと同じ月のものを使用します。同じ月のSetup Dynamic UpdateまたはSafe OS Dynamic Updateが公開されていない場合は、利用可能な最新バージョンを使用するよう案内されています。(Microsoft Learn)

公式サンプルをそのまま実行しない

Microsoft Learnに掲載されているPowerShellスクリプトは、完成済みの汎用ツールではありません。Microsoft自身が、説明用のサンプルであり、十分なエラー処理を含んでいないと明記しています。(Microsoft Learn)

実行前に、少なくとも次の項目を自分の環境に合わせて変更します。

  • 元メディアのパス
  • 更新後メディアの出力先
  • 累積更新プログラムのファイル名
  • Setup Dynamic Updateのパス
  • Safe OS Dynamic Updateのパス
  • WinPEのアーキテクチャ
  • 言語パックやFeatures on Demandの要否

公式サンプルには日本語言語パック、音声合成、追加機能を統合する処理も含まれています。これらが不要な環境では、関連する変数や処理を整理してから使用します。

また、サンプルは主にsources\install.wimを前提としています。メディアがinstall.esdや分割WIMを使用している場合は、そのままでは動作しない可能性があります。

Update WinPE処理で実行される内容

Update WinPE部分では、boot.wimに含まれる各イメージを順番にマウントし、累積更新プログラムを適用します。

標準的なWindowsインストールメディアでは、boot.wimに複数のインデックスが含まれています。公式サンプルは、通常のセットアップ用イメージから次のファイルを取得します。

Windows\Boot\EFI\bootmgfw.efi
Windows\Boot\EFI\bootmgr.efi
Windows\Boot\EFI\boot.stl

その後、更新済みのboot.stlを次の場所へ配置します。

newMedia\EFI\Microsoft\Boot\boot.stl

さらに、setup.exesetuphost.exe、EFIブートマネージャーなども整合するよう更新します。単一ファイルだけではなく、展開メディア全体のバージョン不一致を避けたい場合に適した方法です。(Microsoft Learn)

方法2:更新済みOSからboot.stlを手動コピーする

対象となるUSBメディアが少ない場合や、すぐに復旧したい場合は、更新済みWindowsから手動コピーできます。

コピー元とメディアのバージョンを確認する

コピー元Windowsのバージョンとアーキテクチャは、PowerShellで確認できます。

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, OSArchitecture

展開メディア側のboot.wimは、管理者権限のコマンドプロンプトで確認します。

dism /Get-WimInfo /WimFile:E:\sources\boot.wim

E:は実際のUSBメディアや作業フォルダーのドライブ文字に置き換えてください。

Microsoftが明示している最低条件は、Windowsバージョンとアーキテクチャを一致させることです。実務上は、展開メディアへ統合したものと同じ累積更新プログラムを適用済みのOSから取得するのが最も確実です。

たとえば、Windows 11 25H2のKB5101650統合メディアには、同じ25H2、同じアーキテクチャで、KB5101650相当まで更新済みの環境から取得したboot.stlを使用します。

PowerShellでboot.stlをコピーする

管理者としてPowerShellを起動し、次のスクリプトを実行します。

$MediaRoot = "E:\"
$Source = Join-Path $env:SystemRoot "Boot\EFI\boot.stl"
$Destination = Join-Path $MediaRoot "EFI\Microsoft\Boot\boot.stl"

if (-not (Test-Path -LiteralPath $Source)) {
    throw "コピー元のboot.stlが見つかりません: $Source"
}

New-Item `
    -ItemType Directory `
    -Path (Split-Path -Parent $Destination) `
    -Force | Out-Null

Copy-Item `
    -LiteralPath $Source `
    -Destination $Destination `
    -Force

Get-FileHash -LiteralPath $Source -Algorithm SHA256
Get-FileHash -LiteralPath $Destination -Algorithm SHA256

コピー元とコピー先に表示されたSHA-256ハッシュが同じであれば、ファイル自体は正しくコピーされています。

ISOの場合は作業フォルダーで差し替える

マウントしたISOは読み取り専用なので、直接boot.stlを上書きできません。

次の流れで作業します。

  1. ISOの全ファイルを書き込み可能な作業フォルダーへコピーする
  2. 作業フォルダー内の\EFI\Microsoft\Boot\boot.stlを差し替える
  3. Windows ADKのOscdimgなどを使用して、UEFIブート可能なISOを再生成する
  4. 再生成したISOを仮想マシンまたは検証端末で起動する

ファイルをZIP圧縮して拡張子を.isoへ変更しても、ブート可能なISOにはなりません。元のBIOS・UEFIブート構造を維持して再生成する必要があります。

更新済みboot.wimからboot.stlを取り出す方法

更新済みの実機を用意できない場合は、累積更新プログラム適用後のboot.wimからboot.stlを取り出せます。

まず、含まれるインデックスを確認します。

Get-WindowsImage -ImagePath "D:\Media\sources\boot.wim"

通常のWindowsインストールメディアではインデックス2がセットアップ用ですが、カスタムWinPEでは構成が異なることがあります。表示されたイメージ名を確認して、対象インデックスを選択してください。

$BootWim = "D:\Media\sources\boot.wim"
$MountPath = "C:\Mount\WinPE"
$Destination = "D:\Media\EFI\Microsoft\Boot\boot.stl"

New-Item -ItemType Directory -Path $MountPath -Force | Out-Null
New-Item -ItemType Directory -Path (Split-Path $Destination) -Force | Out-Null

Mount-WindowsImage `
    -ImagePath $BootWim `
    -Index 2 `
    -Path $MountPath

Copy-Item `
    -LiteralPath "$MountPath\Windows\Boot\EFI\boot.stl" `
    -Destination $Destination `
    -Force

Dismount-WindowsImage `
    -Path $MountPath `
    -Discard

この方法は、boot.wimへ対象の累積更新プログラムを正しく適用済みであることが前提です。更新前のboot.wimから取り出した古いboot.stlをコピーしても、不整合は解消しません。

boot.stl更新で失敗しやすいポイント

失敗例問題点対処
sourcesフォルダーへコピーするUEFI側が参照する配置先ではない\EFI\Microsoft\Boot\boot.stlへ配置する
24H2と25H2でファイルを共用するMicrosoftの一致条件を満たさない可能性があるバージョンごとに別のファイルを管理する
x64とArm64を混在させるSecure Boot検証に必要な構成が一致しないメディアのアーキテクチャを事前確認する
未更新PCからコピーする古いboot.stlを再配置するだけになる対象更新適用済みのOSを使用する
install.wimだけ更新するWinPEやEFIブートファイルが古いまま残るboot.wimとメディア直下のEFIファイルも確認する
マウント中のISOへ上書きするISOは読み取り専用作業フォルダーへ展開してから再生成する
Secure Bootを恒久的に無効化する公式対処ではなく、セキュリティ機能を失う正しいboot.stlへ差し替えてSecure Boot有効状態で試験する
すべての0xc0430001を同じ原因と判断する通常のWindows起動障害は別原因の可能性がある展開メディア起動時のエラーかを切り分ける

特に多いのは、boot.wimへ更新を統合したことで作業が完了したと思い、メディア直下のboot.stlを更新し忘れるケースです。

更新後の確認手順

ファイルを差し替えたら、いきなり全端末へ配布せず、次の順序で確認します。

ファイルの存在を確認する

Test-Path "E:\EFI\Microsoft\Boot\boot.stl"

Trueが返ることを確認します。

コピー元とコピー先のハッシュを確認する

Get-FileHash "$env:SystemRoot\Boot\EFI\boot.stl" -Algorithm SHA256
Get-FileHash "E:\EFI\Microsoft\Boot\boot.stl" -Algorithm SHA256

両方のハッシュ値が一致していることを確認します。

Secure Bootを有効にした状態で起動する

検証端末ではSecure Bootを有効にした状態で、USB、ISO、PXEなど実際の配布方法から起動します。

少なくとも次の段階まで確認してください。

  • 0xc0430001が表示されない
  • WinPEが最後まで起動する
  • Windowsセットアップ画面が表示される
  • ストレージやネットワークドライバーを認識する
  • タスクシーケンスや自動展開処理を開始できる

可能であれば、実運用と同じ機種でWindowsのインストール完了まで試験します。WinPEの初期画面が表示されただけでは、setup.exesetuphost.exeの不整合までは検出できないためです。

よくある疑問

boot.stlだけコピーすれば直るのか

Microsoftが案内する手動対処では、更新済みOSのWindows\Boot\EFIから、展開メディアの対応フォルダーへboot.stlをコピーできます。そのため、緊急の起動復旧ではboot.stlの差し替えが有効です。(マイクロソフトサポート)

ただし、組織で継続利用する展開メディアでは、boot.wim、Setup関連ファイル、EFIブートマネージャーにも更新差が残る可能性があります。恒久対応にはUpdate WinPEスクリプトを使い、メディア全体を更新する方が適しています。

Windows 11 24H2のboot.stlを25H2へコピーしてよいか

避けるべきです。

KB5101650は24H2と25H2の両方を対象としていますが、OSビルドは異なります。Microsoftはboot.stlをWindowsバージョンとアーキテクチャに一致させるよう求めています。24H2、25H2、26H1ごとにコピー元を分けて管理してください。

別のPCからboot.stlをコピーしてよいか

Microsoftの手動手順では、更新済みデバイスのWindows\Boot\EFIフォルダーからコピーする方法が案内されています。

重要なのはPCのメーカー名ではなく、コピー元が次の条件を満たしていることです。

  • 対象メディアと同じWindowsバージョン
  • 対象メディアと同じアーキテクチャ
  • 対象メディアへ統合した更新と同等の更新状態
  • 信頼できるWindows環境から取得したファイル

インターネット上で配布されている出所不明のboot.stlは使用しないでください。

Secure Bootを無効にすれば回避できるか

Secure Bootの無効化を恒久対策にしてはいけません。

Microsoftが示している公式対処は、Secure Boot検証で使用するboot.stlを、更新後のWindowsバージョンとアーキテクチャに一致させることです。検証でも、最終的にはSecure Bootを有効にした状態で展開メディアが起動することを確認する必要があります。

まとめ:まずメディア直下のboot.stlを確認する

Windows 11の2026年7月更新を統合した展開メディアが0xc0430001で起動しない場合は、次の順序で対応します。

  1. 対象がWindows 11 24H2、25H2、26H1のどれか確認する
  2. 展開メディアのアーキテクチャを確認する
  3. \EFI\Microsoft\Boot\boot.stlの有無と更新状態を確認する
  4. 同じバージョン・アーキテクチャの更新済みOSからboot.stlをコピーする
  5. 継続利用するメディアはUpdate WinPEスクリプトで全体を更新する
  6. Secure Bootを有効にした検証端末で起動試験する
  7. 問題がなければUSB、ISO、PXE、配布ポイントへ反映する

手動対応で最も重要なのは、コピー先を間違えないことです。

コピー元:
%SystemRoot%\Boot\EFI\boot.stl

コピー先:
展開メディア\EFI\Microsoft\Boot\boot.stl

一時的な回避だけで終わらせず、今後の月例更新ではinstall.wimboot.wim、Setup Dynamic Update、EFIブートファイルを一つの更新工程として管理すると、同様のバージョン不整合を防ぎやすくなります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次