[WSL2] C/C++ IntelliSense triggers ~30s wsl.exe stalls and Remote-WSL disconnects

[fechofx]

Environment

• OS and Version: Windows 11 10.0.26200.9457; WSL 2.7.14; WSL kernel 6.18.33.2-2; Ubuntu 22.04 (WSL2)
• VS Code Version: 1.137.0
• C/C++ Extension Version: 1.35.1 pre-release (also reproduced with 1.34.4)
• If using SSH remote, specify OS of remote machine: Not using SSH. Using VS Code Remote-WSL 0.104.3 with Ubuntu 22.04.

Bug Summary and Steps to Reproduce

Bug Summary:

When the Microsoft C/C++ IntelliSense engine is enabled in a VS Code WSL2 workspace, it can cause new Windows-to-WSL invocations to intermittently stall for approximately 30 seconds.

The problem is not limited to IntelliSense operations. A trivial Windows PowerShell command such as:

wsl -d Ubuntu-22.04-D -- /bin/true

normally completes in approximately 0.1-0.2 seconds. After the issue is triggered, the same command intermittently takes approximately 30 seconds, and in some earlier tests reached approximately 55-60 seconds.

At approximately the same time:

• The C/C++ language server crashes or restarts.
• C/C++ output contains "uv_read_cb failed with nread = -104".
• VS Code reports errors such as:
  "Client cpptools: connection to server is erroring. write EPIPE"
  "Cannot call write after a stream was destroyed"
• Remote-WSL disconnects and reconnects.

I isolated the issue by moving all remote user extensions out of ~/.vscode-server/extensions and restoring extensions selectively.

The strongest A/B result was obtained with ms-vscode.cpptools as the only remote user extension.

With C/C++ 1.34.4 and IntelliSense enabled:

Baseline:
0.158s
0.107s
0.107s

After opening VS Code and the C++ workspace:
0.200s
30.105s
0.199s
30.154s
30.085s
30.181s
30.079s
0.111s

With the same extension and workspace, but with:

"C_Cpp.intelliSenseEngine": "disabled"

the same test remained stable:

0.137s
0.119s
0.105s
0.115s
0.137s
0.143s
0.112s
0.112s

I then updated to C/C++ 1.35.1 pre-release and re-enabled IntelliSense. The issue reproduced again:

0.180s
0.156s
0.170s
30.108s
30.164s
30.214s
0.176s
0.128s

Remote-WSL also disconnected/reconnected during this run.

After disabling C/C++ IntelliSense again, repeated WSL invocation tests remained stable at approximately 0.1-0.2 seconds.

Steps to reproduce:

1. Start an Ubuntu 22.04 WSL2 distro.

2. Connect to it using VS Code Remote-WSL.

3. Install/enable Microsoft C/C++ in the WSL environment.

4. Enable the default C/C++ IntelliSense engine.

5. Open a non-trivial C++ workspace and C++ source/header files.

6. From Windows PowerShell, repeatedly run:

   wsl -d Ubuntu-22.04-D -- /bin/true

7. Observe that calls which normally take approximately 0.1-0.2 seconds begin intermittently taking approximately 30 seconds.

8. Around the same time, observe C/C++ language server errors/crashes and Remote-WSL reconnects.

9. Set:

   "C_Cpp.intelliSenseEngine": "disabled"

10. Terminate and restart the WSL distro and repeat the test.

With IntelliSense disabled, the approximately 30-second stalls no longer reproduce in my testing.

Expected behavior:

Enabling C/C++ IntelliSense should not cause unrelated host-side wsl.exe invocations to stall for approximately 30 seconds, and should not destabilize the Remote-WSL connection.

Configuration and Logs

Relevant VS Code Remote Machine settings during the stable workaround:

{
    "C_Cpp.default.compilerPath": "/usr/bin/g++",
    "C_Cpp.intelliSenseEngine": "disabled"
}

When IntelliSense was enabled/default, the problem reproduced.

Representative C/C++ output/errors while the problem was active:

uv_read_cb failed with nread = -104
uv_read_cb failed with nread = -104

Language server crashed. Restarting...

Client cpptools: connection to server is erroring. Cannot call write after a stream was destroyed

Client cpptools: connection to server is erroring. write EPIPE

Representative Windows-side timing command:

wsl -d Ubuntu-22.04-D -- /bin/true

Normal latency:
approximately 0.1-0.2 seconds

Affected latency:
approximately 30 seconds per invocation, intermittently and sometimes repeatedly.

Example with C/C++ 1.35.1:

0.180s
0.156s
0.170s
30.108s
30.164s
30.214s
0.176s
0.128s

Example with IntelliSense disabled:

0.145s
0.148s
0.146s
0.142s
0.121s
0.134s
0.147s
0.121s

Recovery command:

wsl --terminate Ubuntu-22.04-D

After restarting the distro, wsl.exe invocation latency returns to approximately 0.1-0.2 seconds.

Additional WSL observations during investigation:

