Wsl/ERROR_NOT_FOUND after installing Windows updates

[target-san]

Windows Version

Microsoft Windows [Version 10.0.19045.3693]

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

N/A

Distro Version

N/A

Other Software

No response

Repro Steps

Install Windows updates (possibly KB5032189)

Expected Behavior

Wsl works

Actual Behavior

Error:

Element not found.
Error code: Wsl/ERROR_NOT_FOUND

Diagnostic Logs

WslLogs-2023-11-17_09-50-38.zip

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• WSL failed to start after update Windows (#4939), similarity score: 0.89
• WSL not working after windows update (#10185), similarity score: 0.89
• Latest Windows update uninstalled WSL (#9355), similarity score: 0.87
• WSL doesnt start after Windows Update (#5722), similarity score: 0.87
• WSL Not working after windows 11 updates (#7379), similarity score: 0.86

Closed similar issues:

• WSL stopped working after latest windows update (#8133), similarity score: 0.87
• Windows Update Destroys WSL System (#1195), similarity score: 0.86
• Windows updates disabled - Can't upgrade to WSL 2 (#6132), similarity score: 0.85
• Can't update WSL2 (#10527), similarity score: 0.85
• Unable to update to WSL2 (#5309), similarity score: 0.85

You can give me feedback by thumbs upping or thumbs downing this comment.

[CHADT10]

Try this #10764 (comment)

[target-san]

Didn't work. I erased service record, uninstalled WSL components from installer. Now I cannot even install it, installer simply closes immediately. WSL CLI returns same error.

[target-san]

wsl --install ends with 0x80070490
Is there some proper way to clean WSL completely and then reinstall from scratch?
Or some comprehensive registry of WSL errors?

[target-san]

After wsl --update and installing required kernel update MSI, I'm down to square one, Wsl/ERROR_NOT_FOUND

[OneBlue]

@target-san: I'm not seeing anything in the logs you shared.

Can you try to manually install the latest release and see if that helps ?

Please share /logs again if a failed startup if that doesn't help

[target-san]

@OneBlue
wsl.2.0.9.0.x64.log.zip
Well, according to log installation succeeded 🤷
As of logs, I'm getting issue with importing AppX module . Was present before reinstall, just didn't notice. Need to solve before I get real logs. Honestly it's extremely frustrating how MS products tend to hide error information at all cost.

[target-san]

Finally logs:
WslLogs-2023-11-18_07-54-11.zip

[osavoskin]

@target-san

I have just run into this issue myself. Spent half a day trying to fix it. Nothing has worked except for:

• reinstall of the windows components: virtual machines support & wsl support
• uninstall all the wsl updates
• wsl --install --no-distribution
• now wsl --status at least produces the report, but requires an update
• run wsl --update --inbox (only the kernel)

Now you should be able to run your containers, at least. But any update to wsl (up to 2.0.9) will break it again, unfortunately.

** I guess the windows components reinstallation step is excessive and can be skipped. Try to just uninstall all the wsl updates and update the kernel (--inbox) to make it work.

[pahar0]

Launching WSL from a terminal with administrator privileges works for me. #10788 (comment)

[target-san]

@pahar0 Yup, thanks. Works for me too. At least for now.
Though it's interesting what causes this requirement out of thin air.

[osavoskin]

Launching WSL from a terminal with administrator privileges works for me. #10788 (comment)

Hm, does not work for me, for some reason..

[pahar0]

Launching WSL from a terminal with admin privs it's a workaround while we wait for a proper solution. We should be able to run it as a regular user.
@osavoskin interesting... could you try this #10793 (comment) ?
I know the problem is not related but this could be another possible solution.

[osavoskin]

@pahar0
Doesn’t help either. I have already tried everything. The only thing that worked is uninstalling all the updates. It allows me to work, at least. But the cli becomes unresponsive when the —shutdown command executed. So, the UX is awful

[DemonPenguin]

Same issue, but I have also noticed that wslg.exe is missing and I can't seem to get it back no matter what I do

[baiciluigi]

Same issue, can only run wsl with admin rights, everything else fails. Have to manually run it on admin.
Docker Desktop fails, but when launched with admin rights, succeeds aswell.
For now I can work like this but it needs to be fixed..

[bsatts]

Yup running with admin rights is the only thing that works atm.

I wonder if this is related to the patch this latest update pushed regarding an Elevation of Privilege vulnerability. Cause i've had similar issues with other tools like powertools or autohotkey

[OneBlue]

Thanks everyone for reporting this.

To give some clarity: there are two issues with WSL 2.0.9:

1. Wsl/CallMSI/E_ABORT

We've identified the issue and working on a fix. You can workaround it by enabling the WSL optional component and rebooting

2. Wsl/ERROR_NOT_FOUND

We've not been able to reproduce the issue yet. We're investigating but to root cause it we'd need COM logs.

If you can reproduce the issue, please follow these instructions to collect logs:

• Download and extract ComTrace.wprp
• Open an elevated command prompt
• Run: wpr -start ComTrace.wprp -filemode
• Reproduce the issue (example: wsl.echo echo test)
• Run wpr -stop logs.etl
• Share logs.etl on this issue

[bsatts]

@OneBlue The problem is wsl works when the command is launched from an elevated terminal. That is the current workaround for the issue. Can we get the trace from a non-elevated terminal?

[OneBlue]

@OneBlue The problem is wsl works when the command is launched from an elevated terminal. That is the current workaround for the issue. Can we get the trace from a non-elevated terminal?

@bsatts: Yes you can start the trace from an elevated terminal and then reproduce the issue from another, non-elevated terminal. The log collection will capture that repro

[bsatts]

Thank you. I started the wpr, then opened a new command prompt and typed wls. Then ended the wpr

logs.zip

[OneBlue]

Thank a lot @bsatts. We're getting closer.

Can you try to execute: C:\Program Files\WSL\wsl.exe as non-elevated and see if that works ?

[pahar0]

Some logs @OneBlue
logs.zip

Also:

If i open wsl.exe by double-clicking on the icon directly from the C:\Program Files\WSL\ folder a PowerShell opens and gets closed immediately.

[OneBlue]

Thank you @bsatts and @pahar0. We have a theory now. To validate it, could you please use regedit to export the content of HKLM\Software\Classes\PackagedCom and share the .reg file with us ?

[pahar0]

regedit.zip
There you go @OneBlue

[OneBlue]

Thank you @pahar0. This confirms our theory: There is an old WSL installation that's conflicting with the latest package.

Can you try to:

• Delete: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E}
• See if that solves the issue

(You can use the .reg you just captured as backup if needed)

[benhillis]

Thanks for all the help on this folks. This is a strange MSIX / packaged COM issue that we have not seen in internal testing. I know this issue is causing you all a lot of pain, and I'm hopeful we will have a fix to push out before turkey day.

[pahar0]

Issue solved deleting HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E} in regedit.
Thank you guys @OneBlue @benhillis

[OneBlue]

Thank for confirming @pahar0. So this confirms that the issue is this registry key being left over by previous install. We'll update our install logic to automatically remove it in the next update.

[Alkarex]

On Windows 10, just deleting the newest WSL entry in the list of Windows applications worked for me #10767 (comment)

[rgaiacs]

I also had the same issue and confirm that deleting HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E} in regedit resolve the issue.

[target-san]

Same for me. Erasing that key solved issue permanently.

[DemonPenguin]

Deleting the key worked for me. Now to sort out the display issue on wslg which seems to have a weird overlay on top of GUI apps.

[benhillis]

Thanks for the confirmation! @OneBlue is working on a fix now.

[aleluis79]

I added a dash to the old keys. That worked for me.

[AKN-CPH]

Issue solved deleting HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E} in regedit. Thank you guys @OneBlue @benhillis

THANK YOUUUUUUU. Deleting the reg. key also solved all WSL update problems for me.

[benhillis]

Fixed with https://github.com/microsoft/WSL/releases/tag/2.0.11.

[andjsouza]

Issue solved deleting HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\ClassIndex\{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E}

Thanks :)

[lukasz-mitka]

Fixed with 2.0.11 (release).

wsl --update was unable to pick it up. Had to manually install msi from the release.

[truongleeuet]

I found a solution in: here. You can try it

[weylin-piegorsch]

For others coming here and trying to verify their registry:

I installed the .msi from an unmodified registry (I changed the name to get work done, then reverted to the stock name before installing 2.0.11). These keys appeared before the install, and no longer appear after:
{A9B7A1B9-0671-405C-95F1-E0612CB4CE7E}
{B5AEB4C3-9541-492F-AD4D-505951F6ADA4}

I'm now working fine without needing to make manual registry edits.

I think one of these (or perhaps some combination of all?) are the registry key(s) for 2.0.11:
{F122531F-326B-4514-85AE-DC99D31D8256}
{C8F673A8-4BAB-420E-94E3-BFDB19740697}
{60285AE6-AAF3-4456-B444-A6C2D0DEDA38}
{1D5CE30F-C0EF-4182-83BA-196F9DE07BB9}

At least, they exist after I installed 2.0.11; I don't know if they existed before but they're all include a subkey MicrosoftCorporationII.WindowsSubsystemForLinux_1.2.0.0_x64__8wekyb3d8bbwe

[gignsky]

Can confirm installing version 2.0.11 (pre-release) works in resolving this issue of not being able to access WSL without elevated privileges.