Vmmem Using High Memory? Identify the Workload and Limit WSL2

You open Task Manager, and a process called Vmmem (or VmmemWSL) is sitting on 4, 7, sometimes 12 GB of RAM — and you can’t end it. Right-click → End Task does nothing.

Vmmem/VmmemWSL reports resources used by virtualized workloads. WSL2 and a Docker Desktop WSL backend can use it; other virtualization workloads need their own diagnosis. Merely having installed Docker or Ubuntu does not prove they are causing this activity. Identify the running workload before stopping it.

Stop WSL after saving its work

1. Save files in every Linux session/container. Stop running jobs and databases normally, and quit Docker Desktop through its supported controls. wsl --shutdown immediately terminates running WSL distributions and their VM; it can discard unsaved work.
2. Open PowerShell.
3. Run:

   wsl --shutdown

4. Check Task Manager. WSL memory should fall when its VM stops; another virtualized workload can keep a Vmmem process active.

This stops the WSL environment immediately; it is not a guarantee of a graceful application shutdown. It does not stop unrelated Hyper-V VMs. Stop each workload through its own controls first, and do not force-kill Vmmem.

If Docker Desktop is set to start with Windows, Vmmem will return at next boot — which is why you also want the permanent fix.

The permanent fix: cap WSL2’s memory with .wslconfig

By default, WSL2 is allowed to grab a large share of your total RAM. You can cap it:

1. Open File Explorer and go to C:\Users\<your username>\
2. Create a file named exactly .wslconfig (no .txt extension — enable “File name extensions” in Explorer’s View menu to check)
3. Put this in it:

   [wsl2]
   memory=2GB
   processors=2
   swap=1GB

   Adjust to taste — memory=2GB is comfortable for light Docker use; give it 4GB if you compile inside WSL.
4. Save the configuration and all running Linux/container work, stop workloads normally and quit Docker Desktop, then run wsl --shutdown. The limits apply from the next WSL start.

This is Microsoft’s documented mechanism (global WSL2 settings live in %UserProfile%\.wslconfig) and it’s the reliable way to stop Docker/WSL from creeping past the RAM you intended to give it.

If the workload is not WSL

Check running Hyper-V VMs, Windows Sandbox, Docker’s selected backend and any emulator you use. Save its work and stop it through its own supported controls. wsl --shutdown only targets WSL. Do not remove Windows virtualization features as a generic memory fix; other apps and security features may depend on them.

FAQ

Why can’t I end Vmmem in Task Manager? It’s not a normal process — it’s the host-side representation of a virtual machine. You stop it by stopping the VM (wsl --shutdown), not by killing the meter that measures it.

Is high Vmmem usage bad? Not inherently — Linux aggressively caches file data in RAM it’s been given. The .wslconfig cap keeps that appetite inside a budget so the rest of Windows stays snappy.

Vmmem vs VmmemWSL? Same idea; newer Windows builds split WSL’s usage out under the VmmemWSL name so you can tell it apart from Hyper-V VMs.

Sources: Microsoft Learn — WSL commands and immediate shutdown, Microsoft Learn — WSL advanced configuration