Windows 11のバックアップで「十分な記憶域がありません」0x8004231FとWinREを修復した事例

原因を追跡したらWinRE回復パーティションへ行き着いた事例

発生・調査開始：2026年8月22日
修復・正常動作確認：2026年8月23日

Windows 11に搭載されている「バックアップと復元（Windows 7）」を使用してシステムイメージを作成しようとしたところ、突然バックアップが失敗しました。

表示された内容は、次のようなものでした。

1. エラー - ボリューム シャドウ コピー サービスの操作エラーが発生しました: (0x8004231f)
2. シャドウ コピーの記憶域ファイルまたはその他のシャドウ コピー データを作成するために利用できる十分な記憶域がありません。

しかし、Cドライブにもバックアップ先のNASにも十分な空き容量がありました。
「十分な記憶域がありません」と言われても、どの記憶域が不足しているのかが分かりません。
この疑問を出発点に、約2日間かけて原因の切り分けと修復を行いました。

本記事は、その際の経過を事例として記録したものです。同じエラー番号でも原因が異なる可能性があるため、すべての環境にそのまま適用できる手順ではありません。

1．発生した症状

使用していたのは、Windows 11 Homeのコントロールパネルから利用できる「バックアップと復元（Windows 7）」です。

コントロール パネル
↓
バックアップと復元（Windows 7）
↓
システムイメージを含むバックアップ

バックアップ先はNAS上の共有フォルダーでした。

バックアップを開始すると、シャドウコピーの作成段階で停止し、最終的に次のエラーが表示されました。

0x8004231F

コマンドラインから実行した場合も、同じ結果になりました。

wbadmin start backup -backuptarget:\\NAS名\共有フォルダー -allcritical -quiet

バックアップ対象として、次のボリュームが表示されました。

1. ESP（EFIシステムパーティション）
2. OS（C:）
3. WINRETOOLS

この時点で重要だったのは、バックアップ対象がCドライブだけではなかったことです。

2．まず確認した空き容量

最初に、一般的な空き容量不足を確認しました。

Cドライブ

Cドライブには約300GB以上の空きがありました。

バックアップ先のNAS

NASにも約5.6TBの空きがありました。

この結果から、少なくとも次の2つは単純な容量不足ではありませんでした。

• Cドライブの通常の空き容量
• NASの通常の空き容量

3．WindowsとVSSの基本診断

次に、Windowsのシステム破損やVSSの異常を確認しました。

システムファイルチェッカー

sfc /scannow

結果は正常でした。

• Windows リソース保護は、整合性違反を検出しませんでした。

DISM

DISM /Online /Cleanup-Image /RestoreHealth

DISMによる修復も実施しましたが、バックアップ障害は改善しませんでした。

VSS Provider

vssadmin list providers

登録されていたProviderはMicrosoft純正のみでした。

• Microsoft Software Shadow Copy provider 1.0

VSSサービス

VSSサービスとMicrosoft Software Shadow Copy Providerサービスは、どちらも実行中でした。

sc query vss

sc query swprv

単純にサービスが停止していたわけではありませんでした。

4．VSS Writerのタイムアウト

バックアップ失敗後に、次のコマンドを実行しました。

vssadmin list writers

すると、複数のVSS Writerが次の状態になっていました。

• 状態: [7] 失敗
• 最後のエラー: タイムアウト

タイムアウトが確認されたWriterには、次のようなものがありました。

1. System Writer

2. ASR Writer

3. WMI Writer

4. Registry Writer

5. COM+ REGDB Writer

6. MSSearch Service Writer

7. Shadow Copy Optimization Writer

再起動直後には正常へ戻るものの、バックアップを開始すると再びタイムアウトする状態でした。

つまり、VSSサービスそのものが常時停止しているのではなく、バックアップ処理を開始した際に、複数のWriterが応答できなくなるように見えました。

ただし、この時点では、どのWriterが最初に失敗したのかまでは特定できませんでした。

