Windows Terminal WT.exe not working anymore after latest update 22509.1000.211119-1136.RS_PRERELEASE #16059

@Litttlefish commented on GitHub (Dec 8, 2021):

For me, this issue is weirder. (system version is 22000.348)
Terminal version: 1.11.2921.0

1: Win+X -> [Windows Terminal] or Windows Terminal {Admin}
No response/pop up a UAC window called wt.exe and nothing happened too if proceeded.
But if you right-click the Win icon and open the terminal there, it will work normally. Also, the UAC window will say WindowsTerminal.exe rather than wt.exe.
2: Win+S/Search -> wt or wt.exe
No response at all.
3: Win+R -> wt or wt.exe
Same as 2.
4: Open wt.exe directly in explorer
Same as 2 and 3.
5: Type wt in cmd or PowerShell
Can open terminal window normally.
Also the "Open in Windows Terminal" option in right-click menu is missing too.

@Litttlefish commented on GitHub (Dec 8, 2021): For me, this issue is weirder. (system version is 22000.348) Terminal version: 1.11.2921.0 1: Win+X -> [Windows Terminal] or Windows Terminal {Admin} No response/pop up a UAC window called wt.exe and nothing happened too if proceeded. But if you right-click the Win icon and open the terminal there, it will work normally. Also, the UAC window will say WindowsTerminal.exe rather than wt.exe. 2: Win+S/Search -> wt or wt.exe No response at all. 3: Win+R -> wt or wt.exe Same as 2. 4: Open wt.exe directly in explorer Same as 2 and 3. 5: Type wt in cmd or PowerShell Can open terminal window normally. Also the "Open in Windows Terminal" option in right-click menu is missing too.

claunia commented

@pupa57 commented on GitHub (Dec 8, 2021):

Your responses are much appreciated.
Yes! I did also suspect its to do with permissions. I suspect that it could also be related to Win32 and it's path issues as I have to suddenly add Win32 programs that worked before to the environment path to get it to work? There is also WSL Ubuntu links that won't work from start but they work ok if opened directly from store.

Is reinstallation my only best choice!

Thank you!

@pupa57 commented on GitHub (Dec 8, 2021): Your responses are much appreciated. Yes! I did also suspect its to do with permissions. I suspect that it could also be related to Win32 and it's path issues as I have to suddenly add Win32 programs that worked before to the environment path to get it to work? There is also WSL Ubuntu links that won't work from start but they work ok if opened directly from store. Is reinstallation my only best choice! Thank you!

claunia commented

@Litttlefish commented on GitHub (Dec 8, 2021):

I happened to find some solutions to fix this problem.
2 solutions, you can use either one or all of them.
So basically,
1:
Use PSTools and run this in Powershell or cmd:

.\psexec -i -s -d cmd.exe

Then

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

And just wait for it to finish.

