If you’ve tried setting up WSL2Host.exe to use with a WSL GUI Full Desktop, or for some other reason, but you sign in to your computer using a Microsoft account (rather than a local account) then you’ve probably struggled.
The fix requires some steps – and they’re a pain in the butt. It’s not Shayne’s fault, it’s the way Windows works. The answers are available on the Github page at https://github.com/shayne/go-wsl2-host/issues/10 but they’re not particularly easy to follow unless you’re fairly familiar with Windows admin.
So this post will address that….
So you try running WSL2Host.exe install and you put in your username and password. And it accepts it and everything looks great. Until you try to connect to ubuntu2004.wsl (or whichever distro you installed) and it doesn’t work. So you check your Windows hosts file thusly and you’re missing the .wsl entry…
This is more than likely because you’re using a Microsoft Account to login to your Windows system and even though you entered your username and password correctly it’s not worked because Microsoft Accounts can’t, by default, run Windows Services.
So now we need to fix it. Fortunately it’s fairly straightforward but does involve a couple of processes.
Fix The Service Permissions
Firstly, in the Cortana / Search box at the bottom left (usually) of your screen, type in the following;
Then click the Services App link to open it. You will probably be prompted to allow Adminstrator execution of the program. This will open up the Services applet which allows you to control all the different background services that are running on your computer. WSL2Host is installed as a service but probably not started.
Clicking the Start the service link waits a few seconds and then tells you it cannot start the service due to a logon failure.
This happens for one of two reasons. Either, you really didn’t enter your username and password correctly – or you’re using a Microsoft Account to login to Windows.
So, right click over the WSL2Host service and choose Properties. Then choose the Log On tab at the top. You should see a dialog box like on the right of the screen.
Click on the Browse… button to open up the user browser screen. Then click the Advanced… button from that screen. Then click the Find Now button which will bring up a section at the bottom of the dialog where you can see all the different users on your computer. Most are likely to be system users that can be ignored. Look for the one that looks like it’s your username.
In my case it’s my name of course. The picture to the left should be similar to what you’ll be seeing. Highlight your username then click OK. Then click OK again and you should see the Windows username (it may be a shortened form) in the window. Enter and Re-Enter your password just to be sure, then click OK.
Some people have had success just by following those steps, so it’s worth trying to start the service at this point. If it works, you’re finished. If it doesn’t (and you’re sure you have the right password) keep reading.
Fix The Local Security Policy
Windows 10 Home Users Additional Step First
If you’re on Windows 10 Home you’re going to need to do an additional step before you can fix the Local Security Policy. Thanks to MajorGeeks for documenting this one. Click here if you’re on Windows 10 Home. Windows 10 Professional already has the necessary software to continue to the next steps.
All Users Next Step
From the taskbar search box again, type Local Security Policy and you should see something like the image to the right. Click on Run As Administrator to open up the local security policy editor.
Navigate to the Local Policies -> User Rights Assignment and then find the Logon As A Service rights and double click it. The image to the left shows you an idea of where to look.
Click the Add User Or Group… button in the dialog that pops up and then go through the same procedure as you did for adding your username to the Service users.
Once your username is added as an account that has the rights to logon as a service you’re almost done. But there’s one final step.
Login To Windows With A Password
For some reason, you’ll need to login to Windows with a password rather than a Windows Hello PIN or Face recognition. To do this you can either restart your computer and tell it you want to login with your password instead – or you can simply lock the screen by pressing the WIN-L combination and the unlock by giving your password instead of the PIN.
To unlock your screen if you have a PIN set up you’ll need to tell Windows that you’ve forgotten your PIN. It’ll then go through a series of fairly self explanatory questions and answers and then you can put your password in instead.
If The Password Login Option Isn’t Available
More recent versions of Windows (or at least in my case) sometimes won’t even offer you the option to login with your password. Unfortunately, you need to login with your password at least once to get this all working.
Fortunately, it turns out it’s an option that switched on in the Settings. You’ll need to open up the Settings app, choose Accounts -> Sign In Options and look for the toggle switch that says Require Windows Hello Sign-In For Microsoft Accounts. If it’s switched on, switch it off. Then follow the procedure above to Login To Windows With A Password.
Once you have logged in once you can switch the Windows Hello requirement back on. Passwords are insecure. I long for the day when Digi-ID can be used to login to Windows, and web sites…
Start The WSL2Host Service
Once you’ve done all that you should be able to go back to the Services applet and start the service.
You may also find – unless you did the password bit via a reboot – that you need to restart your WSL instance. You can do this from CMD or Powershell with the command;
When you re-open a WSL prompt it’ll restart the WSL instance and you should find your \Windows\System32\drivers\etc\hosts file now has an extra entry for your WSL instance.
WSL2Host Silently Fails
If you have done all of the above and WSL2Host starts correctly but nothing is updated in your hosts file and when you check Services again the service has stopped, you may have the problem whereby your default WSL instance is no longer what you thought it was.
This happened to me. I run Docker Desktop and presumably had done something to cause the Docker Desktop WSL instance to become my default WSL instance. I didn’t realise this had happened. I probably unregistered my Ubuntu instance or something. Anyway… The fix for this is to make an actual WSL instance the default instead of the Docker Desktop instance. Everything sprang into life again when I did that.