- No Linux processes were found in D state.
- Linux-to-Windows interop was still responsive in one affected-state test. cmd.exe /c exit completed in approximately 0.144 seconds.
- /run/WSL/*_interop sockets inspected during the affected state had corresponding live /init processes.

Important configuration caveat:

During the earlier reproductions, I discovered that my Remote Machine setting for C_Cpp.default.compilerPath had accidentally been set to a header-file path.

It has since been corrected to:

"C_Cpp.default.compilerPath": "/usr/bin/g++"

I have not intentionally re-enabled cpptools IntelliSense after correcting this setting because repeatedly enabling IntelliSense had destabilized the WSL session.

Therefore, an interaction between the invalid compilerPath and the IntelliSense engine is not fully ruled out.

The current stable workaround is:

"C_Cpp.default.compilerPath": "/usr/bin/g++"
"C_Cpp.intelliSenseEngine": "disabled"

I currently use clangd for C/C++ language features.

Other Extensions

The issue was isolated by removing all remote user extensions and restoring them selectively.

No remote user extensions:
WSL remained stable, with wsl.exe invocation latency approximately 0.1-0.2 seconds.

AI-extension group without cpptools:
OpenAI Codex, Gemini Code Assist, Cline, and Kimi Code were tested together without cpptools. WSL remained stable during the test.

C/C++ only, IntelliSense enabled:
The issue reproduced.

C/C++ only, with C_Cpp.intelliSenseEngine=disabled:
The issue did not reproduce.

Therefore, the reproduction does not appear to require another VS Code extension.

Additional context

I found existing issues such as #10713 and #8131 that describe similar C/C++ language-server symptoms, especially:

uv_read_cb failed with nread = -104

and IntelliSense process crashes.

However, I could not find an existing issue describing the specific behavior observed here: enabling C/C++ IntelliSense appears to cause unrelated host-side wsl.exe invocations to stall for approximately 30 seconds and can cause Remote-WSL to disconnect/reconnect.

The issue reproduced with both:

C/C++ 1.34.4
C/C++ 1.35.1 pre-release

The current workaround is to disable the Microsoft C/C++ IntelliSense engine and use clangd for language features.

I can collect additional C/C++ language-server logs, WSL logs, process-state information, or perform a narrower reproduction if needed.

[Colengms]

Hi fecho (@fechofx) . My first impression is that wsl -d Ubuntu-22.04-D -- /bin/true shouldn't have anything directly to do with cpptools.

I tasked a Copilot agent to look into this. FYI, this is what it came up with so far:

Thanks for the detailed investigation. We do not see a direct mechanism by which /bin/true would communicate with or modify cpptools.

However, wsl.exe -d … -- /bin/true is not merely starting a normal Linux child process. It asks WSL to create a new distro session and associated Hyper-V socket/VMBus channels in the same WSL VM hosting VS Code Remote and cpptools.

The errors appear more consistent with cpptools being affected by a WSL-level transport failure:

• uv_read_cb failed with nread = -104 means ECONNRESET; an internal cpptools worker connection was reset.
• The subsequent EPIPE messages indicate that the extension’s connection to the main cpptools process was also lost.
• Remote-WSL disconnecting at the same time strongly suggests a failure below cpptools rather than an isolated IntelliSense crash.

Enabling IntelliSense may still help trigger or expose the problem because it adds several processes and potentially significant CPU and memory load. Similar WSL reports describe existing sessions continuing to work while new wsl.exe sessions time out after approximately 30 seconds because new hvsocket/VMBus channels cannot be established:

• New WSL sessions hang under memory pressure with vmbus_alloc_ring allocation failure WSL#40795
• Session relay's vsock accept has no timeout; orphaned relays never exit, pinning vmbus rings until new sessions fail WSL#41242
• init aborts (SIGABRT) when an interop client disconnects before its reply: wil::ResultException Broken pipe inside wil::scope_exit in the Interop thread WSL#41592

The successful cmd.exe /c exit test does not necessarily rule this out. A Windows process launched from an existing shell can reuse that shell’s established WSL interop relay, whereas the host-side wsl.exe command must create a new session.

The invalid compilerPath remains a possible contributing factor, but it would not by itself explain Remote-WSL disconnecting. Could you retry after a clean wsl --shutdown, with /usr/bin/g++ configured and IntelliSense enabled? That would separate the compiler configuration from the IntelliSense A/B test.

If it reproduces, the following output captured before terminating WSL would be especially useful:

dmesg -T | grep -E 'vmbus_alloc_ring|page allocation failure|UtilAcceptVsock|UtilBindVsockAnyPort|SessionLeader|InteropServer|Broken pipe|fatal signal|oom'
ps -e -o pid,ppid,comm,args | grep -E 'Relay|cpptools'

It would also be useful to check %LOCALAPPDATA%\Temp\wsl-crashes for an _init-6.dmp, and to collect the official WSL diagnostic logs while reproducing the problem. At this point, our leading theory is that IntelliSense load is exposing a WSL session/channel failure and cpptools is collateral damage, rather than the /bin/true command directly affecting cpptools.> dmesg -T | grep -E 'vmbus_alloc_ring|page allocation failure|UtilAcceptVsock|UtilBindVsockAnyPort|SessionLeader|InteropServer|Broken pipe|fatal signal|oom'
ps -e -o pid,ppid,comm,args | grep -E 'Relay|cpptools'

It would also be useful to check `%LOCALAPPDATA%\Temp\wsl-crashes` for an `_init-6.dmp`, and to collect the official WSL diagnostic logs while reproducing the problem. At this point, our leading theory is that IntelliSense load is exposing a WSL session/channel failure and cpptools is collateral damage, rather than the `/bin/true` command directly affecting cpptools.ects.