Terminal: Wrong wt.exe binary picked up when invoked through explorer's search bar

[erikha1501]

Environment

Windows build number:
Microsoft Windows [Version 10.0.19041.508]

Windows Terminal version (if applicable):
1.3.200825002-release1.3 (installed through Microsoft store)

Steps to reproduce

1. Open Windows Explorer
2. Type in the search box "wt" or "wt -d ." then hit enter
3. Check the path where wt.exe is located. It looks something like this: "C:Program FilesWindowsAppsMicrosoft.WindowsTerminalPreview_1.3.2382.0_x64__8wekyb3d8bbwewt.exe"
   The newly opened Windows Terminal has this info:

Windows Terminal (Unpackaged)
Version: 1.3.200825002-release1.3

Expected behavior

The actual wt.exe binary should be located at "~AppDataLocalMicrosoftWindowsAppswt.exe". Running wt.exe through:

• Run Dialog (Win+R)
• Start (typing "wt" in Windows search)
• Explorer's search bar

yield the same result.
However if I run it via cmd or powershell the correct Windows Terminal shows up.

I'm not sure if this is a bug in the terminal installation process or my windows environment is messed up. Here's a few things I noticed:

• "~AppDataLocalMicrosoftWindowsApps" directory is included in the PATH environment variable
• PATH does not contain anything like "C:Program FilesWindowsApps"
• The "wrong" version of wt.exe fires up a Windows Terminal associated with a settings.json file located at "~AppDataLocalMicrosoftWindows Terminalsettings.json". In contrast the normal settings.json lives at "~AppDataLocalPackagesMicrosoft.WindowsTerminalPreview_8wekyb3d8bbweLocalStatesettings.json"
• This problem persists if I switch to the stable version of Windows Terminal

[erikha1501]

It seems like the installation process adds 2 following entries to registry:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe

Each has a pair of [Default] and Path string values pointing to the "wrong" wt.exe binary. Windows Explorer and Run Dialog Box might query this information to locate wt.exe. After removing these 2 entries, the expected behavior is observed.

[zadjii-msft]

@DHowett @cinnamon-msft we should author a docs page about how wt works with both stable and preview installed, and how to pick which one you want to use in the settings app, since we keep getting this issue

[DHowett]

@zadjii-msft so this is weird—it doesn’t look like stable vs preview here, it looks like one of their versions is _unpackaged_.

@erikha1501 you haven’t changed any permissions in Program FilesWindowsApps, have you?

[erikha1501]

I once took ownership of Program FilesWindowsApps to give me full control access. I added an permission entry then gave the ownership back to TrustedInstaller. This might be the culprit.

[DHowett]

So, the files in that directory are usually only protected by the permissions that stop you from seeing them.

I believe that _if the files in that folder are visible_, the App Paths entry for wt might accidentally launch it directly out of Program Files. This would be like taking the contents of the application and running them without the rest of the package identity.

Terminal sorta supports this, but it's supposed to be by user choice.

If you remove the permission entry that you added, does the issue go away?

[KalleOlaviNiemitalo]

So, the files in that directory are usually only protected by the permissions that stop you from seeing them.

On Windows 10 version 2004 (OS Build 19041.508), I am able to list the files with dir "C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.3.2382.0_x64__8wekyb3d8bbwe" and run wt.exe from there, as a standard user. I have not changed the permissions nor ownership there. On the other hand, dir "C:\Program Files\WindowsApps" does not work, unless elevated.

[erikha1501]

If you remove the permission entry that you added, does the issue go away?

It did. After removing the entry and reinstalling Windows Terminal, the "unpackaged" version goes away.
I still can take a peak inside Program Files\WindowsApps\Microsoft.WindowsTerminal_1.2.2381.0_x64__8wekyb3d8bbwe, run wt.exe directly and it still works. Somehow that previously added permission entry prevented Windows Terminal from installing/running correctly. Messing with Program Files\WindowsApps folder was _not_ a good idea after all.

@DHowett @cinnamon-msft we should author a docs page about how wt works with both stable and preview installed, and how to pick which one you want to use in the settings app, since we keep getting this issue

Documentation on how wt.exe works is definitely welcomed.

[DHowett]

Thanks for confirming! I'm gonna close this as resolved, but the learnings are still pretty interesting. I can bring them back to the application install folks -- they own the code that writes the App Paths entries that have been implicated in a number of our issues.

wt.exe actually just runs WindowsTerminal.exe from the same folder. There's nothing special about it; it's just that Terminal supports running inside and outside a "package" and it was never expected that it would be able to run outside of a package even though it had been installed _inside_ one!

[erikha1501]

wt.exe actually just runs WindowsTerminal.exe from the same folder

It definitely does more than just runs WindowsTerminal.exe as I can't get WindowsTerminal.exe to run on its own (Windows cannot access the specified device, path... error pops up if I try to do so). I suppose this behavior is intended. Nevertheless I can always look at the source code to see what wt.exe does.

Anyway thanks for the support on this one!

[DHowett]

I promise you that's all it does on our side. Here's the source, all 36 lines of it: https://github.com/microsoft/terminal/blob/master/src/cascadia/wt/shim.cpp

The app platform sets up permissions such that wt.exe is the only executable in the package that can be invoked directly -- this is part of the "app execution alias" infrastructure that populates %LOCALAPPDATA%\microsoft\windowsapps and in general does the work of exposing packaged executables as "normal" executables.

[DHowett]

But all of that stuff happens outside of our codebase, in the AppXSvc system service. The extent of our code is "just launch WindowsTerminal.exe". Once the process has "package identity" granted to it by the OS, it's allowed to do so.