WSL2 restarts approximately every minute under native Docker workload; Hyper-V VmSwitch logs Event ID 285 IOCTL_ENUM_NIC_COUNT_EX timeout

[stormbee]

WSL Bug Report Draft

Title

WSL2 restarts approximately every minute under native Docker workload; Hyper-V VmSwitch logs Event ID 285 IOCTL_ENUM_NIC_COUNT_EX timeout

Windows Version

Microsoft Windows [Version 10.0.26200.8246]

WSL Version

Version: 2.6.3.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8246

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.6.87.2-microsoft-standard-WSL2

Distro Version

Ubuntu 24.04.4 LTS

Other Software

Docker Engine installed natively inside Ubuntu on WSL2 (no Docker Desktop)
systemd enabled in Ubuntu
Windows Event Viewer / Hyper-V VmSwitch logs show recurring Event ID 285
Observed HNS networks include:

• FSE Switch (Ethernet) [Mirrored]
• FSE Switch (Wi-Fi) [Mirrored]
• FSE Switch (Loopback Pseudo-Interface 1) [Mirrored]
• WSL (Hyper-V firewall) [ICS]

Repro Steps

1. Install Ubuntu on WSL2.
2. Enable systemd in the distro.
3. Install Docker Engine natively inside Ubuntu without Docker Desktop.
4. Start Docker inside WSL and expose the Docker API to the Windows host.
5. Access the service from Windows and continue normal usage.
6. Wait for a short period.

After some time, services inside WSL become unavailable.

When investigating the failure:

• journalctl shows service shutdown including Docker
• last reboot inside WSL shows repeated short-lived boots
• Windows Event Viewer shows recurring Hyper-V VmSwitch Event ID 285 entries

Expected Behavior

WSL2 should remain stable while running normal long-lived Linux services such as Docker.

The WSL VM should not repeatedly shut down or restart during normal service operation.

If vmIdleTimeout is configured, it should either:

• prevent this lifecycle interruption, or
• it should be documented why it does not apply in this scenario.

Actual Behavior

The WSL2 VM appears to shut down or restart periodically, roughly every minute in this environment.

This causes services running inside WSL to disappear temporarily. Docker was the most visible symptom, but the issue is not specific to Docker itself.

Observed Symptoms

• Linux services are shut down gracefully during each cycle
• last reboot shows repeated very short WSL uptimes (30-60 seconds)
• Windows Event Viewer logs recurring Hyper-V VmSwitch errors at the same time
• Access to services exposed from WSL is lost when the WSL VM restarts
• Each shutdown/restart cycle is consistent and predictable (~60 second intervals)

Reproduction Conditions

The bug manifests only when all of the following are true:

1. No persistent background process is running inside WSL
2. WSL is in an idle state (no active user processes)
3. Hyper-V networking operations are executing normally
4. vmIdleTimeout is not set to -1 (default or positive value triggers the issue)

The bug does not occur if any of these conditions are met:

• A long-lived process (e.g., sleep infinity) is continuously running inside WSL
• vmIdleTimeout=-1 is set in .wslconfig with [wsl2] section
• VM remains under active load/usage

Contributing Factors

Based on diagnostic analysis, the following factors trigger or influence the instability:

1. Hyper-V VmSwitch IOCTL Timeouts (Event ID 285)

   • "IOCTL_ENUM_NIC_COUNT_EX" operations taking too long to complete
   • Occurs when querying network adapter counts via Windows Filtering Platform
   • Observed at regular ~60-second intervals

2. HNS (Host Networking Service) Mirrored Networks

   • FSE Switch (Ethernet) [Mirrored]
   • FSE Switch (Wi-Fi) [Mirrored]
   • These cause increased driver-level operations that correlate with timeouts

3. WSL Idle Timeout Lifecycle

   • Default idle timeout triggers VM shutdown when no active processes exist
   • This shutdown coincides exactly with Hyper-V VmSwitch timeout events
   • Suggests WSL lifecycle management interacts poorly with timeout conditions

4. Network-Level Events

   • Driver-level operations (Windows Filtering Platform, OID queries) appear to be the trigger
   • Flow Steering Engine (FSE) operations on mirrored interfaces may amplify the issue

Workaround

A workaround that currently stabilizes the environment is keeping a long-lived process running inside WSL, for example:

wsl -d Ubuntu -- sleep infinity

Alternatively, configure .wslconfig:

[wsl2]
vmIdleTimeout=-1

[experimental]
autoMemoryReclaim=disabled

Both approaches prevent the frequent shutdown/restart pattern, but do not address the root cause of the underlying IOCTL timeout issue.

Diagnostic Logs

Inside WSL:

last reboot | head -5

