hvsocket new-session transport dies after `wsl --terminate` and after Modern Standby resume (accept4 110); separately, Relay processes stick in accept(12) and log every ~62s until SIGKILL

[axiom-ncis]

Windows Version

Microsoft Windows [Version 10.0.26200.8973]

WSL Version

2.7.11.0 (earlier incidents reproduced on 2.7.10.0)

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2 (6.18.33.2-microsoft-standard-WSL2)

Distro Version

Ubuntu 24.04.4 LTS (systemd enabled)

Other Software

Docker Desktop 4.84.0.234817 (engine 29.6.2), WSL integration enabled for the Ubuntu distro.

Host is an always-on automation machine (MSI laptop, S0 Modern Standby capable). It runs scheduled tasks that invoke wsl.exe headlessly, plus long-lived MCP-style client processes that hold wsl.exe bridges open.

Repro Steps

Two related failure modes on the same host. (A) is deterministic and was found on 2026-08-07 while running a planned recovery drill; (B) and (C) are the field occurrences that led to it.

A. Deterministic: wsl --terminate induces the failure from a healthy baseline

1. Start from a verified-healthy state: zero UtilAcceptVsock errors on the current boot, zero orphaned Relay processes, Docker Desktop WSL integration working (/var/run/docker.sock present in the distro), distro serving normally.
2. wsl.exe --terminate Ubuntu — returns exit 0, "The operation completed successfully."
3. Re-enter the distro with any command, which relaunches it: wsl.exe -d Ubuntu -- /bin/true.
4. Within a few minutes, every new session attempt fails:
   Catastrophic failure / Error code: Wsl/Service/E_UNEXPECTED (exit 127).

What is notable is what keeps working: the distro is still Running per wsl.exe -l -v, its own processes keep serving on forwarded ports (our in-distro HTTP service answered 200 throughout), and the service itself answers. Only creation of new sessions is dead.

Docker Desktop's user-distro integration dies with it (no /var/run/docker.sock, no docker-desktop-user-distro proxy process inside the distro), and its retry loop then repeatedly re-attempts the crossing against the already-broken transport.

In our capture the kernel logged 2,421 UtilAcceptVsock errors in ~6 minutes, with ZERO orphaned Relay processes present — i.e. this mode does not require the Relay accumulation described in (C).

5. Recovery required the full ladder: stop Docker Desktop → wsl --shutdown → start Docker Desktop. A second wsl --terminate is not sufficient, and re-entering the distro just reproduces the wedge.

B. Resume-triggered (observed twice; not reproducible on demand)

Leave the machine to enter Modern Standby / hibernate, then resume.

• 2026-08-04: entered Modern Standby 06:45:03 local. Immediately before sleep, Windows logged Kernel-Power event 40: \Driver\vpcivsp for ROOT\VPCIVSP\0000 "stopped the power transition". Resumed 17:29:58. Starting 51 seconds after resume (17:30:51) and continuing until reboot at 17:56, all 40 subsequent new-session attempts failed identically (log lines under Actual Behavior).
• 2026-07-16: Windows logged exit from Modern Standby at 07:53:05; a WslLogs/hvsocket trace captured 48 seconds later already shows the broken state.

C. Relay accumulation under sustained headless wsl.exe churn

Long-running automation that repeatedly spawns wsl.exe accumulates in-VM Relay processes that never exit (details under Actual Behavior). A deliberate churn test on 2026-07-16 (~80 launches in ~22 minutes) preceded a wedge; a single clean probe pair on 2026-08-05 did not reproduce it. We have not isolated which client exit mode strands a Relay — Windows-side client lifecycle instrumentation is now deployed here and we can supply correlated data on request.

Expected Behavior

1. wsl --terminate <distro> should be a safe, supported way to restart a distro. Re-entering the distro afterwards should create a working session, not leave the host half of hvsocket unable to complete new-session connects while the service and VM remain up.