5．ShadowStorageを拡張しても改善しなかった

CドライブのShadowStorageは、当初の最大値が約9.15GBでした。

念のため、次のコマンドで上限を20％へ拡張しました。

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=20%

変更後は次の状態になりました。

シャドウ コピーの記憶域の最大領域:

91.5GB（20%）

ただし、この91.5GBが直ちに占有されたわけではありません。必要に応じて使用できる最大値を拡大したものです。

拡張後も、バックアップは同じ 0x8004231F で失敗しました。

したがって、少なくとも本事例では、CドライブのShadowStorage上限だけが原因ではありませんでした。

6．転機となった「システムの保護」の実験

調査の転機になったのは、Windowsの「システムの保護」で復元ポイントを作成したことでした。

保護対象を変えながら、復元ポイントを手動で作成しました。

Cドライブのみ

結果：成功

CドライブとDellのImage領域

結果：成功

CドライブとDELLSUPPORT領域

結果：成功

CドライブとWINRETOOLS領域

結果：失敗

エラー：0x8004231F

この実験により、次の再現条件が確認できました。

WINRETOOLSをシステム保護の対象に含めると、復元ポイントの作成でも同じエラーが発生する。

これにより、「バックアップと復元（Windows 7）」だけの問題ではなく、WINRETOOLSを含むVSS処理に問題がある可能性が高まりました。

なお、通常、WINRETOOLS、Image、DELLSUPPORTなどの回復用パーティションを「システムの保護」の対象にする必要はありません。この切り替えは、あくまで原因を絞り込むための一時的な検証でした。

7．WinREを無効化するとバックアップが成功した

Windows回復環境の状態を確認しました。

reagentc /info

当初は、次の場所にWinREが登録されていました。

Windows RE の状態: Enabled

Windows RE の場所: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE

切り分けのため、いったんWinREを無効化しました。

reagentc /disable

その後、再びバックアップを実行したところ、これまで失敗していたシステムイメージを含むバックアップが正常に完了しました。

この結果から、WinREまたはWINRETOOLSがバックアップ失敗へ強く関係していることが分かりました。

ただし、WinREを無効にしたままでは、スタートアップ修復やシステムイメージからの回復など、Windows標準の回復機能が使えません。

そのため、バックアップが成功しただけでは修復完了とはいえません。

8．WinREを再有効化できない

WinREを元へ戻すため、次のコマンドを実行しました。

reagentc /enable

ところが、次のメッセージが表示されました。

Windows RE は、BitLocker ドライブの暗号化が有効になっているボリュームでは有効にできません。

このPCはWindows 11 Homeでしたが、Cドライブの暗号化状態を調べると、次の状態でした。

Get-BitLockerVolume

結果の概要は次のとおりです。

VolumeStatus         : FullyEncrypted

EncryptionPercentage : 100

ProtectionStatus     : Off

KeyProtector         : {}

manage-bde でも、次の結果になりました。

暗号化された割合: 100.0%

保護状態: 保護はオフ

キーの保護機能: 見つかりません

つまり、CドライブはBitLocker形式で完全に暗号化されていましたが、保護状態はオフで、キー保護機能も登録されていない特殊な状態でした。

一方、TPM自体は正常でした。

TpmPresent : True

TpmReady : True

TpmEnabled : True

TpmActivated : True

TpmOwned : True

9．WinRE本体の所在確認

WinREの実体である Winre.wim を検索しました。

dir \winre.wim /s /a

次の場所で発見しました。

C:\Windows\System32\Recovery\Winre.wim

ファイルサイズは次のとおりでした。

1,078,612,329バイト

DISMでイメージを検査しました。

dism /Get-WimInfo /WimFile:C:\Windows\System32\Recovery\Winre.wim

結果：

インデックス: 1

名前: Microsoft Windows Recovery Environment (amd64)

