WSLC vhdx very heavy #41518

Two different things can produce "I pruned but the vhdx didn't shrink", and the fix is opposite in each case. Worth finding out which one you're in before trying more compaction.

First, check whether the file is sparse:

# find the actual path
Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss |
  Get-ItemProperty | Select-Object DistributionName, BasePath

# then, against the vhdx it reports
fsutil sparse queryflag "C:\Users\<you>\AppData\Local\wsl\{guid}\ext4.vhdx"

If it reports "This file is set as sparse"

That is why diskpart did nothing. Diskpart refuses sparse VHDs outright:

Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.

It fails at the attach vdisk step, and if you ran the commands interactively it is easy to miss the failure and assume compact vdisk ran.

The good news is you probably have nothing to reclaim. On a sparse VHD, WSL punches holes as the guest discards blocks, so the space goes back to Windows within a few seconds of the delete. What does not change is the file's logical size — 39 GB is what Explorer's "Size" field shows, while the actual allocation is much smaller. Right-click the vhdx → Properties and compare Size against Size on disk. If "Size on disk" is close to your real usage, nothing is wrong and there is nothing to compact.

If it reports "This file is NOT set as sparse"

Then compaction is the right move, and it needs the disk fully detached — WSL must be shut down, and the attach must be read-only:

wsl --shutdown

Then from an elevated prompt, diskpart /s compact.txt with:

select vdisk file="C:\Users\<you>\AppData\Local\wsl\{guid}\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Missing wsl --shutdown, or attaching without readonly, is the usual reason compact vdisk reports success but reclaims nothing. If you have the Hyper-V module available, Optimize-VHD -Path <path> -Mode Full does the same job with clearer errors.

The part that catches most people

Pruning inside the guest never shrinks the host file on its own. WSL virtual disks only ever grow; deleting data marks blocks free inside the ext4 filesystem, but the vhdx keeps its allocation until something either compacts it or punches holes in it. So the sequence has to be: clean up inside first, then compact from the Windows side. Doing only the first half looks exactly like your symptom.

fstrim used to be a required middle step. On current WSL the ext4 volume is mounted with discard, so TRIM is already continuous and running it manually changes nothing.

One caveat specific to your case: I've verified this against regular WSL distro vhdx files, not the wslc-dedicated disk, so I don't know for certain that wslc registers its disk under Lxss the same way. If the registry query above doesn't list it, the path is worth confirming before running diskpart against anything.