0xc0000022 startup error when opening wt from file explorer or Run window #9859

@DHowett commented on GitHub (Jul 27, 2020):

If you turn the non-preview one off and the preview one on, does the behavior change?

@DHowett commented on GitHub (Jul 27, 2020): If you turn the non-preview one off and the preview one on, does the behavior change?

claunia commented

@JakubKoralewski commented on GitHub (Jul 28, 2020):

I uninstalled the Preview version and now everything seems to work.

If you turn the non-preview one off and the preview one on, does the behavior change?

It didn't. I restarted, tried again and it was the same error. Only difference was where wt showed only the path to WindowsApps\wt.exe and the Preview had disappeared.

@JakubKoralewski commented on GitHub (Jul 28, 2020): I uninstalled the Preview version and now everything seems to work. > If you turn the non-preview one off and the preview one on, does the behavior change? It didn't. I restarted, tried again and it was the same error. Only difference was `where wt` showed only the path to `WindowsApps\wt.exe` and the Preview had disappeared.

claunia commented

@DHowett commented on GitHub (Jul 31, 2020):

This is very strange. Thank you for reporting. Just to confirm: now that you've removed preview, it works fine? That is very unexpected 😄

@DHowett commented on GitHub (Jul 31, 2020): This is very strange. Thank you for reporting. Just to confirm: now that you've removed preview, it works fine? That is very unexpected :smile:

claunia commented

@JakubKoralewski commented on GitHub (Jul 31, 2020):

Yes, it's been working fine since I removed Preview. Seems weird, but I'm just happy everything's working 🥰 . Also since it seems tab renaming has hit stable, Preview lost the major thing I've been using it for, so all is good now in my book.

@JakubKoralewski commented on GitHub (Jul 31, 2020): Yes, it's been working fine since I removed Preview. Seems weird, but I'm just happy everything's working 🥰 . Also since it seems tab renaming has hit stable, Preview lost the major thing I've been using it for, so all is good now in my book.

claunia commented

@DHowett commented on GitHub (Aug 4, 2020):

Thanks for following up! I'm gonna close this out as not reproducing, but please do let me know if it comes back.

@DHowett commented on GitHub (Aug 4, 2020): Thanks for following up! I'm gonna close this out as not reproducing, but please do let me know if it comes back.

claunia commented

@JakubKoralewski commented on GitHub (Sep 28, 2020):

please do let me know if it comes back.