説明: Microsoft Windows Recover Environment (amd64)

 
操作は正常に完了しました。

この結果から、Winre.wim は少なくともWIMイメージとして正常に読み取れることを確認しました。

なお、調査中に実行した reagentc /disable には、WinREイメージを回復パーティション側から C:\Windows\System32\Recovery へ戻す動作があります。

そのため、障害発生前から Winre.wim がCドライブに存在していたのか、今回の無効化操作でCドライブへ移されたのかは断定していません。

10．旧WINRETOOLSの状態

ディスク構成は次のようになっていました。

Partition 1   ESP             300MB

Partition 2   MSR             128MB

Partition 3   Windows C:      約457GB

Partition 4   WINRETOOLS      約1,096MB

Partition 5   Image           約16GB

Partition 6   DELLSUPPORT     約1,530MB

WINRETOOLSへ一時的にドライブ文字 R: を付けて確認しました。

R:\Recovery

は存在しましたが、次のフォルダーはありませんでした。

R:\Recovery\WindowsRE

確認時点では、WINRETOOLSは実質的に空の状態でした。

ただし、前述のとおり、それが障害発生前から空だったのか、reagentc /disable によってWinREイメージがCドライブへ移された結果なのかは、現存する記録だけでは断定できません。

11．旧WINRETOOLSの容量上の問題

旧WINRETOOLSの容量は約1,096MBでした。

一方、Winre.wim のファイルサイズは約1,079MBでした。

旧WINRETOOLS：約1,096MB

Winre.wim：約1,079MB

単純計算上の残り：約17MB

数値上は収まるように見えますが、配置後の空きはほとんどありません。

WinREはWindows Updateによって更新されるため、イメージの置換や作業領域として一定の空き容量が必要になります。約17MBでは、今後の更新を安定して処理できる余裕がありません。

このため、旧WINRETOOLSへそのままWinREを戻す方法は採用しませんでした。

12．WINRETOOLSの再構築

重要な注意

ここからの作業には、パーティションの縮小、削除、作成、フォーマットが含まれます。

本記事に掲載しているパーティション番号やボリューム番号は、今回のPC固有のものです。別のPCでは番号や並びが異なります。対象を誤ると、Windows、EFI、メーカー回復領域、個人データを失う可能性があります。実行する場合は、必ず次の情報を照合する必要があります。

• パーティション番号
• 容量
• ラベル
• 種類
• オフセット
• 前後の配置
• detail partitionの内容

本事例では、重要データとバックアップを確認したうえで作業しました。

Cドライブを2GB縮小

旧WINRETOOLSはCドライブの直後に配置されていました。

そこで、Cドライブを2,048MB縮小しました。

select partition 3

shrink desired=2048 minimum=2048

結果：

ボリュームは、次の方法で正常に縮小されました: 2048 MB

空の旧WINRETOOLSを削除

対象を detail partition で確認しました。

種類: de94bba4-06d1-4d40-a16a-bfd50179d6ac

属性: 0x8000000000000001
 
ラベル: WINRETOOLS
 
容量: 約1,096MB

確認後、空の旧WINRETOOLSを削除しました。

delete partition override

これにより、Cドライブから確保した約2GBと、旧WINRETOOLSの約1.1GBが連続した未割り当て領域になりました。

新しいWINRETOOLSを作成

約3,144MBの新しい回復パーティションを作成しました。

create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac

gpt attributes=0x8000000000000001

format quick fs=ntfs label="WINRETOOLS"

assign letter=R

作成後の状態は次のとおりです。

容量: 約3,144MB

ファイルシステム: NTFS

ラベル: WINRETOOLS

種類: Windows回復パーティション

属性: 0x8000000000000001

Dellの以下の領域には変更を加えていません。

Image

DELLSUPPORT

EFIシステムパーティションにも変更を加えていません。

13．Winre.wimを新しいWINRETOOLSへ配置