reboot   system boot  6.6.87.2-microso Thu Apr 30 02:54   still running
reboot   system boot  6.6.87.2-microso Thu Apr 30 02:47 - 02:47  (00:00)
reboot   system boot  6.6.87.2-microso Thu Apr 30 02:46 - 02:47  (00:00)
reboot   system boot  6.6.87.2-microso Thu Apr 30 02:43 - 02:44  (00:00)
reboot   system boot  6.6.87.2-microso Thu Apr 30 02:42 - 02:43  (00:00)

Windows Event Viewer:

Provider:
Microsoft-Windows-Hyper-V-VmSwitch

Recurring Event ID:
285

Example messages:

V-Switch operation IOCTL_ENUM_NIC_COUNT_EX (2241616) took too long to complete.
Operation Type: IOCTL.

V-Switch operation OID_GEN_STATISTICS (131334) took too long to complete.
Operation Type: OID HOST VNIC.
NicFriendlyName: WSL (Hyper-V firewall).

Failed Mitigation Attempts

Several approaches were tested and did not resolve the root issue:

• Changing Docker bind addresses from unix socket to TCP — issue persisted at WSL level
• Using networkingMode=mirrored — made instability worse with more frequent timeouts
• Setting vmIdleTimeout=3600000 (1 hour) — did not prevent the timeout events
• Confirmed the issue is not Docker-specific — occurs with any running services

These tests confirmed the problem originates from WSL VM lifecycle management, not the hosted services.

Event Log Analysis

Windows Event Viewer shows clear correlation between Hyper-V VmSwitch errors and WSL VM lifecycle events. The pattern is consistent:

1. Hyper-V VmSwitch Event ID 285 occurs (IOCTL timeout)
2. Within seconds, WSL services begin graceful shutdown
3. WSL VM stops and is restarted by WSL subsystem
4. Cycle repeats approximately 60 seconds later

The timing is deterministic and reproducible.

Possibly related issues: #13033, #11369, #10494, #9508

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

[stormbee]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[chemwolf6922]

Hi stormbee, the vmIdleTimeout option won't keep the distro (and the docker workload) alive. You could try this option in your .wslconfig instead:

[general]
instanceIdleTimeout=-1

The shutdown you are seeing is the default distro auto shutdown behavior of wsl. The default timeout is 15 seconds after no active shell.

[mattadams-dev]

Additional data point: same Event 285 / vSwitch collapse signature, reproduced without Docker, plus a single-variable A/B that isolates the Hyper-V firewall as the trigger on my machine.

Environment

• Windows 11 Home 25H2, build 26200.8973
• WSL 2.7.11.0, Ubuntu 22.04, default NAT networking
• Workload: several long-running dev services inside WSL (browser automation, git daemons, LLM agent processes). Docker Desktop stopped throughout, so this reproduces independently of the OP's Docker workload.

Onset
Stable for 12+ hours under this exact workload, then Windows installed KB5101684 + KB5101711 (2026-07-29, three servicing restarts, all clean). First collapse ~7 hours later; three collapses that day. Signature each time:

1. WSL CheckConnection getaddrinfo() failed: -5 (first Linux-side symptom)
2. Hyper-V VmSwitch Event 285: OID_GEN_STATISTICS took too long, NIC "WSL (Hyper-V firewall)" (earliest host-side anomaly)
3. WSL vNIC disconnected, VMBus paused; burst of SIGBUS dumps for /usr/lib/systemd/systemd (reads as teardown collateral, not cause)

Linux journal shows no kernel panic, no EXT4/block errors, no OOM, no shutdown sequence. Host shows no bugcheck or dirty shutdown (no Event 41/6008).

Single-variable A/B

• Baseline (default NAT, Hyper-V firewall enabled): 3 collapses in one day.
• Same box, same workload, default NAT, Hyper-V firewall disabled for the WSL VM creator via elevated Set-NetFirewallHyperVVMSetting -Enabled False + wsl --shutdown: 12.5 hours continuous under load, 1,498 heartbeat samples (30 s cadence, DNS + loopback probes), zero collapses. Roughly 36 hours of further uptime since, still clean.

Two caveats that may matter to others in this thread

1. .wslconfig [wsl2] firewall=false did not take effect on this build. After wsl --shutdown and restart, Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore still showed the WSL VM creator {40E0AC32-46A5-438A-A0B2-2B479E8F2E90} with Enabled: True and full baseline settings. Only the elevated Set-NetFirewallHyperVVMSetting -Enabled False changed ActiveStore. If you tested firewall=false and saw no improvement, verify ActiveStore - the knob may have silently no-opped.

2. With the firewall disabled, Event 285 keeps firing every few minutes in a benign form: OID_GEN_STATISTICS ... Execution time 0 ms. Queued time 0 ms. Expected execution time less than 0 ms. on NIC "WSL" (340 occurrences during my cleanest 12.5-hour window). So a bare Event ID 285 count is not a useful failure signal - the failure-correlated form was on the "WSL (Hyper-V firewall)" NIC in the minutes before collapse, and the "expected less than 0 ms" threshold looks like its own small telemetry bug.

Happy to provide fuller timelines or logs if useful.