It did :(

It seems when I type wt into the explorer it's using this path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe (it flashes very briefly in the explorer URL input and can be retrieved), while where wt returns a more sane C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe. And opening the first path in cmd returns the same error as running in explorer, but running the second path is not a recognized command...:

C:\Windows\System32>"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe"

C:\Windows\System32>C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe
'C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe' is not recognized as an internal or external command,
operable program or batch file.

After the above, I tried reinstalling, but the same error happens. So I tried to uninstall it again and this time I tried removing all these folders:

but I can't remove it all because some files are either opened in another program or I need "SYSTEM" permissions to remove them. I tried changing one of the folder's owner to myself, but when trying to uninstall it says I need permissions from myself to uninstall.

After reinstalling, I removed %USERPROFILE%\AppData\Local\Microsoft\WindowsApps folder from user Path and now the error remains when starting from the explorer, but it doesn't work at all when typed into the cmd:

C:\Windows\System32>wt.exe
'wt.exe' is not recognized as an internal or external command,
operable program or batch file.
C:\Windows\System32>where wt
INFO: Could not find files for the given pattern(s).

Is there a way to force the use of %USERPROFILE%\AppData\Local\Microsoft\WindowsApps instead of C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe ?

@JakubKoralewski commented on GitHub (Sep 28, 2020): > please do let me know if it comes back. It did :( ![image](https://user-images.githubusercontent.com/43069023/94405962-96ed5300-0171-11eb-9f8e-a8a588a3eb3c.png) It seems when I type `wt` into the explorer it's using this path: `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe` (it flashes very briefly in the explorer *URL* input and can be retrieved), while `where wt` returns a more sane `C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe`. And opening the first path in `cmd` returns the same error as running in explorer, but running the second path is not a recognized command...: ```cmd C:\Windows\System32>"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe" C:\Windows\System32>C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe 'C:\Users\Admin\AppData\Local\Microsoft\WindowsApps\wt.exe' is not recognized as an internal or external command, operable program or batch file. ``` After the above, I tried reinstalling, but the same error happens. So I tried to uninstall it again and this time I tried removing all these folders: ![image](https://user-images.githubusercontent.com/43069023/94407356-a66d9b80-0173-11eb-91e9-630b04289dd6.png) but I can't remove it all because some files are either opened in another program or I need "SYSTEM" permissions to remove them. I tried changing one of the folder's owner to myself, but when trying to uninstall it says I need permissions from myself to uninstall. After reinstalling, I removed `%USERPROFILE%\AppData\Local\Microsoft\WindowsApps` folder from user `Path` and now the error remains when starting from the explorer, but it doesn't work at all when typed into the `cmd`: ``` C:\Windows\System32>wt.exe 'wt.exe' is not recognized as an internal or external command, operable program or batch file. C:\Windows\System32>where wt INFO: Could not find files for the given pattern(s). ``` Is there a way to force the use of `%USERPROFILE%\AppData\Local\Microsoft\WindowsApps` instead of `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe` ?

claunia commented

@DHowett commented on GitHub (Sep 28, 2020):

This usually happens when you change the permissions on C:\Program Files\WindowsApps. It is an important part of the app platform on Windows and not something Terminal can recover from when it is broken.

Given that you had no trouble accessing that folder, consider restoring the permissions and removing and reinstalling all instances of Terminal so that they get put back with the correct permissions.

@DHowett commented on GitHub (Sep 28, 2020): This usually happens when you change the permissions on `C:\Program Files\WindowsApps`. It is an important part of the app platform on Windows and not something Terminal can recover from when it is broken. Given that you had no trouble _accessing that folder_, consider restoring the permissions and removing and reinstalling all instances of Terminal so that they get put back with the correct permissions.

claunia commented

@JakubKoralewski commented on GitHub (Oct 18, 2020):

This is crazyyy. I did a restore first with and then without keeping data, but the WindowsApps permissions problem was still there, where the Windows Store or any other built-in app for that matter would not turn on. I am now very finickly at a reverse stage where it works when called from the explorer, but doesn't (incorrect parameter) when called from a shortcut.

I have no idea how a permission problem can persist after system reinstall. This is crazy. I guess somehow it's in the cloud in my Windows user profile... 🤷

EDIT: Is there a way something could have persisted if I chose to restore the system? Is it identical to a clean install cause I want to get rid of this for goood

EDIT2: 🎉 solution as simple as drive format, ez fix 😄

@JakubKoralewski commented on GitHub (Oct 18, 2020): This is crazyyy. I did a restore first with and then without keeping data, but [the WindowsApps permissions problem was still there](https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_store-winpc/windows-10-store-and-most-apps-wont-open/727305b7-9f1b-46a7-a548-d5dd0fe25234), where the Windows Store or any other built-in app for that matter would not turn on. I am now very finickly at a reverse stage where it works when called from the explorer, but doesn't (incorrect parameter) when called from a shortcut. I have no idea how a permission problem can persist after system reinstall. This is crazy. I guess somehow it's in the cloud in my Windows user profile... 🤷 EDIT: Is there a way something could have persisted if I chose to restore the system? Is it identical to a clean install cause I want to get rid of this for goood EDIT2: 🎉 solution as simple as drive format, ez fix 😄

claunia commented

@zachHixson commented on GitHub (Oct 20, 2020):

I am getting this issue starting this morning. Windows updated something (I think security related) and when I booted up I get the same error. Unfortunately for me, drive formatting isn't really an option as it's just not worth it.

Currently I'm just switching back to powershell, but it would be nice if there was a fix/solution for this

@zachHixson commented on GitHub (Oct 20, 2020): I am getting this issue starting this morning. Windows updated something (I think security related) and when I booted up I get the same error. Unfortunately for me, drive formatting isn't really an option as it's just not worth it. Currently I'm just switching back to powershell, but it would be nice if there was a fix/solution for this

claunia commented

@dwright726 commented on GitHub (Oct 21, 2020):

I too started getting this error out of the blue this morning no updates have been applied (to my knowledge) worked yesterday afternoon, I've already spent 1-2hours trying to figure it out. My answer is just to abandon the terminal all together this is the second time I have ran into issues with it that has led to multiple hours of troubleshooting, at this point the benefits of wt are no longer worth the technical debt

@dwright726 commented on GitHub (Oct 21, 2020): I too started getting this error out of the blue this morning no updates have been applied (to my knowledge) worked yesterday afternoon, I've already spent 1-2hours trying to figure it out. My answer is just to abandon the terminal all together this is the second time I have ran into issues with it that has led to multiple hours of troubleshooting, at this point the benefits of wt are no longer worth the technical debt

claunia commented

@dexeonify commented on GitHub (Oct 25, 2020):

I've found a solution from another thread which seems to solve this issue.

Just taking ownership and granting read/execute permission to "Users" for single file "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\vcruntime140.dll" fixed issue for me. No need to mess with whole WindowsApps folder permissions

@dexeonify commented on GitHub (Oct 25, 2020): I've found a solution from another thread which seems to solve this issue. > Just taking ownership and granting read/execute permission to "Users" for single file "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\vcruntime140.dll" fixed issue for me. No need to mess with whole WindowsApps folder permissions

claunia commented

@zachHixson commented on GitHub (Oct 25, 2020):

@dexeonify I had to take control of the WindowsApps folder first, and while I was able to take ownership of vcruntime140.dll, when I go to edit permissions it gives me an error saying "The access control entry is corrupt. Delete it and Create a new one." Guides online on how to do this seem spotty at best.

@zachHixson commented on GitHub (Oct 25, 2020): @dexeonify I had to take control of the WindowsApps folder first, and while I was able to take ownership of vcruntime140.dll, when I go to edit permissions it gives me an error saying "The access control entry is corrupt. Delete it and Create a new one." Guides online on how to do this seem spotty at best.

claunia commented

@dexeonify commented on GitHub (Oct 26, 2020):

Hmm, weird. I didn't face any issues when using that method.

Here's how I did it:

Head over to "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe" and find vcruntime140.dll.
Click "Properties" > "Security" > "Advanced" and change the ownership to your current user.
Click "Apply" and "Ok" and close the Properties window.
Reopen "Properties" > "Security" > "Edit", select "PCNAME\Users" and grant it read/execute permission.

If it's corrupt, I guess you have to remove it and add a new one.

@dexeonify commented on GitHub (Oct 26, 2020): Hmm, weird. I didn't face any issues when using that method. Here's how I did it: 1. Head over to "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe" and find `vcruntime140.dll`. 2. Click "Properties" > "Security" > "Advanced" and change the ownership to your current user. 3. Click "Apply" and "Ok" and close the Properties window. 4. Reopen "Properties" > "Security" > "Edit", select "PCNAME\Users" and grant it read/execute permission. If it's corrupt, I guess you have to remove it and add a new one.

claunia commented

@zachHixson commented on GitHub (Oct 26, 2020):

The problem was I wasn't able to access WindowsApps without first taking ownership. I also have no idea how to delete that file, or where it is.

@zachHixson commented on GitHub (Oct 26, 2020): The problem was I wasn't able to access WindowsApps without first taking ownership. I also have no idea how to delete that file, or where it is.

claunia commented

@Gameghostify commented on GitHub (Oct 29, 2020):

Suddenly got this issue as well, ~~without touching my installation~~ after updating through the Store

However, @dexeonify's steps have helped. To be exact, taking ownership of the Windows Terminal folder in C:\Program Files\WindowsApps fixed the problem

Please consider reopening this issue

@Gameghostify commented on GitHub (Oct 29, 2020): Suddenly got this issue as well, ~~without touching my installation~~ after updating through the Store However, @dexeonify's steps have helped. To be exact, taking ownership of the Windows Terminal folder in C:\Program Files\WindowsApps fixed the problem Please consider reopening this issue

claunia commented

@cjpellicci commented on GitHub (Oct 29, 2020):

Just for another data point, I am also suddenly experiencing this issue since a few days ago. I do have permission to the WindowsApps folder, but wt previously worked fine despite that until a few days ago. Same as above, the issue only occurs when trying to run wt from the start menu or file explorer.

It appears as if I have three copies of wt.exe as well, in the same locations as above:
C:\Users\cjpel\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe
C:\Users\cjpel\AppData\Local\Microsoft\WindowsApps\wt.exe
C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe

It seems as if an update to either Windows or Windows Terminal has done something to suddenly cause this issue, as I and others have chimed in saying that it just started happening in the past few days without changing anything.

Edit: The fix above that seems to be working for others does not fix the issue for me unfortunately.

@cjpellicci commented on GitHub (Oct 29, 2020): Just for another data point, I am also suddenly experiencing this issue since a few days ago. I do have permission to the WindowsApps folder, but wt previously worked fine despite that until a few days ago. Same as above, the issue only occurs when trying to run wt from the start menu or file explorer. It appears as if I have three copies of wt.exe as well, in the same locations as above: `C:\Users\cjpel\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe` `C:\Users\cjpel\AppData\Local\Microsoft\WindowsApps\wt.exe` `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\wt.exe` It seems as if an update to either Windows or Windows Terminal has done something to suddenly cause this issue, as I and others have chimed in saying that it just started happening in the past few days without changing anything. Edit: The fix above that seems to be working for others does not fix the issue for me unfortunately.

claunia commented

@cjpellicci commented on GitHub (Oct 29, 2020):

I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell:

icacls "C:\Program Files\WindowsApps" /reset /t /c /q

@cjpellicci commented on GitHub (Oct 29, 2020): I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell: `icacls "C:\Program Files\WindowsApps" /reset /t /c /q`

claunia commented

@sokolinivan commented on GitHub (Oct 29, 2020):

Мне удалось решить проблему, сбросив разрешения для папки WindowsApps. wt работает должным образом после выполнения следующей команды в PowerShell с повышенными привилегиями:

icacls "C:\Program Files\WindowsApps" /reset /t /c /q

Thank you so much. This really solves the problem.

@sokolinivan commented on GitHub (Oct 29, 2020): > Мне удалось решить проблему, сбросив разрешения для папки WindowsApps. wt работает должным образом после выполнения следующей команды в PowerShell с повышенными привилегиями: > > `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` Thank you so much. This really solves the problem.

claunia commented

@zachHixson commented on GitHub (Oct 29, 2020):

I tried

I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell:

icacls "C:\Program Files\WindowsApps" /reset /t /c /q

And said "Access Denied," on each line that appeared. I tried it with System, and myself as the folder owner and same result

@zachHixson commented on GitHub (Oct 29, 2020): I tried > > > I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell: > > `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` And said "Access Denied," on each line that appeared. I tried it with System, and myself as the folder owner and same result

claunia commented

@zachHixson commented on GitHub (Oct 31, 2020):

Ok, now terminal just refuses to open from the start menu. I can't use "wt" to open it from explorer, running "wt" from powershell (which worked until yesterday), or Start > Terminal to open it, or Start > typing "Terminal," and then opening it that way.

After a reinstall, launching from start, search, and "wt" from powershell worked correctly, but file explorer still gave the 0x0...22 error

@zachHixson commented on GitHub (Oct 31, 2020): Ok, now terminal just refuses to open from the start menu. I can't use "wt" to open it from explorer, running "wt" from powershell (which worked until yesterday), or Start > Terminal to open it, or Start > typing "Terminal," and then opening it that way. After a reinstall, launching from start, search, and "wt" from powershell worked correctly, but file explorer still gave the 0x0...22 error

claunia commented

@butgit commented on GitHub (Nov 3, 2020):

I found this problem yesterday when I tried running it by typing wt and Enter from Start menu. Strange enough, typing windows terminal and Enter in Start menu opens the terminal normally.
I reinstalled it from MS Store but still get the same error message. I tried icacls "C:\Program Files\WindowsApps" /reset /t /c /q in the elevated powershell window to no avail.

@butgit commented on GitHub (Nov 3, 2020): I found this problem yesterday when I tried running it by typing **wt** and <kbd>Enter</kbd> from Start menu. Strange enough, typing **windows terminal** and <kbd>Enter</kbd> in Start menu opens the terminal normally. I reinstalled it from MS Store but still get the same error message. I tried `icacls "C:\Program Files\WindowsApps" /reset /t /c /q ` in the elevated powershell window to no avail.

claunia commented

@0x15f2d commented on GitHub (Nov 10, 2020):

I thought this issue was my SSD breaking up files since it has signs of making files incorrectly usable (a jar file broken).

So I went through a DISM, SFC, DSKCHK but they aren't working at all.

Plus upgrading to 20H2 doesn't seem to fix it since upgrading windows will reinstall drivers, Windows apps.

Edit:

My problem is that I'm afraid I messed up the permissions of WindowsApps and Microsoft.WindowsTerminal_versionNumber_arch__probablyGUIDOrSomething without notices and I don't want to mess up the permissions of WindowsApps anymore so I got a fix for this:

Use powershell under Administrator and run Remove-AppxPackage [Whatever is the full name of the Windows Terminal package name is for example: Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe].

This will ACTUALLY DELETE the program's folder and not keeping the app files when uninstalling them in Settings app.

Go back to Microsoft Store and reinstall it and you're done.

@0x15f2d commented on GitHub (Nov 10, 2020): I thought this issue was my SSD breaking up files since it has signs of making files incorrectly usable (a jar file broken). So I went through a `DISM`, `SFC`, `DSKCHK` but they aren't working at all. Plus upgrading to 20H2 doesn't seem to fix it since upgrading windows will reinstall drivers, Windows apps. Edit: My problem is that I'm afraid I messed up the permissions of `WindowsApps` and `Microsoft.WindowsTerminal_versionNumber_arch__probablyGUIDOrSomething` without notices and I don't want to mess up the permissions of WindowsApps anymore so I got a fix for this: Use powershell under Administrator and run `Remove-AppxPackage [Whatever is the full name of the Windows Terminal package name is for example: Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe]`. This will **ACTUALLY DELETE** the program's folder and not keeping the app files when uninstalling them in Settings app. Go back to Microsoft Store and reinstall it and you're done.

claunia commented

@KyleCrowley commented on GitHub (Nov 10, 2020):

I'm running into this same error seemingly out of nowhere (I suspect a Windows update as others have alluded to).

Steps I've taken to try and resolve:

Ran icacls "C:\Program Files\WindowsApps" /reset /t /c /q with Windows Terminal installed [FAIL]
Uninstalled Windows Terminal (using @0x15f2d's suggestion above) and re-installed, resetting permission before and after (using the command in step 1) [FAIL]

Neither solution worked.

I should point out that I'm installing Windows Terminal via chocolatey, not through the Windows Store (my organization prevents me from doing so), so this issue doesn't seem to be isolated to just the Windows Store installation method.

@KyleCrowley commented on GitHub (Nov 10, 2020): I'm running into this same error seemingly out of nowhere (I suspect a Windows update as others have alluded to). Steps I've taken to try and resolve: 1) Ran `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` with Windows Terminal installed **[FAIL]** 2) Uninstalled Windows Terminal (using @0x15f2d's suggestion above) and re-installed, resetting permission before and after (using the command in step 1) **[FAIL]** Neither solution worked. I should point out that I'm installing Windows Terminal via chocolatey, not through the Windows Store (my organization prevents me from doing so), so this issue doesn't seem to be isolated to just the Windows Store installation method.

claunia commented

https://github.com/microsoft/terminal/issues/7188

@0x15f2d commented on GitHub (Nov 12, 2020):

@KyleCrowley doing icacls "C:\Program Files\WindowsApps" /reset /t /c /q does not actually restore 100% WindowsApp's folder original permissions and owners. It just restores to default owners and permissions. Usually You (Part of the Administrators) not NT Authority\TrustedInstaller or in this case Windows can't display it because Administrators can't even have permissions to see it. So you had to TakeOwn it.

You need an actual backup of owners and permissions from WindowsApps folder also made by icacls so icacls itself can use the backed up permissions and ownership file to restore the folder's owners and permissions correctly.

Otherwise if you are like me who messed that up. Upgrading existing Windows will fix this since it's like a reinstallation (better than doing dism and sfc thing. I tried and it partially works for the WindowsApps folder alone. The rest of the folder's content that has permissions altered must be reinstalled (deleted).

Or reinstall Windows.

And about wt.exe. Check the Settings app for enabling Alias and Command Prompt where wt.exe.

If it returns to WindowsApps folder. Use Powershell to uninstall it. (Do not try to delete the one from AppData because it just a some sort of a symlink. The one you need to delete was from Program Files.)

If it said it doesn't reference to anything but running it from Run still saying 0xc0000022 then that means the Windows Terminal's app is still has folders and files permissions and ownership altered. Use Powershell or anything to get rid of that folder and go to MS Store to reinstall it correctly after you fixed the WindowsApps folder.

One more thing is that when I download the msix file (Currently version 1.3) when installing the file the program works fine. But when I reboot the machine (It was deep freezed) and reinstall the same file. It doesn't work outright anymore it just give me a cross and it said it can't find the file because the path to the execution binary file was shortened for some reason????

But yeah if you downloaded it from github it was installing fine. But when you got it from other places it just can't be launched.

Other appx files and msix files that I got offline seems installing and working fine. Like the Language Pack.

@0x15f2d commented on GitHub (Nov 12, 2020): @KyleCrowley doing `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` **does not** actually restore 100% WindowsApp's folder original permissions and owners. It just restores to **default owners and permissions**. Usually You (Part of the Administrators) not **NT Authority\TrustedInstaller** or in this case Windows can't display it because **Administrators** can't even have permissions to see it. So you had to `TakeOwn` it. You need an **actual backup** of owners and permissions from WindowsApps folder also made by `icacls` so `icacls` itself can use the **backed up permissions and ownership file** to restore the folder's owners and permissions correctly. Otherwise if you are like me who messed that up. **Upgrading** existing Windows **will** fix this since it's like a reinstallation (better than doing `dism` and `sfc` thing. I tried and it **partially** works for the WindowsApps folder alone. The rest of the folder's content that has permissions altered must be reinstalled (**deleted**). Or reinstall Windows. And about wt.exe. Check the Settings app for enabling Alias and Command Prompt `where wt.exe`. If it returns to WindowsApps folder. Use Powershell to uninstall it. (**Do not try to delete the one from AppData because it just a some sort of a symlink. The one you need to delete was from Program Files.**) If it said it doesn't reference to anything but running it from Run still saying 0xc0000022 then that means the Windows Terminal's app is still has folders and files permissions and ownership altered. Use Powershell or anything to get rid of that folder and go to MS Store to reinstall it correctly after you fixed the WindowsApps folder. One more thing is that when I download the msix file (Currently version 1.3) when installing the file the program works fine. But when I reboot the machine (It was deep freezed) and reinstall the same file. It doesn't work outright anymore it just give me a cross and it said it can't find the file because the path to the execution binary file was shortened for some reason???? https://github.com/microsoft/terminal/issues/7188 But yeah if you downloaded it from github it was installing fine. But when you got it from other places it just can't be launched. Other appx files and msix files that I got offline seems installing and working fine. Like the Language Pack.

claunia commented

@KyleCrowley commented on GitHub (Nov 13, 2020):

@0x15f2d Thanks for the note about restoring the original permissions. You led me down a path that eventually allowed me to get Windows Terminal working again.

The method I followed was the one laid out here. At some point, I must've taken control of the WindowsApps folder via my local admin account (separate account my organization provisions). Once I followed the procedure, things started working again (barring some irregularities with the Chocolately install, but that is out of scope as far as this issue is concerned).

@KyleCrowley commented on GitHub (Nov 13, 2020): @0x15f2d Thanks for the note about restoring the original permissions. You led me down a path that eventually allowed me to get Windows Terminal working again. The method I followed was the one laid out [here](https://superuser.com/a/1507948). At some point, I must've taken control of the WindowsApps folder via my local admin account (separate account my organization provisions). Once I followed the procedure, things started working again (barring some irregularities with the Chocolately install, but that is out of scope as far as this issue is concerned).

claunia commented

@zachHixson commented on GitHub (Nov 16, 2020):

@KyleCrowley Wow for some reason this worked. When I first started getting the bug, somebody else here suggested modifying the some files in the folder, but I didn't have access. I took ownership to gain access to WindowsApps and edit the files, but it didn't fix my problem. Restoring ownership to TrustedInstaller fixed my problems. Weird.

@zachHixson commented on GitHub (Nov 16, 2020): @KyleCrowley Wow for some reason this worked. When I first started getting the bug, somebody else here suggested modifying the some files in the folder, but I didn't have access. I took ownership to gain access to WindowsApps and edit the files, but it didn't fix my problem. Restoring ownership to TrustedInstaller fixed my problems. Weird.

claunia commented

@0x15f2d commented on GitHub (Nov 16, 2020):

The method I followed was the one laid out here.

@KyleCrowley oh yeah that makes sense to me now. because reinstalling windows is like using SYSTEM to do stuff.
psexec.exe -s -i cmd

@0x15f2d commented on GitHub (Nov 16, 2020): > The method I followed was the one laid out [here](https://superuser.com/a/1507948). @KyleCrowley oh yeah that makes sense to me now. because reinstalling windows is like using SYSTEM to do stuff. `psexec.exe -s -i cmd`

claunia commented

@0x15f2d commented on GitHub (Nov 16, 2020):

@zachThePerson there will be more issues to come if you still can see if you still have permissions to see (read permissions) who owns WindowsApps folder (not its contents) because i have multiple built in apps reinstalled from ms store (not actually deleting the folder itself because altered ownerships and I don't know this method yet) and they are all starting up crashed like Weather app or Xbox Companion app.

Repairing, clean app data won't help from Settings app.

But it should be like you have zero permissions and ownerships towards WindowsApps folder.

Only special roles like NT Authority\SYSTEM, NT Authority\TrustedInstaller or CREATOR OWNER can have full access.

@0x15f2d commented on GitHub (Nov 16, 2020): @zachThePerson there will be more issues to come if you still can see if you still have permissions to see _(read permissions)_ who owns **WindowsApps** folder (not its contents) because i have multiple built in apps reinstalled from ms store (not actually deleting the folder itself because altered ownerships and I don't know this method yet) and they are all starting up crashed like Weather app or Xbox Companion app. Repairing, clean app data won't help from Settings app. But it should be like you have zero permissions and ownerships towards **WindowsApps** folder. Only special roles like **NT Authority\SYSTEM, NT Authority\TrustedInstaller or CREATOR OWNER** can have full access.

claunia commented

@zachHixson commented on GitHub (Mar 4, 2021):

It happened again. Same error, but nothing I did last time seems to fix it. As far as I can tell all the permission settings are the same

@zachHixson commented on GitHub (Mar 4, 2021): It happened again. Same error, but nothing I did last time seems to fix it. As far as I can tell all the permission settings are the same

claunia commented

@JamesWZM commented on GitHub (Mar 4, 2021):

icacls does not work for me at all!

The WindowsTerminal.exe is still available, but wt.exe just won't work and returns to me a 0xc0000022 error.
I have no idea what has happened to it. It's still working well yesterday and I have not restarted my computer.

Also, OpenConsole.exe returns to me the same error.

It is amazing that, in shell (any shell including cmd, pwsh...), command "wt" worked well. But it just won't work with double click or Win+R run

@JamesWZM commented on GitHub (Mar 4, 2021): `icacls` does not work for me at all! The WindowsTerminal.exe is still available, but wt.exe just won't work and returns to me a 0xc0000022 error. I have no idea what has happened to it. It's still working well yesterday and I have not restarted my computer. Also, OpenConsole.exe returns to me the same error. It is amazing that, in shell (any shell including cmd, pwsh...), command "wt" worked well. But it just won't work with double click or Win+R run

claunia commented

@wuqiling97 commented on GitHub (Mar 4, 2021):

icacls not working, but I found a workaround:

Uninstall Windows Terminal.
Goto Settings → System → Storage → Change where new content is saved and change "New apps will save to" from C: to D:.
Install Windows Terminal.

Then I can run wt from Run window.

@wuqiling97 commented on GitHub (Mar 4, 2021): `icacls` not working, but I found a workaround: - Uninstall Windows Terminal. - Goto Settings → System → Storage → Change where new content is saved and change "New apps will save to" from C: to D:. - Install Windows Terminal. Then I can run `wt` from `Run` window.

claunia commented

@zachHixson commented on GitHub (Mar 4, 2021):

Great workaround! Wouldn't be surprised if a future update breaks this folder too though

@zachHixson commented on GitHub (Mar 4, 2021): Great workaround! Wouldn't be surprised if a future update breaks this folder too though

claunia commented

@Gameghostify commented on GitHub (Mar 18, 2021):

Happened to me again as well. Same thing as last time, taking ownership of the folder the app is in fixed the issue

@Gameghostify commented on GitHub (Mar 18, 2021): Happened to me again as well. Same thing as last time, taking ownership of the folder the app is in fixed the issue

claunia commented

@barnemesh commented on GitHub (Mar 30, 2021):

A solution I found-
changing the values in the following registries:
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe
from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

@barnemesh commented on GitHub (Mar 30, 2021): A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

claunia commented

@zachHixson commented on GitHub (Apr 9, 2021):

Changing the registry path worked like a charm. Since it points to an AppData folder, I think this should be the default as we wouldn't ever have to worry about security bugs like this

@zachHixson commented on GitHub (Apr 9, 2021): Changing the registry path worked like a charm. Since it points to an AppData folder, I think this should be the default as we wouldn't ever have to worry about security bugs like this

claunia commented

@DHowett commented on GitHub (Apr 9, 2021):

security bugs like this

App packages are installed and registered per-user; this is the only effective way to give users specific control over which app package is invoked :)

@DHowett commented on GitHub (Apr 9, 2021): > security bugs like this App packages are installed and registered _per-user_; this is the only effective way to give users specific control over which app package is invoked :)

claunia commented

2026-01-31 02:05:53 +00:00

@zachHixson commented on GitHub (Apr 9, 2021):

Ok. Also it broke again so I retract my previous statement. Don't know why it only worked once or twice, registry entries are still the new value so idk what is going on anymore

@zachHixson commented on GitHub (Apr 9, 2021): Ok. Also it broke again so I retract my previous statement. Don't know why it only worked once or twice, registry entries are still the new value so idk what is going on anymore

claunia commented

@mihirsavadi commented on GitHub (May 29, 2021):

A solution I found-
changing the values in the following registries:
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe
from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

This worked perfectly!!!!!!!!! Tried literally everything else in this thread only more problems, but this worked

@mihirsavadi commented on GitHub (May 29, 2021): > A solution I found- > changing the values in the following registries: > Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe > from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\ This worked perfectly!!!!!!!!! Tried literally everything else in this thread only more problems, but this worked

claunia commented

2026-01-31 02:05:53 +00:00

@pashza commented on GitHub (Jan 30, 2022):

I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell:

icacls "C:\Program Files\WindowsApps" /reset /t /c /q

This worked perfectly!

@pashza commented on GitHub (Jan 30, 2022): > I was able to fix the issue by resetting permissions to the WindowsApps folder. wt works as expected after running the command below in an elevated PowerShell: > > `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` This worked perfectly!

claunia commented

2026-01-31 02:05:53 +00:00

@PennRobotics commented on GitHub (Feb 8, 2022):

For anyone else who messed up their WindowsApps permissions running the command above, running the script at https://github.com/AgentRev/WindowsAppsUnfukker made everything (mostly) well again. Except now Windows Store thinks Terminal Preview is installed while it cannot be found via Start Menu or Add/Remove Programs. (It is, in fact, installed.)

@PennRobotics commented on GitHub (Feb 8, 2022): For anyone else who messed up their WindowsApps permissions running the command above, running the script at https://github.com/AgentRev/WindowsAppsUnfukker made everything (mostly) well again. Except now Windows Store thinks Terminal Preview is installed while it cannot be found via Start Menu or Add/Remove Programs. (It is, in fact, installed.)

claunia commented

2026-01-31 02:05:54 +00:00

@liudonghua123 commented on GitHub (Mar 12, 2022):

A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

This method works for me. I found that "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe" is a uwp, and can not directly run. You should run %LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe (It's a zero sized file, maybe called app execution alias) instead.

But I find other items in Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths are using path like C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemforLinux_0.51.3.0_x64__8wekyb3d8bbwe.

@liudonghua123 commented on GitHub (Mar 12, 2022): > A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\ This method works for me. I found that `"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe"` is a uwp, and can not directly run. You should run `%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe` (It's a zero sized file, maybe called app execution alias) instead. <img width="823" alt="image" src="https://user-images.githubusercontent.com/2276718/158008607-e580c05b-cefe-4521-af40-74cc760b6620.png"> <img width="773" alt="image" src="https://user-images.githubusercontent.com/2276718/158008627-49ccc91e-28c7-4f0f-8721-b2f279e511eb.png"> But I find other items in `Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths` are using path like `C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemforLinux_0.51.3.0_x64__8wekyb3d8bbwe`.

claunia commented

2026-01-31 02:05:54 +00:00

@plutonium-239 commented on GitHub (Mar 23, 2022):

@liudonghua123 Thank you so much!
Finally works after 6 months lol

@plutonium-239 commented on GitHub (Mar 23, 2022): @liudonghua123 Thank you so much! Finally works after 6 months lol

claunia commented

2026-01-31 02:05:54 +00:00

@Anonymous87549236 commented on GitHub (Mar 26, 2022):

https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps worked for me.

@Anonymous87549236 commented on GitHub (Mar 26, 2022): https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps worked for me.

claunia commented

@LeoZeolite commented on GitHub (Sep 23, 2022):

A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

This method works for me.

@LeoZeolite commented on GitHub (Sep 23, 2022): > A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\ This method works for me.

claunia commented

@petryaevve commented on GitHub (Nov 19, 2022):

A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\

This method works for me. I found that "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe" is a uwp, and can not directly run. You should run %LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe (It's a zero sized file, maybe called app execution alias) instead.

But I find other items in Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths are using path like C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemforLinux_0.51.3.0_x64__8wekyb3d8bbwe.

Thanks!!! It works good

@petryaevve commented on GitHub (Nov 19, 2022): > > A solution I found- changing the values in the following registries: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe from the C:\Program Files\WindowsApps\ path, to the path in C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\ > > This method works for me. I found that `"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe"` is a uwp, and can not directly run. You should run `%LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe` (It's a zero sized file, maybe called app execution alias) instead. > > <img alt="image" width="823" src="https://user-images.githubusercontent.com/2276718/158008607-e580c05b-cefe-4521-af40-74cc760b6620.png"> > > <img alt="image" width="773" src="https://user-images.githubusercontent.com/2276718/158008627-49ccc91e-28c7-4f0f-8721-b2f279e511eb.png"> > > But I find other items in `Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths` are using path like `C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemforLinux_0.51.3.0_x64__8wekyb3d8bbwe`. Thanks!!! It works good

claunia commented

@ghost commented on GitHub (Mar 5, 2023):

Why won't Microsoft fix this registry issue on Windows Terminal installation?

@ghost commented on GitHub (Mar 5, 2023): Why won't Microsoft fix this registry issue on Windows Terminal installation?

claunia commented