VS Code renderer causes severe memory/commit leak while idle, eventually freezing Windows

# VS Code renderer causes severe memory/commit leak while idle, eventually freezing Windows

Does this issue occur when all extensions are disabled?: Not tested yet

* VS Code Version: 1.135.0
* Commit: 08d4889f9ec4a1685d257b9b95de036c8e1ce1e5
* Architecture: x64
* OS Version: Windows 10.0.26200.9168
* Physical RAM: approximately 32 GB

## Steps to Reproduce

1. Start VS Code with my normal development environment.
2. The environment includes WSL, Docker Desktop, Node.js/Next.js server and worker processes.
3. Leave the development environment running while the machine is mostly idle.
4. After some time, system committed memory starts increasing rapidly.
5. Commit usage eventually reaches approximately 98–100%.
6. Windows becomes almost completely unresponsive. At that point I cannot reliably open Task Manager or execute diagnostic commands.
7. A hardware reset/reboot is required.

## Actual Behavior

VS Code appears to cause a severe memory/resource leak while the machine is mostly idle.

During one captured occurrence, system committed memory increased from approximately:

`18.2 GB`

to approximately:

`36.2 GB`

in about 11 minutes.

The commit limit at the time was approximately:

`36.9 GB`

so commit usage reached approximately:

`97.9%`

Once this happened, Windows became effectively unusable.

## Suspicious VS Code Process

The primary suspect is a VS Code `Code.exe` renderer process.

Immediately before the system became unusable, this renderer process showed approximately:

* PID: `14700`
* Working Set: `~2.16 GB`
* Private / committed memory: `~2.45 GB`
* Handle count: `~122,745`

The handle count appears extremely abnormal.

For comparison, another main VS Code process had only approximately:

`~1,150 handles`

Total committed memory for all VS Code processes at the time of the snapshot was approximately:

`~4.65 GB`

The unusually high handle count in this renderer process is the most suspicious observation from the captured diagnostics.

## Node.js Processes

Node.js processes were also using a significant amount of committed memory.

One Next.js process running `start-server.js` showed approximately:

* Working Set: `~1.92 GB`
* Committed memory: `~3.67 GB`

Total committed memory for all Node.js processes at that time was approximately:

`~5.18 GB`

It is possible that the issue involves an interaction between VS Code, the renderer, file watchers, extensions, Node.js/Next.js, or the development worker.

## WSL / Docker Observations

WSL and Docker do not appear to be the primary source of the memory growth.

At approximately the same time:

* `vmmemWSL`: `~1.52 GB`
* Actual used memory inside WSL: `~582 MB`
* Redis Docker container: `~14 MB`

The system-wide increase in committed memory therefore does not appear to correspond to memory usage inside WSL or Docker containers.

## Important Reproduction Detail

There is one unusual behavior that may be relevant.

I initially used a diagnostic PowerShell script that periodically queried:

* WSL memory
* Docker statistics
* Windows performance information

When this diagnostic script was running continuously, the memory leak often did not reproduce.

When the machine was left genuinely idle without those periodic WSL/Docker queries, the memory growth occurred again.

This suggests that the issue may depend on an idle state, timing, renderer behavior, file watching, background cleanup, or another process state that is changed when WSL/Docker are periodically queried.

In other words, periodically waking/querying the development environment appears to influence whether the problem reproduces.

## Impact

This is not only increased memory usage.

The end result is a complete system-level failure:

1. VS Code and the development environment are left running.
2. The machine becomes mostly idle.
3. Committed memory starts increasing rapidly.
4. Commit usage approaches 100%.
5. Windows becomes too unresponsive to terminate VS Code or collect further diagnostics.
6. The computer has to be physically reset/rebooted.

## Additional Testing

I am currently testing:

* VS Code with GPU hardware acceleration disabled
* VS Code with extensions disabled
* different combinations of the Node.js/Next.js server and worker processes
* a larger Windows page file so that the system remains responsive long enough to collect more diagnostics

I have a larger diagnostic archive from the affected system, but I am not attaching it publicly because it contains machine/user metadata.

If useful, I can provide specific sanitized logs, process information, handle data, performance traces, renderer dumps, or other targeted diagnostics requested by the VS Code team.