Vmmem high CPU usage

[manuelserradev]

Windows Build Number

Microsoft Windows [Version 10.0.21387.1]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.16

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

I'm struggling to actually repro this issue deterministically. But looks like more prominent when waking up from sleep.
Whit this issue I'd like to gather feedback on how to collect the most useful information to debug this behavior.

I tried to isolate the failing component (ex. not running Docker Desktop and WSL2 "only"), but I failed miserably.

Usually my workflow:

• VSCode Stable v1.56.2 with WSL Remote v0.56.2 for work (usually Java + SQL)
• VSCode Insiders v1.57.0 with WSL Remote v0.56.2 for personal projects (usually JS related)
• Docker Desktop (Windows) v3.3.3 (64133) running (with mongo or postgres)

In the past I tried to alleviate the issue with a .wslconfig but didn't worked.

My machine (Lenovo X1 Carbon) has 16GB of RAM and usually Vmmem RAM consumption float around ~4GB.

Excluded those hiccups WSL2 experience is pretty neat and flowlessy.

Expected Behavior

WSL2 stay idle when no user workload are launched.

Actual Behavior

Vmmem "randomly" uses high cpu/power amount (60%-70%) for couple of minutes (2 to 5 min) before settling down. This also happen when on battery without doing anything WSL2 releated (but with Docker Desktop running), killing autonomy.

Diagnostic Logs

I'll provide an .etl dump as the next hiccup occurs.

[manuelserradev]

Today, after wake up from sleep I managed to repro.

wsl.zip

[Matsemann]

I also see high vmmem cpu usage from time to time (stuck at ~25% CPU). When checking htop on my only running image, I see that one core is being used 100%, but none of the processes are using any CPU. So not sure what's happening / what's the culprit. Docker images not running at the moment.

C:\Users\mats>wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-20.04           Running         2
  docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2

Have the opposite problem with docker, though. Suddenly it will use all available ram even when not running any containers (but the wsl distributions are running)

Edit: A pic of htop when this occurs. Nothing visible using CPU, but it's using much CPU on multiple cores anyway.

[manuelserradev]

The day after, also waking up from night sleep.

Like @Matsemann htop do not show anything relevant.

wsl2.zip

[ll931217]

The day after, also waking up from night sleep.

Like @Matsemann htop do not show anything relevant.

wsl2.zip

The high CPU usage can be seen from Task Manager

[Matsemann]

Yes, and from the htop screenshot. But you cannot see what is using the CPU (other than the generic vmmem but that can be anything). So there is something spinning somewhere draining resources for no good reason.

[ChrisJefferson]

