Win + R -> wt won't start Terminal

[Ldhlwh]

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19044.1826

Other Software

No response

Steps to reproduce

1. Win + R -> wt, no response and Terminal doesn't start
2. Win + R -> %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt.exe, OK
3. Cmd -> wt, OK
4. Start menu -> Terminal, OK

Cmd -> where wt returns C:\Users\username\AppData\Local\Microsoft\WindowsApps\wt.exe My PATH includes %USERPROFILE%\AppData\Local\Microsoft\WindowsApps App execution alias for Terminal is ON

This issue has been happening since Terminal version 1.13.x. Updating to 1.14.1962.0 fixed it for the first few times but later broke again

Expected Behavior

No response

Actual Behavior

No response and Terminal doesn't start

[zadjii-msft]

Can you do a Win + R -> cmd /k where wt & set for me/? I think we've seen intermittent issues where the shell (explorer.exe) for whatever reason, decides to have a different path than the real %PATH%

[Ldhlwh]

Thanks for the reply

C:\Users\username\AppData\Local\Microsoft\WindowsApps\wt.exe
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\username\AppData\Roaming
asl.log=Destination=file
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=computername
ComSpec=C:\WINDOWS\system32\cmd.exe
DriverData=C:\Windows\System32\Drivers\DriverData
FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
FPS_BROWSER_USER_PROFILE_STRING=Default
HOMEDRIVE=C:
HOMEPATH=\Users\username
LOCALAPPDATA=C:\Users\username\AppData\Local
LOGONSERVER=\\computername
NUMBER_OF_PROCESSORS=8
OneDrive=C:\Users\username\OneDrive
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;D:\Calibre2\;C:\Users\username\AppData\Local\Microsoft\WindowsApps;D:\Microsoft VS Code\bin;D:\TIM\Bin;D:\WeChat;D:\IPE\bin;D:\Thunder\Program;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=8c01
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Users\username\AppData\Local\Temp
TMP=C:\Users\username\AppData\Local\Temp
USERDOMAIN=computername
USERDOMAIN_ROAMINGPROFILE=computername
USERNAME=username
USERPROFILE=C:\Users\username
windir=C:\WINDOWS
ZES_ENABLE_SYSMAN=1

[zadjii-msft]

Welp, C:\Users\username\AppData\Local\Microsoft\WindowsApps; is on the PATH, so that's weird. There's a dupe around here somewhere which might have more debugging steps, but I don't think we ever got to the root cause. Lemme dig that up.

[pilaoda]

I guess it is related to permission of the C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.14.1451.0_x64__8wekyb3d8bbwe. 1.15.1862.0 has the same problem.

https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps/1730061#1730061 This solution fix the wt in win+r, but it break my win start menu and taskbar.

https://github.com/AgentRev/WindowsAppsUnfukker This solution fix my win start menu and taskbar but the win+r -> wt is broken again!

I fall into a bad situation to choose one problem or the other. Hope my information can help to fix this problem.

[pilaoda]

Another solution I found is roll back the register key enableLUA from 0 back to 1, which I done to open cmd as admin everytime. https://evotec.xyz/how-to-permanently-disable-uac-in-windows-server/#:~:text=You%20have%20the%20option%20to,computer%20to%20activate%20the%20change. Follow this guide may help you reproduce this problem.

But open everything as admin save me a lot of time, and I ready need it . Hope this infomation can help, too.

[zadjii-msft]

roll back the register key enableLUA from 0 back to 1

HHHHHHHHMMMMMMMMMMMMM. That's interesting. I really don't think enableLUA=0 is super well supported, so I wouldn't be surprised to find out that disabling UAC entirely accidentally breaks app execution aliases.

FWIW, NEVER EVER EVER fuck with the permissions on C:\Program Files\WindowsApps. That's a recipe for disaster. If you fuck with those ACLs, it's possible to get your machine into a state where the only fix is a full reinstall of the OS. Just be warned.

I'm gonna close this out for bookkeeping since you seem to have figured this out. The enableLUA thing is really interesting, thanks for sharing ☺️

You may also be interested in Automatically run as Administrator, if you really need to run every command line instance elevated.

[Ldhlwh]

Thanks @pilaoda @zadjii-msft for the possible solutions, well my enableLUA was originally 1, and changing it to 0 and back to 1 fixed nothing.

Guess I messed up the permissions when my Microsoft Store stopped working last month. Tried a few solutions on the internet. Must be that time.

[Welding-Torch]

Happened to me in December 2023.

FWIW, NEVER EVER EVER fuck with the permissions on C:\Program Files\WindowsApps. That's a recipe for disaster. If you fuck with those ACLs, it's possible to get your machine into a state where the only fix is a full reinstall of the OS. Just be warned.

Ah, A few weeks ago I changed the permissions on the WindowsApps folder because I don't like there being a folder on MY PC that I don't have permissions to access. I suppose this must have caused running the wt command to break.

Which is weird, and shouldn't happen.

[zadjii-msft]

@Welding-Torch I'd say that the most recent incarnation of this is over in #16419. However, if you messed with the permissions on WindowsApps, I'm not totally sure there's a way to recover that. The packaged app infrastructure is very sensitive to those permissions. If you can write into that directory, then any malicious process (or hanlons_razor.exe) could write to the file contents of otherwise trusted packages, and then other apps could load malicious/bad code added into their package by mistake.

Don't touch WindowsApps.

[Welding-Torch]

@zadjii-msft Please note that I only changed the permissions for The WindowsApps folder on D: and that I have Windows Terminal installed on C:

I tried reinstalling Windows Terminal today, and that still did not fix the problem.

Also, launching Windows Terminal from either of the below .exe files doesn't work. Only launching it from the start menu works.

Can you suggest a solution to make Windows Terminal work normally again?

[zadjii-msft]

I honestly don't know. @DHowett might have a better suggestion. Touching WindowsApps is a one-way street to pain, I'm afraid.

You definitely shouldn't be running it directly from where it's installed in WindowsApps. By design, that folder has crazy locked down permissions. The Start Menu (or wt.exe in the run dialog/from a shell) will use a different method of creating our process which will work for launching the Terminal.

[Welding-Torch]

Please note that while launching it from the Start menu (image below) works

It is different from launching it using the run dialog/from a shell, which does not work

[zadjii-msft]

I'd suspect the reason the second isn't working is because the wt.exe that's being found in that case is not the app execution alias, but instead the actual wt.exe from in WindowsApps. Running where wt in a CMD window might be informative as to which wt the Run Dialog thinks it's running

[Welding-Torch]

C:\Users\bhatia>where wt
C:\Users\bhatia\AppData\Local\Microsoft\WindowsApps\wt.exe

Also I discovered, if I run wt from cmd then it works:

This is progress, now how do I get wt to run from the Run Dialog?

[Welding-Torch]

Update: Today I learned that I can run Windows Terminal from the Run dialogue by entering: explorer.exe shell:AppsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App