"No such interface supported" after upgrade to windows store version of wsl

[tjnsn]

Version

Microsoft Windows [Version 10.0.19044.2311]

WSL Version

• [X] WSL 2
• [ ] WSL 1

Kernel Version

No response

Distro Version

Ubuntu

Other Software

No response

Repro Steps

I had wsl2 working just fine then when i saw wsl 1.0 was released for win10 i wanted to give it a try. installed KB5020030 and then ran a "wsl --update" store version of wsl was downloaded and installed after this was done, any attempt to run wsl.exe results in

No such interface supported
Error code: Wsl/0x80004002

and then wsl doesnt work any more.

interesting side note: using a different account on the same computer that never used wsl before, i was able to get wsl started and installed, most likely using the pre-windows store version because linux kernel ended up being 4.4 instead of 5.10 something. on that account, running wsl --update makes wsl break with above "No such interface" error and uninstalling the store version from Settings -> Apps makes it work again and wsl session uses the same old 4.4 kernel.

Expected Behavior

A working startup of wsl like before

Actual Behavior

Error: "No such interface supported" and then it doesnt start

Diagnostic Logs

No response

[tjnsn]

Tried uninstalling the store version of wsl on the regular user account and my old Ubuntu wsl dist came back and started to work. and as expected i got this at the top:

Windows Subsystem for Linux is now available in the Microsoft Store!
You can upgrade by running 'wsl.exe --update' or by visiting https://aka.ms/wslstorepage
Installing WSL from the Microsoft Store will give you the latest WSL updates, faster.
For more information please visit https://aka.ms/wslstoreinfo

Obviously i'm not running wsl.exe --update again until someone can explain why it fails or how to fix it.

[tjnsn]

any update to this? the issue still happens with kb5021233 installed (the non preview version)

[lordyavin]

got that error to

[mskwarWSD]

I am also getting this error. I've scoured google for troubleshooting tips and so far nothing has changed the dysfunctional behavior. I'm trying to get docker setup and I'm stuck unable to get WSL running.

[AZ-201]

I‘ve been hitting this issue recently. After some random effort, I can reproduce this and fix it quite easy. As @tjnsn said. run wsl --update will corrupt your wsl command. Remove the Appxpackage that updating installed will get your wsl back. Run Get-AppxPackage |? { $_.Name -like "*WindowsSubsystemforLinux*" } in powershell to get the package fullname, and remove it using Remove-AppxPackage -Package "<packag-full-name>" The actual wsl you're using is probably in "Setting -> Application" called "Windows Subsystem for Linux Update".

[mskwarWSD]

Unfortuneately, Get-AppxPackage |? { $_.Name -like "*WindowsSubsystemforLinux*" } did not return anything for me when ran in powershell as admin.

[Jecvay]

any update to this? only the inbox version can running correctly. once install the store version then everything broken

[chicagobuss]

same problem here. Can't uninstall the "store app" - it seems like it's in a bad state. Please help - this is a huge productivity killer for me. Also, it's pretty shameful that you recommended people to perform this upgrade and it completely bricks their wsl environments.

[Michiel-s]

I‘ve been hitting this issue recently. After some random effort, I can reproduce this and fix it quite easy. As @tjnsn said. run wsl --update will corrupt your wsl command. Remove the Appxpackage that updating installed will get your wsl back. Run Get-AppxPackage |? { $_.Name -like "*WindowsSubsystemforLinux*" } in powershell to get the package fullname, and remove it using Remove-AppxPackage -Package "<packag-full-name>" The actual wsl you're using is probably in "Setting -> Application" called "Windows Subsystem for Linux Update".

This did the trick for me. Thank you very much @AZ-201

[chrisjaquet]

As another sample point I ran into also this issue after a fresh install of Windows 10. After installing Windows I installed the WSL from the Windows Store. After installation completed, running the wsl command would give

This application requires the Windows Subsystem for Linux Optional Component.
The system may need to be restarted so the changes can take effect.
Error code: Wsl/WSL_E_WSL_OPTIONAL_COMPONENT_REQUIRED

A reboot does not fix this.

Also, running wsl --install ubuntu leads to the following output:

Installing: Ubuntu
Ubuntu has been installed.
Launching Ubuntu...
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80004002
Error: 0x80004002 No such interface supported

Press any key to continue...
The installation process for distribution 'Ubuntu' failed with exit code: 1.
Error code: Wsl/InstallDistro/WSL_E_INSTALL_PROCESS_FAILED

which is the error mentioned here and at #9014.