Update, I can reproduce this 100% of the time by turning off my 2nd monitor (one core in Linux gets pegged to 100%, but htop doesn't show any processes using CPU power).

If I run 'xeyes', as soon as xeyes open the mystery CPU usage disappears, so I assume it's something to do with the new graphics integration, and actually running a program gives it a kick?

[Matsemann]

Great find! I've always experienced it after computer has been sleeping (like when coming back after lunch), but I also can reproduce it by reconnecting a monitor. Which I guess is what happens when the computer starts after sleep.

Running xeyes or any wslg app doesn't seem to stop it here, though.

[Matsemann]

I'm hitting this too, so if anyone has any suggestions on how to capture what is going on, I am happy to record it.

Yes, if someone from wsl team could tell us how to give them better diagnostics that would be nice. As we've said, nothing shows up as using resources in the wsl images themselves. But we can see a high cpu core usage in htop, or vmmem cpu usage in task manager. But don't know how to see what is causing it.

[fmiqbal]

Update, I can reproduce this 100% of the time by turning off my 2nd monitor (one core in Linux gets pegged to 100%, but htop doesn't show any processes using CPU power).

Can confirm,

1. wsl --shutdown, set monitor projection to single screen
2. Startup wsl, normal htop
3. Make monitor projection to extend
4. Suddenly 1 core spin up in htop

I tried messing with refresh rate (my first monitor has 144, my second 60), but no luck. In the process, I found that when I tried to change the refresh rate, the screen "refresh", then the 100% core in htop gone.
So I tried to just reset the graphic driver (Win+Ctrl+Shift+B), and the 100% core is also gone.

Although, currently its fresh restart and reproduced reliably, but only 1 core spinning up. In the past I had like 3 core spinning up out of nowhere. I also use Docker for Windows, which for this purpose I turn off first, because I also had bad experience on that docker hogging CPU while no container running

Update
Using docker for windows, I get 3 core spinning up when projecting to second screen, and Win+Ctrl+Shift+B still works like a charm

Windows 10, build 21390.2025
WSL2, Arch Linux,
2 monitor setup,

[onomatopellan]

I think this is indeed related to WSLg, which creates a hidden "system distro" instance for each running user distro. That's why you can't see anything in htop. When the 100% core usage happens you can run this from the terminal:
wsl.exe --system -d $WSL_DISTRO_NAME top

I bet the culprit is the weston binary inside the system distro. Recently there was a similar problem that has been fixed in the weston repository.

[joewood]

As a possible confirmation of this, I had this issue continuously (with vmmem using 50% of CPU without anything running on WSL2). I disabled WSLg in wslconfig and restarted the distributions. The issue (so far) seems to be fixed.

[onomatopellan]

With wsl.exe --update you will get WSLg 1.0.24 which contains some fixes about high cpu usage.

[joewood]

If it helps, I was already running 1.0.24 (updated yesterday) and still seeing the issue. Disabling WSLg seems to have fixed it. I'll keep testing.

[lishan89uc]

I too can reproduce this 100% by turn on/off my second monitor. Is this issue user "workaround-able" or do we have to wait for Microsoft. If so is there a way to expedite such a serious issue?

Side note: opening xeyes only drop the CPU usage from 25% to 17%. and after I closed xeyes the cpu went back up to 25%. So far I have not found a reliable way to make it run normally again other than to disable wslg with guiApplications=false added to .wslconfig inside the personal folder, do a complete wsl shutdown and restart, or wait it out. If anyone find a better way to keep the functionality (preferably automatable) as a workaround that be great.

[fmiqbal]

@lishan89uc have you tried Win+Ctrl+Shift+B

[GoaLitiuM]

I occasionally get this issue as well and it usually gets fixed when I shut down the WSL completely. This time I tried pressing the Win+Ctrl+Shift+B combo and that seems to have fixed the CPU usage in this instance.

[manuelserradev]

I also experienced this today and the Win + Ctrl + Shift + B trick solved the issue.

Worth mentioning that this is now happening on Windows 11:

Edition	Windows 11 Pro
Update	21H2
Installed on	‎01-‎Jul-‎21
OS build	22000.51
Experience	Windows Feature Experience Pack 421.16300.0.3

[jamestut]

Also happened on mine. Consistently happens after locking the screen. My system is a laptop with internal 4K display (switched off) and external 5K display via Thunderbolt (set to second screen only).
Build 22000.71, WSL2 kernel version 5.10.43, WSL2 last updated 18 July 2021.

[letrhee]

When vmmem's CPU usage is very high, in my case, stopping Docker desktop solved the problem.

• I usually use hibernate to shut down my computer.
  And I use WSLg (and dual monitors), Docker desktop, and VSCode.

[addshore]

I occasionally get this issue as well and it usually gets fixed when I shut down the WSL completely. This time I tried pressing the Win+Ctrl+Shift+B combo and that seems to have fixed the CPU usage in this instance.

This seems to work for me as a temporary fix.

I'v see this in a few different states, either 1 CPU core or 3 CPU cores all at 100% and nothing showing up in top etc as actually using CPU.

Edition	Windows 11 Pro
Version	21H2
Installed on	‎29/‎07/‎2021
OS build	22000.100
Experience	Windows Feature Experience Pack 421.18901.0.3

[jibbers42]

If you don't need gui apps then you can disable wslg while waiting for a fix. I did it a couple days ago and it seems to have stopped the high-cpu-after-sleep issue.

Add the following to <USERPROFILE>\.wslconfig and restart the machine (or maybe wsl --shutdown is good enough).

[wsl2]
guiApplications=false

See https://github.com/microsoft/wslg#wslg-system-distro

[Mystic8b]

I do not use sleep mode on my office PC, it is always on. And I have the same problem. Perhaps it appears after connecting via RDP, but I cannot confirm this yet.
@jibbers42 tx man, i'll try

[benhillis]

Could somebody who is hitting this provide the output of dmesg? I suspect this is WSLg-related.

[ctataryn]

Hi folks, I was having issues with vmmem causing my laptop fans to kick in after I had installed Microsoft PowerToys when I needed to do some batch image resizing. If I quit "Microsoft PowerToys v0.43.0" from the task tray then vmmem went back to normal.

I hope this is relevant and helps someone else in a similar predicament.

[Mystic8b]

I also use power toys, but at the moment the cpu load is normal and cannot confirm. Interesting)

[ctataryn]

I also use power toys, but at the moment the cpu load is normal and cannot confirm. Interesting)

