You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Continuous hv_storvsc READ_10 errors on WSL 2.7.12 cause systemd boot timeouts #41482
Record current error count: wsl.exe -d Ubuntu-24.04 -u root -- sh -c "dmesg | grep -c hv_storvsc"
Generate filesystem read (in separate powershell): wsl.exe -d Ubuntu-24.04 -- sh -c "find /usr -maxdepth 4 -type f -readable -exec head -c 1 {} ; >/dev/null 2>&1"
Count errors again: wsl.exe -d Ubuntu-24.04 -u root -- sh -c "dmesg | grep -c hv_storvsc"
-->The count increased from 221 to 381 during on short file system scan.
Expected Behavior
Ubuntu starts normally, systemd completes initialization, and filesystem reads do not produce continuous hv_storvsc SCSI READ_10 errors.
Actual Behavior
The kernel continuously emits errors of this form: hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#542 cmd 0x28 status: scsi 0x2 srb 0x4 host 0xc0000001
Initially, systemd did not complete its boot process:
WSL (2 - init-systemd(Ubuntu-24.04)) ERROR:
WaitForBootProcess:3488: /sbin/init failed to start within 10000ms
WSL (2 - Interop) ERROR:
CreateLoginSession:2758: Timed out waiting for user session
Failed to connect to bus: No such file or directory
Disabling cloud-init using /etc/cloud/cloud-init.disabled allowed both the system and user systemd instances to reach running.
However, the hv_storvsc READ_10 errors continue and increase during filesystem reads.
Diagnostic Logs
Possibly related to #9173. A storage trace was captured using the official WSL diagnostics script: collect-wsl-logs.ps1 -LogProfile storage
The resulting archive contains identifiable Windows user paths, a device name, and organization information. It is therefore not attached to this public issue.
I can provide the original trace to the WSL team through a non-public, Microsoft-approved transfer channel upon request.
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 networking instead, following the instructions in Collect WSL logs for networking issues
Once completed please upload the output files to this GitHub issue.
If you choose to email these logs instead of attaching them to the bug, please send them to [email protected] 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'.
Attached is the requested WSL storage trace collected with:
powershell: collect-wsl-logs.ps1 -LogProfile storage
For privacy reasons, identifiable values in text-based files were replaced: Windows user name, device name, organization name
The binary logs.etl storage trace was not modified.
Hi Volker Bremer (@bremerv) .
This seems to be an issue with the swap.vhdx. The exact cause is not clear yet. But you could try disable swap in the .wslconfig file with:
[wsl2]
swap=0
Then wsl --shutdown and check if the problem persists.
Thank you. Disabling WSL swap with "swap=0" resolved the issue.
After wsl.exe --shutdown, swapon --show returned no active swap device as expected.
I cleared the kernel log and repeated the filesystem read test. No new hv_storvsc READ_10 errors were generated (result with wsl.exe -d Ubuntu-24.04 -u root -- sh -c "dmesg | grep -c hv_storvsc" returned 0 before an after some file system reads).
System and user systemd sessions both remain in the running state.
Activity
github-actions commentedon Aug 30, 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 [email protected] 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'.
bremerv commentedon Aug 30, 2026
Attached is the requested WSL storage trace collected with:
powershell: collect-wsl-logs.ps1 -LogProfile storage
For privacy reasons, identifiable values in text-based files were replaced: Windows user name, device name, organization name
The binary logs.etl storage trace was not modified.
WslLogs-2026-08-30_13-41-12-redacted.tar.gz
github-actions commentedon Aug 30, 2026
Diagnostic information
chemwolf6922 commentedon Aug 31, 2026
Hi Volker Bremer (@bremerv) .
This seems to be an issue with the swap.vhdx. The exact cause is not clear yet. But you could try disable swap in the
.wslconfigfile with:Then
wsl --shutdownand check if the problem persists.bremerv commentedon Aug 31, 2026
Hi Feng Wang (@chemwolf6922),
Thank you. Disabling WSL swap with "swap=0" resolved the issue.
After wsl.exe --shutdown, swapon --show returned no active swap device as expected.
I cleared the kernel log and repeated the filesystem read test. No new hv_storvsc READ_10 errors were generated (result with wsl.exe -d Ubuntu-24.04 -u root -- sh -c "dmesg | grep -c hv_storvsc" returned 0 before an after some file system reads).
System and user systemd sessions both remain in the running state.
tnielens commentedon Sep 28, 2026
I did face the same issues after an upgrade to windows 11 with Fedora 44
Disabling the swap resolved the issue as well for me.
New WSL distro recipe follow-up: rehearsal, signed sums, schema and s…