Repository navigation
Sparse disk corrupted due to lack of storage space [fix inside] #41837
Description
Windows Version
Microsoft Windows [Version 10.0.26200.9457]
WSL Version
3.0.1.0
Are you using WSL 1, WSL 2, or WSLC?
- WSL 2
- WSL 1
- WSLC
Kernel Version
6.18.40.1-1
Distro Version
Ubuntu-26.04
Other Software
No response
Repro Steps
WSL2 Ubuntu 26.04 is gone during code build - host storage space was exhausted.
So was unable to start WSL again:
>wsl
Failed to attach disk '$somepath\ext4.vhdx' to WSL2: The file or directory is corrupted and unreadable.
Error code: Wsl/Service/CreateInstance/MountDisk/HCS/ERROR_FILE_CORRUPT
If this error was unexpected, please consider searching for existing issues or filing a new issue at https://github.com/microsoft/WSL/issues.
>wsl --version
WSL version: 3.0.1.0
Kernel version: 6.18.40.1-1
WSLg version: 1.0.79
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.9457Tried to check the disk container itself and it seems to be fine:
>"c:\Program Files\qemu\qemu-img.exe" info "$somepath\ext4.vhdx"
image: $somepath\ext4.vhdx
file format: vhdx
virtual size: 1 TiB (1099511627776 bytes)
disk size: 213 GiB
cluster_size: 1048576
Child node '/file':
filename: $somepath\ext4.vhdx
protocol type: file
file length: 213 GiB (228867440640 bytes)
disk size: 213 GiB
PS > & C:\Program Files\qemu\qemu-img.exe convert -p -n -f vhdx --target-image-opts `
>> "$somepath\ext4.vhdx" 'driver=null-co,size=1099511627776'
(100.00/100%)
PS > $LASTEXITCODE
0Created a script for metadata inspection (and I think that's the most useful info in this issue):
python3 .\vhdx_inspect.py "$somepath\ext4.vhdx"
VHDX metadata inspection -- READ ONLY -- v1.1
File: $somepath\ext4.vhdx
Length: 228867440640 bytes (213.149 GiB)
Creator: Microsoft Windows 10.0.22631.0
HEADERS
#1: signature=True CRC=True sequence=614
stored CRC=4b38434e calculated=4b38434e; version=1 log_version=0
FileWriteGuid=0c7d0271-62c1-4fb3-8c18-9777350dce3c DataWriteGuid=7345863d-28ca-4593-a1e3-83934b3bef14
LogGuid=00000000-0000-0000-0000-000000000000 offset=0x100000 length=1048576
#2: signature=True CRC=True sequence=615 CURRENT
stored CRC=c9c0df39 calculated=c9c0df39; version=1 log_version=0
FileWriteGuid=0c7d0271-62c1-4fb3-8c18-9777350dce3c DataWriteGuid=7345863d-28ca-4593-a1e3-83934b3bef14
LogGuid=00000000-0000-0000-0000-000000000000 offset=0x100000 length=1048576
REGION TABLES
#1: signature=True CRC=True entries=2
BAT 2dc27766-f623-4200-9d64-115e9bfd4a08 offset=0x300000 length=9437184 required=1
Metadata 8b7ca206-4790-4b9a-b8fe-575f050f886e offset=0x200000 length=1048576 required=1
#2: signature=True CRC=True entries=2
BAT 2dc27766-f623-4200-9d64-115e9bfd4a08 offset=0x300000 length=9437184 required=1
Metadata 8b7ca206-4790-4b9a-b8fe-575f050f886e offset=0x200000 length=1048576 required=1
METADATA
File parameters caa16737-fa36-4d43-b3b6-33f0aa44e76b offset=0x10000 length=8 flags=0x4
Virtual disk size 2fa54224-cd1b-4876-b211-5dbed83bf4b8 offset=0x10008 length=8 flags=0x6
Logical sector size 8141bf1d-a96f-4709-ba47-f233a8faab5f offset=0x10010 length=4 flags=0x6
Physical sector size cda348c7-445d-4471-9cc9-e9885251c556 offset=0x10014 length=4 flags=0x6
Virtual disk ID beca12ab-b2e6-4523-93ef-c309e000c746 offset=0x10018 length=16 flags=0x6
block_size: 1048576
virtual_size: 1099511627776
logical_sector_size: 512
physical_sector_size: 4096
has_parent: False
leave_blocks_allocated: False
disk_id: 8f6d1a0c-72b5-4b12-8de0-8fe7131970d9
BAT
chunk_ratio: 4096
payload_blocks: 1048576
required_entries: 1048831
required_bytes: 8390648
region_bytes: 9437184
scanned_entries: 1048831
complete: True
payload_states: {'FULLY_PRESENT': 192803, 'NOT_PRESENT': 446338, 'ZERO': 16047, 'UNMAPPED': 393388}
bitmap_states: {'0': 255}
allocated_payload_blocks: 192803
allocated_bitmap_blocks: 0
highest_live_extent_end: 228867440640
offset_counts: {'payload:FULLY_PRESENT': {'zero': 0, 'nonzero': 192803}, 'payload:NOT_PRESENT': {'zero': 446338, 'nonzero': 0}, 'payload:ZERO': {'zero': 16047, 'nonzero': 0}, 'bitmap:0': {'zero': 255, 'nonzero': 0}, 'payload:UNMAPPED': {'zero': 368237, 'nonzero': 25151}}
nonzero_offset_duplicates: 1
retained_payload_blocks: 25151
retained_extents_beyond_eof: 0
highest_retained_extent_end: 228842274816
FINDINGS
[ERROR] BAT_OFFSET_DUPLICATE: BAT[515684] payload:UNMAPPED and BAT[10662] payload:FULLY_PRESENT share nonzero offset 0x521e00000
[ERROR] BAT_RETAINED_OVERLAP: BAT[515684] payload:UNMAPPED [0x521e00000,0x521f00000) overlaps BAT[10662] payload:FULLY_PRESENT [0x521e00000,0x521f00000)
Totals: {"ERROR": 2, "WARN": 0, "INFO": 0}
Metadata bytes read: 8596008 (8.20 MiB)
Scope: No log replay or log sequence validation; no repairs.
Scope: No ext4/filesystem check, payload scan, or parent-chain validation.
Scope: These checks do not prove compatibility with Windows' VHDX parser.
RESULT: Inconsistencies detected. Keep the original unchanged; do not guess repairs.Made a backup in advance and patched:
PS C:\Temp> python3 .\vhdx_patch_duplicate.py "$somepath\ext4.vhdx" --apply --skip-backup-check
Exact reported collision confirmed; proposed metadata passes inspector checks.
File byte offset: 0x6ef320 (7271200)
Before: 03 00 e0 21 05 00 00 00
After: 03 00 00 00 00 00 00 00
Live BAT[10662] and payload at 0x521e00000 remain unchanged.
Full-image backup check skipped by explicit request; local metadata backup is still required.
Original 12 MiB metadata saved: C:\Temp\vhdx-before-bat-fix.bin
Metadata SHA256: 7b02c11ae46caa55331eaba0fb79834b98ad547b900882c8cc22a18b155fc740
Applying OFFLINE forensic patch (no VHDX transaction-log protocol).
APPLIED AND READ BACK: only the intended 8-byte entry was written.
Next: rerun inspector, then test native Windows READ-ONLY attachment.WSL started fine:
dmesg | grep -iE 'ext4|EXT4-fs|I/O error'
[ 0.560148] EXT4-fs (sda): mounted filesystem 00000000-0000-0000-0000-000000000000 ro without journal. Quota mode: none.
[ 0.563850] EXT4-fs (sdb): mounted filesystem 00000000-0000-0000-0000-000000000000 ro without journal. Quota mode: none.
[ 4.702441] EXT4-fs (sdd): 1 orphan inode deleted
[ 4.703375] EXT4-fs (sdd): recovery complete
[ 5.894352] EXT4-fs (sdd): mounted filesystem 11fab7bc-1e48-4b26-a308-e809fe0c7470 r/w with ordered data mode. Quota mode: none.
[ 74.461029] EXT4-fs (sde): mounted filesystem a6180757-5ece-424e-a74a-81f7bfb432d9 r/w with ordered data mode. Quota mode: none.
[ 90.281539] EXT4-fs (sde): unmounting filesystem a6180757-5ece-424e-a74a-81f7bfb432d9.Finally ran Optimize-VHD and it was fine:
Optimize-VHD -Path "$somepath\ext4.vhdx" -Mode Full
>Expected Behavior
VHDX not corrupted?
Actual Behavior
Corrupted VHDX
Diagnostic Logs
No response
Activity
github-actions commentedon Oct 8, 2026
Logs are required for review from WSL team
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use
.\collect-wsl-logs.ps1 -LogProfile networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce completed please upload the output files to this GitHub issue.
See Collect WSL logs (recommended method).
If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.
andrico21 commentedon Oct 8, 2026
scripts used for troubleshooting and recovery:
vhdx_patch_duplicate.py
vhdx_inspect.py