Another thing I notice is that vmmem won't actually go away until I issue another wsl --shutdown after quitting PowerToys.

Steps:

1. Quit Docker Desktop from task tray
2. from cmd.exe: wsl --shutdown
3. Observe vmmem is still running as a process and taking about 5% CPU
4. Quit PowerToys from task tray
5. Observe vmmem is still running, however CPU usage is 0%
6. from cmd.exe, again issue: wsl --shutdown
7. Observe that vmmem is no longer present in the Task Manager

[fmiqbal]

@ctataryn sorry, can't confirm. As soon as I shutdown the wsl, vmmem is gone

[barart]

Add me to the list.. i have no open my vm instance in weeks but it use all my cpu, my debian is closed

[jose-duran-payco]

#6982 (comment)

worked for me

[arnehude]

I'll have also two devices suffering from this. One using debian, one using ubuntu. Sometimes working with the basesystem becomes realy nerf-racking because the whole system becomes unresponsiv.

[AtleWebstep]

Still an issue with the latest WSL, is anyone working on a fix for this one?

[carlfriedrich]

@AtleWebstep There is a community effort on trying to find the kernel commit which introduces this issue. You can follow or help here: carlfriedrich/wsl-kernel-build#1

[bmarinov]

The only way to kill wsl on my machine when it's stuck on 100% CPU load, is using hcsdiag. Use hcsdiag list to list all containers & VMs, copy the UID for the WSL container, then kill it using hcsdiag kill <WSL_UID>

This comment is pure gold, thank you.

[RubberSalad]

Docker even if the desktop version is off in Windows, seems to be running in WSL and resulting in high CPU usage (Vmmem process) in Windows (while not reflected in Ubuntu).
You will see docker listed after "wsl --list --running" in PowerShell.

Ex:
PS C:\Windows\system32> wsl --list --running
Windows Subsystem for Linux Distributions:
Ubuntu (Default)
docker-desktop-data
docker-desktop

I've run:
wsl --shutdown docker-desktop

After:
PS C:\Windows\system32> wsl --list --running
Windows Subsystem for Linux Distributions:
Ubuntu (Default)

The Vmmem process on my Windows machine dropped to 0 - 3% CPU usage.

I know this is not a fix and just a workaround, I just thought to share it.

[bennycode]

Thanks to everyone for sharing debugging information.

We've made some progress on this issue on #8696 but we need more information. Pasting the instructions to gather more debugging information here:

Note: this requires WSL >= 1.1.0

1) Capture an strace

• Open a debug shell via: wsl.exe --debug-shell
• Install strace and netcat via: tdnf install nc strace -y
• Get wsl's ip address by running: ip -4 a show eth0 (It's usually of the form 172.X.X.X)
• Reproduce the issue
• Use ps aux to get the pid of the process taking the most CPU (and share the output of that command on this issue)
• In the debug shell, run: strace -p <pid> 2>&1 | nc -l -p 1111 (replace <pid> with the pid of the process eating all the cpu)
• In a Windows powershell, run:

$tcp = New-Object System.Net.Sockets.TcpClient("<addr>", 1111) # <== Replace <addr> with WSL ip address 
$stream = New-Object System.IO.StreamReader($tcp.GetStream())
while ($tcp.Connected)
{ Write $stream.ReadLine() >> "strace-log.txt"}