新しいWINRETOOLSに、標準的な配置フォルダーを作成しました。

mkdir R:\Recovery\WindowsRE

次に、WinREイメージをコピーしました。

xcopy /h /r /y C:\Windows\System32\Recovery\Winre.wim R:\Recovery\WindowsRE\

コピー中の破損がないことを確認するため、コピー元とコピー先のSHA-256ハッシュを比較しました。

コピー元

5082de2828cecaec024ecebaf2ef14eb1da534a73f05cd7a4c855c59bd50375c

コピー先

5082de2828cecaec024ecebaf2ef14eb1da534a73f05cd7a4c855c59bd50375c

完全に一致しました。

コピー後も、新しいWINRETOOLSには約2.2GBの空きが残りました。

14．WinREの再登録と有効化

新しいWinREの場所を登録しました。

reagentc /setreimage /path R:\Recovery\WindowsRE

結果：

ディレクトリは次に設定されています:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE

REAGENTC.EXE: 操作は成功しました。

続いて、WinREを有効化しました。

reagentc /enable

今度は正常に完了しました。

最終確認：

reagentc /info

結果：

Windows RE の状態: Enabled

Windows RE の場所: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE

ブート構成データ（BCD）ID: cc7cce0a-9ed2-11f1-a24e-98597a2ad4f5

Windows RE バージョン: 10.0.26100.9168

最後に、一時的に付与していたドライブ文字 R: を解除し、WINRETOOLSを再び非表示状態へ戻しました。

15．修復後のバックアップ試験

WinREを有効化した状態で、再度Windowsバックアップを実行しました。

結果は正常終了でした。

wbadmin get versions

確認されたバックアップ：

バックアップ時間: 2026/08/23 18:30

バックアップ場所: \\NAS名\バックアップ共有

回復可能: 

 ボリューム

 ファイル

 アプリケーション

 ベア メタル回復

 システム状態

単なるファイルコピーではなく、ベアメタル回復とシステム状態を含むバックアップとして正式に登録されました。

16．VSS Writerの最終確認

バックアップ完了後に、再びVSS Writerを確認しました。

vssadmin list writers

修復前にタイムアウトしていたWriterを含め、すべて次の状態になりました。

状態: [1] 安定

最後のエラー: エラーなし

正常を確認した主なWriter：

・ Task Scheduler Writer

・ VSS Metadata Store Writer

・ Performance Counters Writer

・ System Writer

・ ASR Writer

・ Shadow Copy Optimization Writer

・ MSSearch Service Writer

・ WMI Writer

・ Registry Writer

・ COM+ REGDB Writer

17．セキュリティソフト再導入後の確認

修復後、ESET HOME Security Premiumを導入しました。

ESETの初期検査とアップデート完了後も、WinREとVSS Writerを確認しました。

WinRE

Windows RE の状態: Enabled

VSS Writer

全Writer:

状態 [1] 安定

最後のエラー: エラーなし

本事例では、ESET導入後もWinRE、VSS、Windowsバックアップに異常は確認されませんでした。

したがって、ESETが今回の原因だったことを示す証拠は得られていません。

18．この事例から分かったこと

今回の「十分な記憶域がありません」というメッセージは、完全な誤報だったとは言い切れません。

しかし、利用者が最初に確認する次の領域には、十分な空きがありました。

Cドライブ

バックアップ先NAS

CドライブのShadowStorage

一方で、システムイメージの対象にはWINRETOOLSも含まれていました。

旧WINRETOOLSは約1.1GBで、約1.08GBの Winre.wim を安定して収容し、将来の更新にも対応するには余裕が不足していました。

つまり、本事例で重要だったのは、

「空き容量があるか」ではなく、「どのボリュームに、何のための空き容量が必要なのか」

19．原因について断定できることと、できないこと

確認できたこと

