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

Nobody has claimed this yet.

# 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:

```powershell
wsl -d Ubuntu -- sleep infinity
```

Alternatively, configure `.wslconfig`:

```ini
[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`

```text
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:

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

```text
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

Start by reproducing the short-lived boots with the listed WSL setup, then compare `last reboot`, `journalctl`, and Windows Event Viewer Hyper-V VmSwitch Event ID 285 entries. Check the `.wslconfig` settings and the documented `vmIdleTimeout` behavior against the idle and long-lived-process cases. Done means WSL remains stable under the reported workload without relying on the workaround.

Written by the indexing model from the issue text.