STG_S_CANNOTCONSOLIDATE 0x00030206 Fix for Windows

This isn't a crash. It's Windows saying the storage file is already fine, so consolidation was skipped. Here's when it shows up and why you can ignore it.

What's actually happening when you see 0x00030206

You're running a storage operation — typically a VHDX compaction, a Storage Spaces optimization, or a defrag pass on a Windows Server 2019/2022 box — and the operation finishes green. Then the log or console spits out STG_S_CANNOTCONSOLIDATE (0X00030206). Most admins see the word "CANNOT" and immediately start hunting for a broken volume. Don't. The trailing phrase "(commit succeeded)" tells you everything: the operation you asked for completed. The consolidation step just had nothing to do.

Real trigger scenario: you've got a dynamically expanding VHDX on a ReFS volume, you deleted 400 GB of old backup files inside the guest, then you detach and run Optimize-VHD -Mode Full. The VHDX shrinks by 12 GB, not the 380 GB you expected, and the event log on the host shows 0x00030206 at the end of the pass. That's normal. The file was already in a state where further consolidation would be a no-op or would move blocks for zero benefit.

The root cause, in plain English

Windows storage files (VHD, VHDX, storage tier files, and the internal files backing Storage Spaces) have two concepts: the allocated size and the used size. Consolidation is the operation that walks the file's block map and tries to move live data together so free regions can be released back to the parent volume.

When the storage stack runs consolidation, it first asks a simple question: is there anything to gain? If the file is already contiguous, or if the reclaimable space is below the threshold the stack considers worth the I/O, it returns STG_S_CANNOTCONSOLIDATE. That's an S prefix, not an E — it's a success-class HRESULT. Windows treats it as informational, which is why the operation reported success anyway.

The reason step 3 works in the fixes below is this: the error is almost never the failure itself. It's the messenger for "your expectation of how much space should come back didn't match reality." If you're chasing 0x00030206 specifically, you're usually chasing the wrong thing.

Fixes — in order of what to actually try

Confirm the operation really succeeded. Open Event Viewer, filter the Microsoft-Windows-Hyper-V-VMMS-Admin or Microsoft-Windows-StorageSpaces-Driver/Operational log depending on your scenario. Look for the entry after 0x00030206. If it says the operation completed, you're done — no action needed.
Check the actual free space inside the VHDX, not on the host. Mount the VHDX read-only and run defrag /A /V from inside. If the volume reports fragmentation under 10% and free space is already consolidated, the host-side compaction has nothing further to do.
Zero out free space inside the guest before compacting. This is the fix that actually changes outcomes. Creating 400 GB of files then deleting them leaves the blocks marked as written in the VHDX. They look used to the host even though the guest sees them as free. Run inside the guest:
```
cipher /w:C:\ScratchVolume
```
Then shut down cleanly and run:
```
Optimize-VHD -Path "D:\VMs\Web01\disk0.vhdx" -Mode Full
```
The VHDX shrinks by the real amount this time.
For Storage Spaces, retry after a trim. On Windows Server 2022, run:
```
Optimize-Volume -DriveLetter S -ReTrim -Verbose
```
If the drive returns 0x00030206 immediately, the pool is already balanced. Move on.
Restart the relevant service if the error persists across reboots. For VHD/VHDX work, that's the Virtual Disk Service:
```
net stop vds
net start vds
```
This clears a stale allocation map that occasionally sticks after a failed compaction earlier in the day.

If it still reports 0x00030206

Run Get-VHD -Path "D:\VMs\Web01\disk0.vhdx" | Format-List * and compare FileSize against Size. If FileSize is close to Size, the file is fully allocated and there's nothing to consolidate — the error is correct. If FileSize is dramatically larger than what the guest reports as used, you've likely got a ReFS integrity stream or a pending checkpoint holding blocks. Check for checkpoints with Get-VMSnapshot and merge or delete any that got orphaned.

One more thing worth checking: the host volume itself. If the parent disk is over 85% full, Windows quietly refuses deep consolidation passes to avoid filling the volume mid-operation. That refusal surfaces as 0x00030206 too. Free up space on the host and rerun.

Short version: 0x00030206 is not a bug. It's Windows telling you the storage file is already in the shape you wanted. Verify the result, then stop worrying about the code.