2. Resume from Modern Standby / hibernate should not leave new-session creation broken while everything else (the service, the VM, the distro's own processes, established connections and port forwards) keeps working.

3. A Relay process whose Windows client has disconnected should exit or be reaped. It should not remain forever in accept(12) emitting a kernel error every ~62 seconds, and it should not require SIGKILL from inside the VM to clear.

4. When the transport does break, the failure should be distinguishable from a distro-down condition. Wsl/Service/E_UNEXPECTED with the distro still reporting Running gives an operator no actionable signal, and the recovery that is actually required (wsl --shutdown plus a Docker Desktop restart) is much heavier than the failure appears to warrant.

Actual Behavior

Signature 1 — new sessions fail after resume (and after wsl --terminate)

Every new-session attempt produced this pair in the kernel log, from a fresh SessionLeader each time (40 consecutive occurrences on 2026-08-04, 17:30:51 → 17:54:31):

WSL (<pid> - SessionLeader) ERROR: UtilAcceptVsock:273: accept4 failed 110
WSL (<pid> - SessionLeader) ERROR: operator():1263: UtilAcceptVsock() failed for session leader 110

(110 = ETIMEDOUT.) The in-VM side forks a session leader that listens and times out; the Windows half never connects. On the client side this surfaces as:

Catastrophic failure
Error code: Wsl/Service/E_UNEXPECTED

Throughout, wsl.exe -l -v kept reporting the distro Running, established connections and port forwards kept working, and services inside the distro kept serving. Only new session creation was dead. A host reboot (2026-08-04) or wsl --shutdown + Docker Desktop restart (2026-08-07) restored it.

An earlier episode (2026-08-03) ended the same way with Wsl/Service/E_UNEXPECTED on session creation.

Signature 2 — Relay stuck in accept(12), forever, until SIGKILL

Individual in-VM Relay processes (comm exactly Relay) enter a permanent stuck-accept state while their SessionLeader parent is still alive, and are only later reparented to PID 1 when that parent exits. Each emits exactly one kernel error every ~62 seconds, indefinitely:

WSL (<pid> - Relay) ERROR: UtilAcceptVsock:246: Waiting for abnormally long accept(12)

Controlled observation (2026-08-05, WSL 2.7.11), from 5-minute monitoring snapshots:

• 20 consecutive samples at zero errors.
• One Relay stuck at ~16:42Z; error count then rose linearly 1, 6, 11, 17 … 62, 66 — one per ~62 s — with all 66 errors attributed to that single PID and no other PID contributing.
• At 16:43:47Z the process was still parented to its live SessionLeader; by 16:49:02Z it had become PPID 1.
• SIGTERM was ignored. SIGKILL removed it and the error stream stopped instantly and stayed flat across five subsequent samples (~17 minutes).

On 2026-08-06 a population of 10 such Relays (ages 4.6–21.9 h, ~250 attributed errors each) accumulated and was cleared the same way.

SIGTERM was ignored without exception: across both removals, 11 of 11 stuck Relays ignored SIGTERM (bounded 10–15 s waits) and every one exited only on SIGKILL. Removal had no observable effect on the distro, established connections, Docker, or running services.

Earlier episodes (2026-07-14 / 07-16) accumulated 37–42 such Relays and ended in full new-session failure.

Possibly related

• WSL is non-responsive after waking from hibernate #8696 — WSL non-responsive after waking from hibernate.
• Error code: Wsl/Service/E_UNEXPECTED #13159 / Error code: Wsl/Service/E_UNEXPECTED #14014 — Wsl/Service/E_UNEXPECTED; Error code: Wsl/Service/E_UNEXPECTED #14014's WPA logs show WslCorePort sequence-number desync, which is consistent with the post-resume accept timeouts above.

Cited as possibly-related symptoms, not asserted duplicates.

Diagnostic Logs

Available on request — please tell us the preferred private channel for the trace:

• WslLogs / hvsocket ETW trace, 1.37 GB, captured 2026-07-16 at 07:53:53, i.e. 48 seconds after the Modern Standby resume that broke that boot. Too large to attach here.
• Persistent journald records for every episode listed above, including per-PID attribution of each UtilAcceptVsock error.
• 5-minute health snapshots spanning the 2026-08-05 and 2026-08-06 events (relay census with PID/PPID/session-ID/age, cumulative and delta error counts) — these are what produced the linear 1-per-62s attribution above.
• Windows Kernel-Power event sequences for the resume episodes, including the id-40 \Driver\vpcivsp "stopped the power transition" entry.
• Full terminal transcript of the 2026-08-07 wsl --terminate reproduction, including the 2,421-errors-in-6-minutes capture and the recovery ladder.

Happy to re-run the deterministic reproduction (A) with any specific tracing enabled if that would help — it reproduces on demand here.

[github-actions]

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:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

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.

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'.

[axiom-ncis]

Additional WSL 2.7.11 occurrence and attended recovery evidence:

• On the same WSL boot, two bare Relay processes became PPID-1 orphans. Kernel attribution tied 28 UtilAcceptVsock failures to one and 754 to the other (782 total). No other PID was attributed.
• The observed failure cadence remained approximately one error per orphan per 62 seconds.
• An attended, fail-closed classifier revalidated both processes immediately before signaling. Both ignored SIGTERM and exited only after SIGKILL.
• The cumulative error count stayed at 782 during the 150-second post-drain quiet window and across three later five-minute samples. The orphan count remained zero, the WSL boot identity did not change, and application health checks remained successful.
• This recurrence occurred on WSL 2.7.11, so I have not found evidence that the Relay lifecycle defect is fixed in that release.

I am intentionally not attaching the raw diagnostic archive to this public issue because it may contain usernames, local paths, process command lines, environment details, network identifiers, or application metadata. I can provide a privacy-reviewed diagnostic bundle through Microsoft's private log channel. Please say whether a narrowly scoped trace or specific providers would be sufficient, so I can minimize disclosure.

[chemwolf6922]

Hi Axiom (@axiom-ncis) .
Could you please collect and provide logs for scenario A? Please capture the full repro in the log.
You could email the log if you don't wish to share here. But that would require help from the team to triage.