To get things working I removed both WSL and the Ubuntu install using "Apps & Features". Once that was done, from the command line I ran wsl --install --no-distribution:

The requested operation requires elevation.
Installing: Virtual Machine Platform
Virtual Machine Platform has been installed.
Installing: Windows Subsystem for Linux
Windows Subsystem for Linux has been installed.
Installing: Windows Subsystem for Linux
Windows Subsystem for Linux has been installed.
The requested operation is successful. Changes will not be effective until the system is rebooted.

After rebooting, I could install Ubuntu (and other distributions happily). It seems that when installing from the Windows Store directly it does not install the required dependencies:

• Virtual Machine Platform
• Windows Subsystem for Linux and this is confirmed in the "Windows Features" control panels settings window:

I was not sure that it was installing the Windows Store version of WSL, but going into the Windows Store app it only has the option to "open" and running X apps works correctly, so I am assuming that it has installed the store version of the app.

[faddaful]

@chrisjaquet This works for me absolutely. Thank you.

[tjnsn]

As another sample point I ran into also this issue after a fresh install of Windows 10. After installing Windows I installed the WSL from the Windows Store. After installation completed, running the wsl command would give

This application requires the Windows Subsystem for Linux Optional Component.
The system may need to be restarted so the changes can take effect.
Error code: Wsl/WSL_E_WSL_OPTIONAL_COMPONENT_REQUIRED

A reboot does not fix this.

Also, running wsl --install ubuntu leads to the following output:

Installing: Ubuntu
Ubuntu has been installed.
Launching Ubuntu...
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80004002
Error: 0x80004002 No such interface supported

Press any key to continue...
The installation process for distribution 'Ubuntu' failed with exit code: 1.
Error code: Wsl/InstallDistro/WSL_E_INSTALL_PROCESS_FAILED

which is the error mentioned here and at #9014.

To get things working I removed both WSL and the Ubuntu install using "Apps & Features". Once that was done, from the command line I ran wsl --install --no-distribution:

The requested operation requires elevation.
Installing: Virtual Machine Platform
Virtual Machine Platform has been installed.
Installing: Windows Subsystem for Linux
Windows Subsystem for Linux has been installed.
Installing: Windows Subsystem for Linux
Windows Subsystem for Linux has been installed.
The requested operation is successful. Changes will not be effective until the system is rebooted.

After rebooting, I could install Ubuntu (and other distributions happily). It seems that when installing from the Windows Store directly it does not install the required dependencies:

• Virtual Machine Platform
• Windows Subsystem for Linux and this is confirmed in the "Windows Features" control panels settings window:

I was not sure that it was installing the Windows Store version of WSL, but going into the Windows Store app it only has the option to "open" and running X apps works correctly, so I am assuming that it has installed the store version of the app.

it is not that simple as missing optional features, this is something i have checked many times in my troubleshooting of this. also i have a brand new computer that was working fine with the store version of wsl (1.2.5 i believe) and then all of a sudden broke and i have no idea why. it now behaves just like my older computer i used when i initialy created this ticket.

so new comptuer was working with store, then broke, tried reinstalling and now i have "No such interface supported" as long as store version of wsl is installed. removing it and falling back pre-windows store version works

[tjnsn]

I'm prety sure i know what is triggering this error for me. due to company policy many security related settings have been adjusted, one of them is removal of the default groups "interactive" and "authenticated users" from the local "Users" group.

this in turn causes something in wsl to fail, not sure what exactly, but i suspect it is some user related service or something, perhaps related to the integration of wsl and windows side. and then when you try to do somethign with wsl, all you get is "no such interface" and the error code. wsl --version works but wsl --list does not and errors

adding back the two groups plus a reboot makes it work again, but that is not realy a workabl solution in the long run.

[timbutler-um]

I have the exact same problem. Seemingly out of the blue, my functional store version stopped working with the "no such interface" issue. My machine is also managed by a corporate IT group and I can confirm that your solution regarding the missing "Users" group entities also works for me.

As you say, adding the groups back is not a long term solution, but at least it's in the policy domain. Your diagnosis clears up the technical aspect - thanks much for your diligence.

[tjnsn]

My workaround is to add back: "NT AUTHORITY\Authenticated Users" to the local Users group and then restart the service WslService This service is unfortunately listed with the name: ms-resource:AppName so it was not immediately obvious it is WSL related. (would be nice with a proper name for the service)

Would be nice with some input from microsoft about this, for example is it a must to have authenticated users in the users group or is there a way to make it work without it (prefered due to company policies) @OneBlue ?