2:
(From #7081)
Change 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 %LocalAppData%\Microsoft\WindowsApps\

Right-click menu is another issue(#10119).

@Litttlefish commented on GitHub (Dec 8, 2021): I happened to find some solutions to fix this problem. 2 solutions, you can use either one or all of them. So basically, 1: Use PSTools and run this in Powershell or cmd: `.\psexec -i -s -d cmd.exe` Then `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` And just wait for it to finish. 2: (From #7081) Change 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 `%LocalAppData%\Microsoft\WindowsApps\` Right-click menu is another issue(#10119).

claunia commented

@zadjii-msft commented on GitHub (Dec 8, 2021):

I also just came across an older thread discussing a similar effect: #7188

You might be able to quick fix this by just toggling the "App Execution Alias" for the Terminal in the Settings App:

(if that didn't help, then maybe reboot after toggling it)

Any chance that resolved it?

@zadjii-msft commented on GitHub (Dec 8, 2021): I also just came across an older thread discussing a similar effect: #7188 You might be able to quick fix this by just toggling the "App Execution Alias" for the Terminal in the Settings App: ![image](https://user-images.githubusercontent.com/18356694/145302086-65fb7e1c-65d2-4785-95ed-e2c0d1ed6fdc.png) (if that didn't help, then maybe reboot after toggling it) Any chance that resolved it?

claunia commented

@ghost commented on GitHub (Dec 13, 2021):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Dec 13, 2021): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.

claunia commented

@eryksun commented on GitHub (Dec 16, 2021):

AFAICT, updating the appexec alias doesn't update the "wt.exe" entry in "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths". The "App Paths" entry is meant to allow running "wt.exe" via ShellExecute[Ex]W(), regardless of PATH. For some reason it references the executable in "%ProgramFiles%\WindowsApps" instead of the appexec alias. Normally that works fine. CreateProcessW() has code to handle running the executable directly if the user has an appexec alias with the same name that references the executable. If the appexec alias is disabled or refers to a different app, however, CreateProcessW() won't do anything to handle the access-denied error.

If the "App Paths" entry is wrong, you can either fix it or remove it. If you opt to fix it, you can change it to run the appexec alias instead of the executable. Butchering the ACLs on "%ProgramFiles%\WindowsApps" is an over the top response to a simple problem.

CreateProcessW() is designed to handle the cases where NtCreateUserProcess() fails with either STATUS_ACCESS_DENIED (0xC0000022, from running the executable directly) or STATUS_IO_REPARSE_TAG_NOT_HANDLED (0xC0000279, from running the appexec link). In both cases, it reads the appexec reparse point to get the required app information, including the package name, app user model ID, and the fully-qualified path of the executable. It uses the app information to create a custom access token that allows running the app.

In particular, the access token contains the app's "WIN://SYSAPPID" attribute. A conditional ACE on the executable file grants execute access in this case. For example, (XA;ID;0x1200a9;;;BU;(WIN://SYSAPPID Contains "MICROSOFT.WINDOWSTERMINALPREVIEW_8WEKYB3D8BBWE")) grants read and execute access (0x1200A9) to a member of "BUILTIN\Users" (BU) if the access token has Terminal's package name in its "WIN://SYSAPPID" attribute. To view these conditional ACEs on the command line, use cacls.exe with the /s (SDDL) option. Or use PowerShell's get-acl and show the Sddl property of the result. icacls.exe does not support displaying conditional ACEs.

@eryksun commented on GitHub (Dec 16, 2021): AFAICT, updating the appexec alias doesn't update the "wt.exe" entry in "HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths". The "App Paths" entry is meant to allow running "wt.exe" via `ShellExecute[Ex]W()`, regardless of `PATH`. For some reason it references the executable in "%ProgramFiles%\\WindowsApps" instead of the appexec alias. Normally that works fine. `CreateProcessW()` has code to handle running the executable directly if the user has an appexec alias with the same name that references the executable. If the appexec alias is disabled or refers to a different app, however, `CreateProcessW()` won't do anything to handle the access-denied error. If the "App Paths" entry is wrong, you can either fix it or remove it. If you opt to fix it, you can change it to run the appexec alias instead of the executable. Butchering the ACLs on "%ProgramFiles%\\WindowsApps" is an over the top response to a simple problem. `CreateProcessW()` is designed to handle the cases where `NtCreateUserProcess()` fails with either `STATUS_ACCESS_DENIED` (0xC0000022, from running the executable directly) or `STATUS_IO_REPARSE_TAG_NOT_HANDLED` (0xC0000279, from running the appexec link). In both cases, it reads the appexec reparse point to get the required app information, including the package name, app user model ID, and the fully-qualified path of the executable. It uses the app information to create a custom access token that allows running the app. In particular, the access token contains the app's "WIN://SYSAPPID" attribute. A conditional ACE on the executable file grants execute access in this case. For example, `(XA;ID;0x1200a9;;;BU;(WIN://SYSAPPID Contains "MICROSOFT.WINDOWSTERMINALPREVIEW_8WEKYB3D8BBWE"))` grants read and execute access (0x1200A9) to a member of "BUILTIN\\Users" (BU) if the access token has Terminal's package name in its "WIN://SYSAPPID" attribute. To view these conditional ACEs on the command line, use cacls.exe with the `/s` (SDDL) option. Or use PowerShell's `get-acl` and show the `Sddl` property of the result. icacls.exe does not support displaying conditional ACEs.

claunia commented

@pupa57 commented on GitHub (Dec 16, 2021):

Hi everyone.
Sorry about delayed response. I was busy setting up another less troublesome windows backup I had with no perceived problem, now updated to the latest Insiders Dev Win11 build . I only realised yesterday I had to respond in this thread but then this issue was already locked. I tried the no 1 option of Littlefish which worked only until a reboot, then I got another but different error message and ended back to square one. I then today updated the Terminal app to version 7.2 that was offered by windows update which allowed the terminal to open but got another error thus issue, but at least at the same time it displayed there was a newer update to Windows terminal Version 7.2.1 available from https://aka.ms/PowerShell-Release?tag=v7.2.1 which I downloaded and installed and can confirm that Windows terminal works now from everywhere, as it did before.
Thank you very much for your inputs and help. I will again report back if anything else is amiss!

If there is anyting else you want me to do to test or feed back info please advise and I will attend to it pronto.

My PC Windows version is currently in the process of updating to Windows 11 Insider Preview 2253.1000 (rs_prerelease). I hope all ends well and nothing breaks again.

Edit: Fixed some spelling and added text to add hopefully some better clarity. English is not my native language.

@pupa57 commented on GitHub (Dec 16, 2021): Hi everyone. Sorry about delayed response. I was busy setting up another less troublesome windows backup I had with no perceived problem, now updated to the latest Insiders Dev Win11 build . I only realised yesterday I had to respond in this thread but then this issue was already locked. I tried the no 1 option of Littlefish which worked only until a reboot, then I got another but different error message and ended back to square one. I then today updated the Terminal app to version 7.2 that was offered by windows update which allowed the terminal to open but got another error thus issue, but at least at the same time it displayed there was a newer update to Windows terminal Version 7.2.1 available from https://aka.ms/PowerShell-Release?tag=v7.2.1 which I downloaded and installed and can confirm that Windows terminal works now from everywhere, as it did before. Thank you very much for your inputs and help. I will again report back if anything else is amiss! If there is anyting else you want me to do to test or feed back info please advise and I will attend to it pronto. My PC Windows version is currently in the process of updating to Windows 11 Insider Preview 2253.1000 (rs_prerelease). I hope all ends well and nothing breaks again. Edit: Fixed some spelling and added text to add hopefully some better clarity. English is not my native language.

claunia commented

@Litttlefish commented on GitHub (Dec 17, 2021):

Hi,
So after my comment I met many more weird problems about uwp apps, such as Snipping Tool not working, can't open photo or txt files, game service not working anymore, etc., and reinstalling them didn't help.
I think my problem came after I took control of the /WindowsApps folder and that messed up its permission settings.
And I decided to reinstall Windows and these problems are all gone.
I think that resets the folder permission to default, so it may have to do with the permissions of /WindowsApps folder.
I think maybe you changed the permissions of that folder before and after that wt.exe broke.

@Litttlefish commented on GitHub (Dec 17, 2021): Hi, So after my comment I met many more weird problems about uwp apps, such as Snipping Tool not working, can't open photo or txt files, game service not working anymore, etc., and reinstalling them didn't help. I think my problem came after I took control of the /WindowsApps folder and that messed up its permission settings. And I decided to reinstall Windows and these problems are all gone. I think that resets the folder permission to default, so it may have to do with the permissions of /WindowsApps folder. I think maybe you changed the permissions of that folder before and after that wt.exe broke.

claunia commented

@pupa57 commented on GitHub (Dec 17, 2021):

Yes. I long ago took ownership of the /WindowsApps folder for some reason I cannot now remember and never experienced any problems until a recent Insiders update then everything slowly but surely broke mostly after windows store installs or insiders updates. Now everything seems to mostly work again after your option 1, although wt.exe broke again after reboot with different errors, which the latest powershell update 7.2.1 fixed. Now testing various other apps to see if their shortcuts also works.

@pupa57 commented on GitHub (Dec 17, 2021): Yes. I long ago took ownership of the /WindowsApps folder for some reason I cannot now remember and never experienced any problems until a recent Insiders update then everything slowly but surely broke mostly after windows store installs or insiders updates. Now everything seems to mostly work again after your option 1, although wt.exe broke again after reboot with different errors, which the latest powershell update 7.2.1 fixed. Now testing various other apps to see if their shortcuts also works.

claunia commented

@commodore-84 commented on GitHub (Feb 16, 2022):

Have you tried: -

get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

@commodore-84 commented on GitHub (Feb 16, 2022): Have you tried: - get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

claunia commented

@FarawayMagnet commented on GitHub (Feb 18, 2022):

Have you tried: -

get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

this worked for me. i was getting "Windows cannot find wt.exe" when doing "right-click Start menu > left-click Windows Terminal". i'd only just performed a fresh install of windows 10 home, followed by an upgrade to windows 11 the next day.

i don't have any weird permissions and wasn't messing with any system settings or file permissions, so it seems like a bug.

@FarawayMagnet commented on GitHub (Feb 18, 2022): > Have you tried: - > > get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} this worked for me. i was getting "Windows cannot find wt.exe" when doing "right-click Start menu > left-click Windows Terminal". i'd only just performed a fresh install of windows 10 home, followed by an upgrade to windows 11 the next day. i don't have any weird permissions and wasn't messing with any system settings or file permissions, so it seems like a bug.

claunia commented

@ChayimEliazer commented on GitHub (Mar 13, 2022):

@LitttleFish

I happened to find some solutions to fix this problem. 2 solutions, you can use either one or all of them. So basically, 1: Use PSTools and run this in Powershell or cmd:

.\psexec -i -s -d cmd.exe

Then

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

And just wait for it to finish.

2: (From #7081) Change 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 %LocalAppData%\Microsoft\WindowsApps\

Right-click menu is another issue(#10119).

2nd solution solved it.
This problem came after latest Windows Update.

@ChayimEliazer commented on GitHub (Mar 13, 2022): @LitttleFish > I happened to find some solutions to fix this problem. 2 solutions, you can use either one or all of them. So basically, 1: Use PSTools and run this in Powershell or cmd: > > `.\psexec -i -s -d cmd.exe` > > Then > > `icacls "C:\Program Files\WindowsApps" /reset /t /c /q` > > And just wait for it to finish. > > 2: (From #7081) Change 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 `%LocalAppData%\Microsoft\WindowsApps\` > > Right-click menu is another issue(#10119). 2nd solution solved it. This problem came after latest Windows Update.

claunia commented

@ChayimEliazer commented on GitHub (Mar 13, 2022):

@el-chazmo

Have you tried: -

get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Solved the problem. Thanks. The problem comes after the lately update in Windows 11.

@ChayimEliazer commented on GitHub (Mar 13, 2022): @el-chazmo > Have you tried: - > > get-appxpackage Microsoft.WindowsTerminal -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} Solved the problem. Thanks. The problem comes after the lately update in Windows 11.

claunia commented