This post was most recently updated on June 13th, 2022.3 min read.
This was another (luckily pretty shallow) rabbit hole down some corporate IT and weird default configurations by our favorite tech-daddy Microsoft. In the article, I will describe one possible reason for a process called Vmmem.exe consuming enough RAM to crash pretty much everything else running on your machine.
But let’s take a step back first – what happened?
I was developing some Azure IoT Edge modules (as one does), when my dev laptop was starting to feel a bit sluggish. That’s nothing out of the ordinary, though – I often have more than 3 tabs open in Chrome, so it’s not unusual for the machine to start slowing down, especially if I try having any Electron apps open.
But then one of said Electron apps started behaving even more annoyingly – namely, Teams started crashing and restarting in a loop.
I don’t care too much about Teams not running every now and then, but a restart loop flashing on one of my screens DOES start to bother me after a while. So I started looking into it.
This is what’s shown for about 3 seconds before Teams automatically restarts (only to crash again).
The obvious first step was to fire up Task Manager and see what was up. So, what do I find?
Oh. Okay. That’s not normal. 28 GB of RAM in use even though I’m not running a full SharePoint farm on this laptop? That’s a bit weird. Is OneDrive acting up again?
Let’s take a look…
Ohhhhhh. That’s even more abnormal, and won’t be solved by simply shutting down all 15 OneDrive clients on my machine. Vmmem is something else. What’s going on?
This one was caused by WSL acting up, as Vmmem is the process that represents the memory allocation for your Virtual Machines, and I was most definitely running a bunch of Docker containers as part of my development workflow.
WSL reserves a lot of memory, even if it doesn’t need it. On current Windows builds (technically speaking, pre-20175, but that’s a Windows Insiders build, so most of y’all out there don’t have it), WSL can consume up to 80% of your memory. This has been changed in later builds to be 50%, up to 8GB. Which is still non-trivial, if you plan to run Teams and Chrome at the same time with WSL.
Personally, I ran into this issue on my work laptop, which is running an archaic version of Windows 10 anyway (not something I chose, but hey, that’s corporate IT for you). And probably will be, until Windows 12 is out. So no Insider builds for me (unless Microsoft leaks them in the Current/GA channel again).
Anyway, the gist of the story is, that when running Docker on WSL (in my case, for developing Azure IoT Edge modules), you might find yourself running out of memory very, VERY easily. 😁 As I learned the hard way.
Luckily, this is one of the easiest performance issues to fix, ever. Let’s get to it, then!
This applies to WSL2. If you’re running WSL1, you probably shouldn’t.
Time needed: 20 minutes.
How to solve Vmmem consuming ungodly amounts of RAM when running Docker on WSL?
- Shut down WSL
First of all, we’ll want to get rid of WSL to free up some resources and make sure it picks up our configuration changes later on.
Run this on your command line:
- Find your .wslconfig file
Navigate to %UserProfile% (just paste that text as-is in the address bar of Windows Explorer), and see if you have a .wslconfig file available (make sure you have dotfiles visible first!)
Or you can try adding %UserProfile%/.wslconfig in a text editor directly.
If it doesn’t exist yet, don’t fret – that’s normal. Just create it.
- Edit your .wslconfig file to limit memory usage
You should have something like this in the file:
If you don’t, add it!
- Restart Docker
If you were using Docker, that is :) If you had some other workload, just fire up WSL or whatever depends on it, and it should pick up your new configuration!
And that’s it! Did it help in your case? Let me know in the comments section below!
- What is Vmmem?
- .wslconfig documentation
- Windows 10 builds / channels