• Windowsバックアップが 0x8004231F で失敗した
• バックアップ後に複数のVSS Writerがタイムアウトした
• CドライブとNASには十分な空きがあった
• CドライブのShadowStorageを拡張しても改善しなかった
• Cドライブ単独では復元ポイントを作成できた
• WINRETOOLSを含めると復元ポイント作成に失敗した
• WinREを無効化するとバックアップが成功した
• 旧WINRETOOLSは約1.1GBだった
• Winre.wim は約1.08GBだった
• 新しい約3.1GBのWINRETOOLSへWinREを配置できた
• WinREを再登録し、有効化できた
• WinRE有効状態でもWindowsバックアップが成功した
• 修復後はVSS Writerが全件正常になった

断定できないこと

• Windows UpdateがWinREを移動させたのか
• 過去のリカバリー操作が直接の原因だったのか
• TPMやデバイス暗号化操作が起点だったのか
• ESETのアンインストールが関係していたのか
• 障害発生前から旧WINRETOOLSが空だったのか
• 0x8004231F が常にWinREパーティションの問題を意味するのか

これらを特定できる直接的なログは残っていませんでした。

そのため、本事例の原因は次のように表現するのが正確だと考えます。

旧WINRETOOLSの容量とWinREイメージの配置・登録に不整合があり、それがVSSおよびWindowsバックアップ失敗へ関係していた可能性が極めて高い。

20．同じ症状が出た場合の確認順序

同じエラーが出ても、いきなり回復パーティションを削除してはいけません。

まず、次の順で確認することをおすすめします。

1．通常の空き容量

Cドライブ

バックアップ先

2．VSS Writer

vssadmin list writers

3．VSS Provider

vssadmin list providers

4．ShadowStorage

vssadmin list shadowstorage

5．WinREの状態

reagentc /info

6．ディスク構成

diskpart

list disk

select disk 0

list partition

list volume

7．Winre.wimの所在

dir \winre.wim /s /a

8．Winre.wimの正常性

dism /Get-WimInfo /WimFile:C:\Windows\System32\Recovery\Winre.wim

ここまで確認して初めて、WINRETOOLSの容量や再構築を検討します。

21．作業上の重要な注意

パーティション番号やボリューム番号はPCごとに異なります。

本記事の例では、

Partition 4

Volume 2

がWINRETOOLSでしたが、別のPCでも同じとは限りません。

番号だけを見て削除やフォーマットを実行してはいけません。

必ず次を確認してください。

ラベル

容量

パーティション種類

属性

前後の配置

detail partitionの結果

また、作業前に次を準備してください。

• 重要データのバックアップ
• Windowsインストールメディア
• メーカーの回復手段
• 暗号化回復キーの確認
• 電源が安定した環境
• 作業記録

自信がない場合は、メーカーサポートや専門業者への相談をおすすめします。

22．まとめ

今回の調査は、次の疑問から始まりました。

「十分な記憶域がありません」と言われたが、いったいどこの容量が足りないのか。

CドライブにもNASにも十分な空きがあり、ShadowStorageを拡張しても改善しませんでした。

復元ポイントの作成対象を一つずつ切り替えたことで、WINRETOOLSを含めた場合に障害が再現することが分かりました。

その後、旧WINRETOOLSの容量が約1.1GBしかなく、約1.08GBのWinREイメージを安定して収容する余裕がないことを確認しました。

WINRETOOLSを約3.1GBへ再構築し、WinREを配置、再登録した結果、次の状態を取り戻すことができました。

Windows RE: Enabled

Windowsバックアップ: 正常完了

ベアメタル回復: 利用可能

VSS Writer: 全件安定

ESET導入後: 正常

「容量不足」という表示は、必ずしもCドライブやバックアップ先を指しているとは限りません。

システムイメージでは、EFIや回復パーティションなど、普段は見えない領域も処理対象になります。

同じエラーに遭遇した方にとって、本事例が、

「こんなこともあるのか」

と、調査の視点を広げる一例になれば幸いです。