microsoft / microsoft/vscode-cpptools

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

Aperta
#14,778 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

@Colengms ci sta già lavorando.

Dal 17/9/2026.

Language Service more info needed
Lingua principale
TypeScript
Stelle
6.2k
Fork
1.7k
Merge medio
14h 46m
PR unite (30g)
61

Descrizione

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.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.