[puthuppu]

My workaround is to add back: "NT AUTHORITY\Authenticated Users" to the local Users group and then restart the service WslService This service is unfortunately listed with the name: ms-resource:AppName so it was not immediately obvious it is WSL related. (would be nice with a proper name for the service)

Would be nice with some input from microsoft about this, for example is it a must to have authenticated users in the users group or is there a way to make it work without it (prefered due to company policies) @OneBlue ?

From what I can see with Process Monitor, the wslservice.exe gets ACCESS DENIED when trying to do a CreateFile operation on C:\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftCorporationII.WindowsSubsystemForLinux_1.2.5.0_x64__8wekyb3d8bbwe\PackagedCom\WslServiceProxyStub.dll.

I'm not sure how it's related, but I was able to get by with just adding "BUILTIN\SYSTEM" to the users group instead of all authenticated users.

[abhishekmaha23]

Adding to the local Users group seemed risky, so I didn't try this - but I hope somebody with a clearer understanding of the consequences of adding users can help understand what that would cause.

I've found that on the base version of wsl, running wsl --install --inbox works to update the WSL kernel to 5.10.102.1, but WSL itself doesn't play well with updating (I try with Add-AppxPackage and am able to revert with the Get-AppxPackage and Remove-AppxPackage) , I keep getting the "No such interface found". Interestingly, the kernel gets updated alongside the wsl to the following versions:

WSL version: 1.3.11.0 Kernel version: 5.15.90.2-3 WSLg version: 1.0.54 MSRDC version: 1.2.4240 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25880.1000-230602-1350.main Windows version: 10.0.19045.3086

I've tried with a few different versions (you can see 1.3.11 (preview) above, but the store version of 1.2.5 also fails)

As mentioned above, reverting to the base version with the method from @AZ-201 still works, and my data isn't lost (I backed it up just in case)

I‘ve been hitting this issue recently. After some random effort, I can reproduce this and fix it quite easy. As @tjnsn said. run wsl --update will corrupt your wsl command. Remove the Appxpackage that updating installed will get your wsl back. Run Get-AppxPackage |? { $_.Name -like "*WindowsSubsystemforLinux*" } in powershell to get the package fullname, and remove it using Remove-AppxPackage -Package "<packag-full-name>" The actual wsl you're using is probably in "Setting -> Application" called "Windows Subsystem for Linux Update".

I'd still love to be able to use wslg from the releases - MobaXterm still lags a bit for my taste Any help is appreciated!

[jcrben]

Faced the same issue on a secured corporate machine. I ran this from an elevated cmd.exe shell:

net localgroup users "nt authority\authenticated users" /add

Seems to have fixed it. I got that command from https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/add-special-groups-to-built-in-groups

I downloaded and installed WSL 1.25.1 from the releases and installed like this from powershell: add-appxpackage .\Microsoft.WSL_1.2.5.0_x64_ARM64.msixbundle

[ysn2233]

There is no solution to use new version of WSL if company don't allow to change the localgroup user?

[hjwmedenblik]

I'm prety sure i know what is triggering this error for me. due to company policy many security related settings have been adjusted, one of them is removal of the default groups "interactive" and "authenticated users" from the local "Users" group.

this in turn causes something in wsl to fail, not sure what exactly, but i suspect it is some user related service or something, perhaps related to the integration of wsl and windows side. and then when you try to do somethign with wsl, all you get is "no such interface" and the error code. wsl --version works but wsl --list does not and errors

adding back the two groups plus a reboot makes it work again, but that is not realy a workabl solution in the long run.

Hi, good work! We experienced similar issues. Although the fix is clear, I am much more interested how you have been able to pinpoint it to this cause. Solutions are always nice but the road to find it is much more useful.

[tjnsn]

I'm prety sure i know what is triggering this error for me. due to company policy many security related settings have been adjusted, one of them is removal of the default groups "interactive" and "authenticated users" from the local "Users" group. this in turn causes something in wsl to fail, not sure what exactly, but i suspect it is some user related service or something, perhaps related to the integration of wsl and windows side. and then when you try to do somethign with wsl, all you get is "no such interface" and the error code. wsl --version works but wsl --list does not and errors adding back the two groups plus a reboot makes it work again, but that is not realy a workabl solution in the long run.

Hi, good work! We experienced similar issues. Although the fix is clear, I am much more interested how you have been able to pinpoint it to this cause. Solutions are always nice but the road to find it is much more useful.

well.... pure luck mostly.

