Windows took 70 GB of disk space without warning. Nothing visible in File Explorer, nothing in Disk Cleanup, yet my C: drive was full. If you develop with WSL2 or store large amounts of data there, you may be in exactly the same situation without realizing it.
The culprit is a single file: ext4.vhdx, the virtual disk containing your entire Linux distribution. I measured the problem on my own workstation before fixing it. Ubuntu was using 38 GB of real data, while the file occupied 110 GB on the Windows side. I will show you how to check your system and recover the space in five minutes.
In this article
Why your C: drive fills up even though you installed nothing
WSL2 stores your entire Linux environment in a single VHDX virtual disk, provisioned by default up to 1 TB according to Microsoft’s WSL disk-space documentation. This file uses dynamic expansion. It grows with every write—an apt update, an npm install, a download—and Windows never shrinks it automatically.
The trap comes from the separation between the two worlds. When you delete files in Ubuntu, the space becomes available inside the virtual machine. Linux sees it as free and can reuse it. Windows, however, continues to see an ext4.vhdx file at its largest historical size. The space exists on both sides, but you can use it from only one of them.
That is why Windows Disk Cleanup, WinDirStat and TreeSize do not show anything unusual. They see a large, legitimate system file—not the gap between its real contents and its size on disk.
The problem affects every WSL2 workload, not just Docker
Any large write can trigger this behavior. Copy 150 GB of photos into your Linux home directory for sorting, delete them when you are done, and the vhdx file will keep those 150 GB on your C: drive. A training dataset, a video export or an extracted backup has exactly the same effect. The content does not matter; only the amount written matters.
Docker is the most common case among developers because images, volumes and build caches accumulate quickly. A docker system prune command can free dozens of gigabytes, but only inside the virtual machine. The cleaned space remains trapped in the virtual disk until that disk is compacted. Note that Docker Desktop uses its own vhdx, docker-desktop-data, separate from your Ubuntu distribution’s file. Both can grow.
Check how much space you can recover
The check takes two minutes and compares two figures. The first is the space actually used by your distribution; the second is the size of the vhdx file as Windows sees it. The difference between them is the space you can recover.
First figure. Open your WSL terminal and measure the distribution’s real usage.
df -h /Filesystem Size Used Avail Use% Mounted on
/dev/sdd 1007G 38G 918G 4% /The Used column gives you the first figure—in this example, 38 GB. Do not rely on the Size column, which shows about 1 TB. That is WSL’s maximum provisioned size, not the capacity of your physical drive.
The vhdx location varies depending on how WSL was installed, so the most reliable approach is to have Windows find it. Open PowerShell and paste this command. It scans your user profile and displays every distribution virtual disk with its full path and size in GB.
Get-ChildItem $env:LOCALAPPDATA -Recurse -Filter ext4.vhdx -ErrorAction SilentlyContinue | Select-Object FullName, @{n="GB";e={[math]::Round($_.Length/1GB,1)}}FullName GB
-------- --
C:\Users\adrien\AppData\Local\wsl\{c16045d3-...}\ext4.vhdx 110You will get one line for each installed distribution, plus one for Docker Desktop if applicable. Copy this path carefully; you will use it in diskpart in the next step. The command deliberately targets ext4.vhdx files, which are the ones that matter. Any swap.vhdx files you find elsewhere are temporary swap files and empty themselves when WSL stops.
On my workstation, the comparison showed 38 GB actually used and a 110 GB file. More than 70 GB to recover without deleting anything. One useful distinction: a full drive is not necessarily a failing drive. The symptoms of a failing drive are different: slowdowns, unusual noises and unreadable sectors.
The diskpart procedure to compact the disk in 5 minutes
Compaction forces Windows to rewrite the vhdx file at its real size. The operation is safe for your data; the disk is attached as read-only throughout the procedure. Start by completely shutting down WSL from a terminal.
wsl --shutdownAlso close Docker Desktop, including its notification-area icon. This is the classic trap: Docker left open can restart WSL in the background, and diskpart will refuse to attach the disk. Then open an administrator Command Prompt and start the disk-management utility.
diskpartFinally, run these four commands and adapt the path to your own file—the one you found in the previous step.
select vdisk file="C:\Users\<you>\AppData\Local\wsl\<id>\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdiskCompaction displays its progress as a percentage and then returns control to you. On my workstation, the file went from 110 GB to just under 40 GB, and File Explorer reflected the change immediately. Start WSL again normally; your data has not moved.
Are Optimize-VHD and sparse mode worth using?
Two other methods exist, and you will see them in English-language discussions. The first, the PowerShell Optimize-VHD cmdlet, produces a result equivalent to diskpart but requires Hyper-V, meaning Windows Pro or Enterprise, as explained in Stephen Rees-Carter’s guide to shrinking WSL2 virtual disks. It is not available on Windows Home.
The second is sparse mode, introduced with WSL 2.0 in September 2023 and enabled with wsl --manage <distro> --set-sparse true. In theory, it returns space automatically whenever you delete files. In practice, users report on Microsoft Q&A that sparse disks sometimes stop shrinking and become impossible to compact manually. I chose not to entrust my 70 GB to such a temperamental feature and stick with diskpart, which is widely available and predictable.
| Method | Requirements | Reliability |
|---|---|---|
| diskpart, compact vdisk | None; included with every Windows edition | Excellent; the reference method |
| Optimize-VHD | Windows Pro or Enterprise with Hyper-V | Good; equivalent result to diskpart |
| WSL sparse mode | WSL 2.0 minimum | Unpredictable; bugs involving unreclaimed space have been reported |
Don’t let the algorithm decide for you
Add Assistouest to your preferred sources on Google so you can find our guides faster when you search for an IT solution.
Your action plan in brief
The WSL2 ext4.vhdx file never shrinks by itself, and the gap between its contents and its on-disk size can reach dozens of gigabytes. Four diskpart commands solve the problem in five minutes, with no risk to your data because the disk is mounted read-only. Repeat the operation periodically if you work with large volumes.
If your drive is filling up for a reason unrelated to WSL, or if you would rather leave the procedure to a professional, our remote computer troubleshooting service can diagnose this kind of storage issue in one session.
An error occurred. Please try again in a moment.