WSL 2.7.10 / 6.18.33.2-2: unkillable D-state (find/rm/ls/systemd) with load ~75 vs ~12% CPU; Cursor Remote-WSL EH timeout. No wchan. Likely #41113, not #41191

Nobody has claimed this yet.

### Windows Version

Microsoft Windows [Version 10.0.26200.8875]

### WSL Version

2.7.10.0

### Are you using WSL 1 or WSL 2?

- [x] WSL 2

### Kernel Version

`6.18.33.2-microsoft-standard-WSL2` (`#1 SMP PREEMPT_DYNAMIC Thu Jun 18 21:54:43 UTC 2026`)

`wsl --version`:

```
WSL version: 2.7.10.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8875
```

### Distro Version

Ubuntu 26.04 LTS (resolute), `wsl -l -v` → `Ubuntu Running 2`

### Other Software

- Cursor 3.18.9 Remote-WSL (`anysphere.remote-wsl`), leftover `cursor-server` listening on `127.0.0.1:42879`
- Concurrent leftover agent CLIs inside the same distro: `pi`, `kimi-code`, `codex`, several `timeout`-wrapped `python` processes (one at 100% CPU, cwd under `~/Github/MASS`)
- Host CPU: Intel Core i9-14900K (Family 6 Model 183 Stepping 1)
- snap/command-not-found is already stubbed out on this machine (not the 2026-08 snap D-state trigger)

### Repro Steps

Not a single-command repro. This is a live incident report from 2026-09-08 after the VM was recovered with `wsl --shutdown` (so **no `wchan` / `/proc//stack` / D-task `cmdline`** were captured — reading `cmdline` of a D task is how #41113 poisons `ps`).

1. Leave Ubuntu WSL2 running for several hours with multiple agent CLIs (Cursor / Codex / pi / kimi) doing large mmap/munmap and filesystem work on the ext4 VHD (`/home`, not only `/mnt/c`).
2. Reconnect Cursor via Remote-WSL (`wsl+ubuntu`).
3. Observe Cursor resolve authority to an already-running `cursor-server` in ~300ms (`Successfully connected to Cursor server at http://127.0.0.1:42879/version`).
4. ~60s later the remote extension host fails: `The remote extension host took longer than 60s to send its ready message.` Then `No Connect transport provider registered`.
5. Inside the guest, `ps -eo pid,stat,pcpu,pmem,comm` still returns immediately (reads `/proc//stat` + `comm` only). Task Manager shows `vmmemWSL` around **12% CPU** while guest load is ~**75**.

### Expected Behavior

- Uninterruptible (`D`) tasks should be exceptional and killable, or at least not pin `systemd` (pid 1) and `wsl-pro-service`.
- High load should track CPU or a documented I/O bottleneck, not persist at 65–75 for 15+ minutes while the host sees ~12% CPU.
- If `cursor-server` `/version` answers, the remote extension host should become ready (or fail with a guest-side crash/oops, not a silent 60s timeout).
- `kill -9` / process restart should recover without `wsl --shutdown`.

### Actual Behavior

Same WSL + kernel pair as #41113 (`2.7.10.0` / `6.18.33.2-2`). **No kernel oops** — this is not the #41191 `try_to_unlazy` / `fs/namei.c:844` GuestCrash signature.

Captured while the guest was still up:

`/proc/loadavg`:

```
75.17 72.55 66.93 23/1107
```

(`23` runnable threads vs 1-minute load `75` ⇒ load was dominated by tasks that are **not** in `nr_running`, i.e. `D`.)

Guest memory (`free -h`): 31Gi total, 21Gi used, 7.7Gi cache, **9.8Gi available**, swap unused. Host `vmmemWSL` Working Set ~13 GB, commit ~29 GB. Not OOM.

`ps` state counts (process-level, no `-L`, so D **threads** inside node/python are under-counted):

```
~16 R
~7 D (find, rm, ls, MainThread, systemd pid 1, wsl-pro-service)
~46 Z (MainThread, uv, kimi-code) — zombies do not add to load; they are a consequence
```

Visible D processes (comm from `stat` only):

| comm | notes |
| --- | --- |
| `find` / `rm` / `ls` | path lookup / unlink stuck |
| `MainThread` | node-style worker |
| `systemd` (pid 1, `Ds`) | init itself uninterruptible |
| `(wsl-pro-servi)` (`Ds`) | WSL guest agent |

`ps` did **not** hang, unlike the classic #41113 writeup, because nothing enumerated `/proc//cmdline` of the D tasks. Cursor still could not finish Remote-WSL bring-up: HTTP `/version` on the existing server worked; the extension host never sent ready.

Only `wsl --shutdown` cleared the guest. `kill -9` is expected to be useless on these D tasks (not re-tested after shutdown).

### Why this is filed as a new issue

- **Likely the same kernel bug as #41113** (per-VMA lock stall on 6.18.33.2-2). We cannot assert `__vma_start_write` without `wchan`.
- **Userspace signature differs:** Cursor Remote-WSL + leftover agents, not only Codex; `ps` can still work; pid 1 and `wsl-pro-service` also entered `D`; load vs CPU mismatch is extreme.
- **Not #41191:** no `kernel BUG at fs/namei.c:844`, no GuestCrash. Related only in the sense that both sit on the 6.18 WSL kernel line.

Happy to re-capture `wchan` / SysRq-w / `/proc//stack` on the next occurrence (without reading D-task `cmdline`).

Start with the WSL 2.7.10.0 and 6.18.33.2-2 details, then compare this incident with #41113 and the fs/namei.c:844 signature from #41191. On the next occurrence, capture wchan, SysRq-w, and /proc//stack without reading a D-task's cmdline. Done means determining whether this is the #41113 per-VMA lock stall or a distinct kernel issue.

Written by the indexing model from the issue text.