on my old computer i always assumed the broken wsl was due to a fault of me messing something up. all i knew was that only the pre windows store version worked, any atempt to run the store version caused wsl to break.

so i figured i give it a new try after getting a new computer. and to my surprise the store version worked imediately and worked fine for a couple of weeks. so i, incorrectly, assumed problem was solved and it was my fault somehow that it broke it on the old computer.

after a few weeks it broke again and this time it was definitely not my fault so that got me to troubleshoot it. this happen to coincide with a change and apparently the policy related to authenticated users had been temporarily turned off for a few weeks (when it worked for me after computer replacement). then it was just a matter to test and confirm it.

so it was down to a computer replacement, timing and some luck.

now it would be nice with some feedback from MS about this. either fix the issue or bare minimum update the wsl documentation section regarding running wsl in a corporate environment so it includes the need for authenticated users.

[philippjenni]

I have found a workaround for the problem that does not require adding the "authenticated users" group to the "users" group. The problem is that WSL wants to run a process in the App Package folder, but the permissions for the System Account do not allow it because the permission inheritance has been broken.

If you start a CMD as System Account using PSEXEC (psexec -i -s cmd.exe) and set the permissions of the folder with the command icacls C:\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftCorporationII.WindowsSubsystemForLinux_1.2.5.0_x64__8wekyb3d8bbwe\PackagedCom /grant System:(OI)(CI)(X) /inheritance:d corrected, WSL2 works with the latest release.

Why the permissions in the directory are wrong, Microsoft would have to answer. However, this is a workaround, with which you can you don't have to soften the company policy.

Probably you will have to correct the permissions again after each update.

[tjnsn]

I have found a workaround for the problem that does not require adding the "authenticated users" group to the "users" group. The problem is that WSL wants to run a process in the App Package folder, but the permissions for the System Account do not allow it because the permission inheritance has been broken.

If you start a CMD as System Account using PSEXEC (psexec -i -s cmd.exe) and set the permissions of the folder with the command icacls C:\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftCorporationII.WindowsSubsystemForLinux_1.2.5.0_x64__8wekyb3d8bbwe\PackagedCom /grant System:(OI)(CI)(X) /inheritance:d corrected, WSL2 works with the latest release.

Why the permissions in the directory are wrong, Microsoft would have to answer. However, this is a workaround, with which you can you don't have to soften the company policy.

Probably you will have to correct the permissions again after each update.

Good catch, havent tested this yet but i'm prety sure it will work. Using sysinternals procmon you can see that wslservice.exe is trying to open that path and fails with an access denied because of the permissions. The service is running as SYSTEM and the permissions on the PackagedCom folder does not grant SYSTEM the execute permission and the only reason it does get execute permission is because authenticated users membership in users group makes SYSTEM part of the Users group and Users do have the needed permissions.

some searching for PackagedCom pointed me to: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/

[Reflyer823]

I have found a workaround for the problem that does not require adding the "authenticated users" group to the "users" group. The problem is that WSL wants to run a process in the App Package folder, but the permissions for the System Account do not allow it because the permission inheritance has been broken.

If you start a CMD as System Account using PSEXEC (psexec -i -s cmd.exe) and set the permissions of the folder with the command icacls C:\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftCorporationII.WindowsSubsystemForLinux_1.2.5.0_x64__8wekyb3d8bbwe\PackagedCom /grant System:(OI)(CI)(X) /inheritance:d corrected, WSL2 works with the latest release.

Why the permissions in the directory are wrong, Microsoft would have to answer. However, this is a workaround, with which you can you don't have to soften the company policy.

Probably you will have to correct the permissions again after each update.

This actually works! This should be the most perfect solution at the moment. Thank you very much.

[tjnsn]

With the just released v2.0.0 preview version of wsl the problem appears to be solved. Upgraded a test computer from 1.2.5 to 2.0.0 and started wsl without adding authenticated users back and without adjusting the previously discussed folder permissions and it started just fine.

with the experimental dns tunneling (not tested it yet since it requries an insider preview version of windows) and the authenticated users problem my main two problems appear to finaly be solved.

now i just have to wait until next stable relase and hopefully some future windows update.

[wcbutler]

I had no issues in Win 10 on my work PC with WSL. In place upgrade to Win 11 then running WSL it prompted me to run wsl.exe --upgrade which broke my containers and uninstall reinstall isn't working. Working through some of the fixes here to hopefully solve.

[tjnsn]

now that wsl 2.0.9 is not a prerelease any more i'm going to close my own ticket. the issue was caused by removal of authenticated users and 2.0.9 no longer have the problem