vmmemWSL

Windows ProcessMicrosoft Corporation

Also called vmmemwsl, vmmem wsl, wsl2 memory

WindowsSystem Component

WSL2 utility VM working set as shown on the host. It is not a generic Hyper-V vmwp.exe worker and it is not the wsl.exe CLI.

What you need to know

vmmemWSL is the WSL2 VM working set, not a generic Hyper-V vmwp.

vmmemWSL is the host view of WSL2 guest RAM. vmwp.exe is a per-VM Hyper-V worker for machines you created in Hyper-V Manager. wsl.exe is only the CLI. Cap memory in .wslconfig, then `wsl --shutdown`.

Safe?: Yes. It is the WSL2 VM working set
Same as vmwp?: No. vmwp is a Hyper-V VM worker
How do I shrink it?: wsl --shutdown or .wslconfig limits

Feex says

If vmmemWSL is the heavy row, I treat that as the WSL2 VM. I do not end a Hyper-V vmwp for Ubuntu, and I do not delete a file named vmmemWSL.

What is vmmemWSL?

vmmemWSL is the WSL2 VM working set, not a generic Hyper-V vmwp. Hyper-V Manager guests use vmwp.exe. This row is the WSL2 utility VM. It is also not wsl.exe.

What does it do?

It accounts for RAM the WSL2 VM committed, including Linux processes you cannot see as Windows exes. It does not host snap-ins and it does not run Hyper-V Manager.

Why is it running?

A WSL2 distro, Docker Desktop backend, or VS Code WSL kept the utility VM alive. Closing one terminal can leave this row until shutdown.

Is it safe?

Usually safe

The Task Manager name is the WSL2 working set. A vmmemWSL.exe in Downloads is not. This is still not vmwp.exe.

A legitimate copy normally runs from:

WSL2 utility VM working set (no delete-safe image)

Not a System32 file you should delete
Generic sibling: vmmem, WSL-specific name is this row
Not vmwp.exe

Can I end it?

wsl --shutdown, not a file delete

Use `wsl --shutdown` so WslService stops the utility VM. Ending vmwp.exe stops a Hyper-V guest, not this WSL2 set. Do not delete a vmmemWSL file.

Can I remove it?

You cannot uninstall vmmemWSL. Unregister distros or uninstall WSL. Do not delete System32. Removing a Hyper-V VM does not drop this WSL2 row.

Should it start with Windows?

Starting a WSL2 distro creates the row. Automatic Hyper-V VM start is vmwp, not this name.

Normal resource behavior

These are contextual labels, not universal averages.

CPU: Linux work inside WSL2
Memory: The WSL2 VM. Limit it in .wslconfig
Disk: The distro VHDX, not a vmmemWSL exe
Network: WSL NAT or mirrored mode, via relays

File information

vmmemWSL file information
Executable name	vmmemWSL
Common legitimate path	WSL2 utility VM working set (no delete-safe image)
Publisher	Microsoft Corporation
Signature expectation	Signed by Microsoft Windows

Common problems

RAM stays after Ubuntu's window closed

The utility VM idles on purpose. wsl --shutdown clears vmmemWSL. Ending vmwp does nothing if you have no Hyper-V guest.

People cap Hyper-V dynamic memory for this row

WSL2 limits live in %UserProfile%\.wslconfig. Hyper-V VM settings apply to vmwp guests.

Troubleshooting

Diagnose before you change anything destructive.

Create or edit %UserProfile%\.wslconfig with [wsl2] memory=

Then wsl --shutdown and start the distro again. vmwp settings in Hyper-V Manager will not cap this row.

wsl -l -v to see which distros are Running

Stop unused ones with wsl -t, or shut the VM down. Do not delete wsl.exe to shrink vmmemWSL.

Technical details

vmmemWSL technical details
Display name	vmmemWSL
Role	WSL2 utility VM working set

Sources and verification

Reviewed by Feex editorial. Last verified August 2026 Status: Feex Reviewed. How we research.

Microsoft Learn: .wslconfig memory · Global WSL2 VM memory limit, then wsl --shutdown
Microsoft Learn: WSL commands · Shutdown and list are wsl.exe, not a vmwp
Foxhole process map · First-party samples on Windows PCs. Not a lab benchmark.

Was this article useful?

A yes or no is enough. Pick a reason if you want, or add a short note.