Repository navigation
[WSL2] C/C++ IntelliSense triggers ~30s wsl.exe stalls and Remote-WSL disconnects #14778
Description
Activity
Hi fecho (@fechofx) . My first impression is that
wsl -d Ubuntu-22.04-D -- /bin/trueshouldn'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/truewould communicate with or modify cpptools.However,
wsl.exe -d … -- /bin/trueis 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 = -104meansECONNRESET; an internal cpptools worker connection was reset.- The subsequent
EPIPEmessages 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.exesessions 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 exittest 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-sidewsl.execommand must create a new session.The invalid
compilerPathremains a possible contributing factor, but it would not by itself explain Remote-WSL disconnecting. Could you retry after a cleanwsl --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-crashesfor 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/truecommand 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.
Metadata
Metadata
Assignees
Type
Projects
- Status
Environment
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:
"Client cpptools: connection to server is erroring. write EPIPE"
"Cannot call write after a stream was destroyed"
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:
Start an Ubuntu 22.04 WSL2 distro.
Connect to it using VS Code Remote-WSL.
Install/enable Microsoft C/C++ in the WSL environment.
Enable the default C/C++ IntelliSense engine.
Open a non-trivial C++ workspace and C++ source/header files.
From Windows PowerShell, repeatedly run:
wsl -d Ubuntu-22.04-D -- /bin/true
Observe that calls which normally take approximately 0.1-0.2 seconds begin intermittently taking approximately 30 seconds.
Around the same time, observe C/C++ language server errors/crashes and Remote-WSL reconnects.
Set:
"C_Cpp.intelliSenseEngine": "disabled"
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.