(Note: We have to do this because the debug shell doesn't have access to the Windows drives, so we use the network to extract the strace output)

• Once WSL is hung, ctrl-C the powershell command and share the resulting `strace-log.txt" on this issue

2) Capture a dump

This time we'll capture a dump of the process. To do this, can you please:

• Restart wsl completely with: wsl.exe --shutdown
• Open a debug shell and install gdb and netcat via: tdnf install gdb nc -y
• Get WSL's ip address again via: ip -4 a show eth0
• Reproduce the issue where init takes a lot of CPU and use ps aux to get the pid of the process
• Create a dump of the process via: gcore -a <pid>, this will generate a file like <pid>.core
• Stream the dump to Windows via: base64 < core.<pid> | nc -l -p 1111 (encoding in base64 because it's binary data)
• Receive the dump on Windows via (powershell):

$tcp = New-Object System.Net.Sockets.TcpClient("<addr>", 1111) # <== Replace <addr> with WSL ip address 
$stream = New-Object System.IO.StreamReader($tcp.GetStream())
while ($tcp.Connected)
{ Write $stream.ReadLine() >> "dump"}

• Wait a couple minutes, and ctrl-C the powershell command, and share the dump file on this issue (it will be base64 encoded, but we can easily decode it)

Thanks for the instructions. When I try to run tdnf install nc strace -y from a debug shell (C:\Program Files\WSL\wsl.exe) then I am receiving this error:

Error(1261) : SSL peer certificate or SSH remote key was not OK
Error: Failed to synchronize cache for repo 'CBL-Mariner Official Extras 2.0 x86_64'
Disabling Repo: 'CBL-Mariner Official Extras 2.0 x86_64'

@OneBlue I noticed today that the vmmemWSL process consumes a lot of memory when resolving npm packages in VS Code: microsoft/vscode#211528

[stardust85]

If you try to run wsl.exe --debug-shell and get something like File not found, ensure that wsl is running: simply launch it and try again.

[stardust85]

Installing anything in cbl mariner was incredible pain to me. DNS resolving didn't work for me neither in ubuntu nor in CMB Mariner, so first I needed to fix DNS by putting 8.8.8.8 into /etc/resolv.conf just by using:

echo 'nameserver 8.8.8.8' > /tmp/resolv.conf
cp /etc/resolv.conf /etc/resolv.conf.backup   # just to backup the old one
cp /tmp/resolv.conf /etc/resolv.conf

Then I got SSL errors, so I had to disable the SSL checking just by using sed (no better editor available!)

sed 's/sslverify=1/sslverify=0/g' -i /etc/yum.repos.d/mariner*.repo

Finally installed at least vim :)

[stardust85]

I see 100% at /sbin/init, but only in ubuntu, not in cbl-mariner. strace -p 1 rolls fast in ubuntu, but has only two lines in cbl-mariner.

[stardust85]

Changing systemd=true back to systemd=false in /etc/wsl.conf and restarting wsl fixed both my DNS and 100% CPU usage problem :)

wsl --version
WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.3447

[anodynos]

Worth mentioning, that this issue is highly related to #8696 WSL is non-responsive after waking from hibernate & also the community is Trying to find the kernel commit which makes WSL non-responsive

[bennycode]

@anodynos thanks for linking the related issues. I just noticed that I had a high CPU usage coming from VmmemWSL without having my PC set to hibernate before.

Unfortunately, I still cannot run tdnf install gdb nc -y as it shows:

Error(1261) : SSL peer certificate or SSH remote key was not OK
Error: Failed to synchronize cache for repo 'CBL-Mariner Official Extras 2.0 x86_64'
Disabling Repo: 'CBL-Mariner Official Extras 2.0 x86_64'

When my VmmemWSL eats all my CPU and I try to run wsl.exe --debug-shell from an elevated CMD, I am getting the following error:

All pipe instances are busy.
Error code: Wsl/DebugShell/ERROR_PIPE_BUSY

Restarting my graphics driver with Win + Ctrl + Shift + B doesn't reduce CPU load coming from VmmemWSL.

My WSL version is:

WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

I cannot run wsl --shutdown as it hangs in case of the error but running this from an Administrator Command Prompt works for me:

taskkill /F /im wslservice.exe

Any idea how I can support debugging the issue? I would love to provide more useful logs if possible.

In the "Reliability Monitor" from Windows I can see the following events if WSL stops working:

EDIT: I can now reproduce this high CPU usage everytime I am starting VS Code and opening up a package.json file.

[bennycode]

I was able to fix this on my end by adding .vscode-server to the Files: Watcher Exclude.

"files.watcherExclude": {
  "**/.vscode-server/**": true
}

I also added this exclude pattern but my VmmemWSL process is still going crazy when working in Node.js projects. It happens quite regularly when I run scripts from my package.json file.

@glazzari, do you maybe know how I can get VS Code debugging logs?

[glazzari]

I was able to fix this on my end by adding .vscode-server to the Files: Watcher Exclude.

"files.watcherExclude": {
  "**/.vscode-server/**": true
}

I also added this exclude pattern but my VmmemWSL process is still going crazy when working in Node.js projects. It happens quite regularly when I run scripts from my package.json file.

@glazzari, do you maybe know how I can get VS Code debugging logs?

Same here. I think you can use Developer: Open Logs Folder command.

[matra774]

• wsl.exe --debug-shell

I can not run this command. It results in an error. Details:

C:\WINDOWS\system32>wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.2538

C:\WINDOWS\system32>wsl.exe --debug-shell
The system cannot find the file specified.
Error code: Wsl/DebugShell/ERROR_FILE_NOT_FOUND

I did try to enable dbug shell as describe here: #7930
but id did not help. In fact,after existing bash it complained about unknown keys:

C:\WINDOWS\system32>bash
user@machine:/mnt/c/WINDOWS/system32$ exit
logout
wsl: Unknown key 'wsl2.debugShell' in C:\Users\user\.wslconfig:3

[bennycode]

@matra774 I just noticed the same issue... When running wsl.exe --debug-shell I also go the ERROR_FILE_NOT_FOUND notification. What surprisingly worked for me was running just wsl.exe (without debug shell), then exiting it (by typing exit) and then running wsl.exe --debug-shell again.

Screenshot:

[TiagoSilvaPereira]

Same issue here

[BeranekCZ]

I have same problem. vmmem process is going to high in intervals. My notebook's fans go to max rotations and it is very annoying. Some cores go to 100C

I have windows 11, CPU 13th Gen Intel(R) Core(TM) i7-13700H

[TiagoSilvaPereira]

My computer has been freezing, with VMmem always using a lot of memory and the fan going to max rotation. I decided to uninstall WSL, and now everything is going well.

[youk]

This is not a MeToo thread. Read the messages above on how to provide meaningful diagnostic data.

[mhklinux]

Let me provide a high-level recap on this long thread. :-) It has many reports of high CPU usage on the Windows/Hyper-V host, and hangs in the WSL Linux VM. For the most part, the reported symptoms are somewhat generic, which is a starting point, but usually doesn't help get to the root cause. That said, we have gotten enough diagnostic details to identify one root cause, but there may be other root causes that produce the same generic symptoms. Here are the details of the known root cause:

1. A bug in Hyper-V causes time advancement (via the TSC) in the Linux VM to be a little bit slow. As a result, when the Linux VM programs a synthetic timer interrupt, Hyper-V may generate the interrupt in the VM much sooner than it should. Eventually this becomes a synthetic timer interrupt storm that chews up a lot of CPU cycles in the host and the guest. The VM appears hung, and sometimes the Windows Hyper-V host as well.
2. The Hyper-V bug happens after the Windows Hyper-V host resumes after hibernation. It also happens only on Windows builds earlier than 22621, which includes Windows 10 and the initial release of Windows 11. The bug is believed to be fixed in build 22621, which is the Windows 11 22H2 release. (See https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions for a full list of Windows build numbers.)
3. The Hyper-V bug happens only with Linux kernel version 5.5 and later, because the bug requires enabling a Hyper-V feature that Linux first enabled in the 5.5 kernel. The WSL user community did a great job in bisecting the Linux kernel to discover this dependency, which then led to the Microsoft Hyper-V team understanding the root cause of the problem. See Trying to find the kernel commit which makes WSL non-responsive carlfriedrich/wsl-kernel-build#1 for details of that activity.

I worked on this problem a year ago as a Microsoft employee doing Linux kernel work. I've since retired from Microsoft, but have kept an interest in this problem, and have been in contact with my former colleagues on the Hyper-V and WSL teams at Microsoft. They are still working out how they want to move forward with a resolution. In the meantime, the WSL user community has built and tested custom WSL Linux kernels that don't enable the problematic feature described in (3) above. The reports from the WSL community are that these custom kernels solve this specific root cause. Again, see carlfriedrich/wsl-kernel-build#1 for information about getting one of these custom kernels.

If someone is seeing WSL hangs, and high CPU usage on the Windows Hyper-V host, and your environment meets the pre-requisites for this known root cause, you might try one of the custom kernels to see if it fixes your symptoms. If your environment doesn't meet the pre-requisites, then your problem is likely a different root cause. For example, there's been some recent discussion on this thread of issues related to VS Code, and that's almost certainly a different root cause. Unfortunately, I don't have any expertise to offer on these other potential root causes.

[oldbuilding]

The only way to kill wsl on my machine when it's stuck on 100% CPU load, is using hcsdiag. Use hcsdiag list to list all containers & VMs, copy the UID for the WSL container, then kill it using hcsdiag kill <WSL_UID>

function WslRestart { Get-Service LxssManager | Restart-Service }
function WslStop { Get-Service LxssManager | Stop-Service }

function WslStart { Get-Service LxssManager | Start-Service }

function WslServiceStatus {
	tasklist /svc /fi "imagename eq svchost.exe" | findstr LxssManager
	Get-Service | Where-Object { $_.name -like "*LxssManager*" }
	Get-CimInstance -ClassName Win32_Service -Filter "Name='LxssManager'"
}

function WslKill {
	Write-Host "Killing wsl.exe..."
	taskkill /F /FI "IMAGENAME eq wsl.exe"
	Write-Host "Killing wslhost.exe..."
	taskkill /F /FI "IMAGENAME eq wslhost.exe"
	Write-Host "Killing wslservice.exe..."
	taskkill /F /FI "IMAGENAME eq wslservice.exe"
}

WslForceRestart is the only thing that works for me. I have it in a powershell profile. Must be run as admin. WslStop and WslRestart are both useless functions. I'm including them here just to point out that they don't work for me. And wsl --shutdown has been useless for ... maybe the last year.

function WslForceRestart {
	WslKill
	WslStart
	WslServiceStatus
}

[ToniCipriani]

The only way to kill wsl on my machine when it's stuck on 100% CPU load, is using hcsdiag. Use hcsdiag list to list all containers & VMs, copy the UID for the WSL container, then kill it using hcsdiag kill <WSL_UID>

Thanks, finally a solution that doesn't require local admin or rebooting.

[sadaqatullah]

I noticed this in my PC. Everytime i notice high CPU usage, I have noticed this. Just too many wsl processes.

On top of that, disk usage sky rockets to 100MB/s
RAM consumption stays at 4.5GB

This generally happens when WSL (Ubuntu22.04)+VSCode+Docker is used together.
This doesn't happen when WSL(Ubuntu22.04)+Pycharm+Docker is used.

My guess is the way VS Code connects with WSL images is the key problem here. Because after some time of idle system (8+hours) VSCode attempts to connect with WSL and upon failing it opens a new socket/connection with WSL and forgets to remove previous connection. Due to this a number of WSL connections are opened. When VScode updates itself with new connection, it queries all the connections there are resulting in increased CPU usage, Disk usage.

Of course I can be wrong here as this is just based on observation of user experience and is personal experience. But this is my understanding of this observation. As people have suggested to kill the WSL and it generally solves the problem, I believe all connections to VScode are killed and a new one is opened that results in smoother output. Same thing (my guess, not observed or tested in any way) happens when system restarts. Connection Pool Resets and things start working smoother.

On unrelated note: Combine this with Google Chrome and an adblocker, you get even higher usage of processor/cores resulting in complete halt of system.

This is my theory.

While writing above, I reloaded VSCode and it spewed this out. I do not know what it means.

My System has13thGen i7, 64GB Ram, 3080Ti Card. So system specs are more than optimal for WSL to run but I am unable to figure it out further.