PATH in child process includes Windows Terminal Preview installation directory, if started via Win+R wt.exe

[KalleOlaviNiemitalo]

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.388]
Windows Terminal version (if applicable): Windows Terminal Preview 1.2.2022.0

Steps to reproduce

1. Enable the wt.exe app execution alias of Windows Terminal Preview.
2. Press Windows+R to open the Run dialog box.
3. Type wt.exe and press Enter to start Windows Terminal Preview.
4. In Windows Terminal Preview, start the Command Prompt profile.
5. In the Command Prompt session, type PATH and press Enter.

Expected behavior

The displayed value of PATH does not include the directory where Windows Terminal Preview was installed.

Actual behavior

C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe is the first directory in PATH.

Notes

This is presumably caused by the Registry values that were created by AppXSvc when Windows Terminal Preview was installed:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe]
@="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe"
"Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe]
@="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe\\wt.exe"
"Path"="C:\\Program Files\\WindowsApps\\Microsoft.WindowsTerminalPreview_1.2.2022.0_x64__8wekyb3d8bbwe"

According to Application Registration, ShellExecuteEx prepends the data of the "Path" Registry value to the PATH environment variable of the new process. That seems unnecessary here, as selecting Windows Terminal Preview from the Start menu does not add to PATH.

Because non-packaged processes of users have no access to the "C:\Program Files\WindowsApps" directory, this addition to PATH perhaps does not cause problems. However, if wt.exe is run as administrator, then the PATH addition could cause a process in the terminal session to load DLLs from the installation directory of Windows Terminal Preview. (If a packaged application is run within the terminal session, then that too would have access to the directory, but Search Order for Windows Store apps looks like the PATH environment variable will not affect DLL loading in that case.)

Related to #6860, #6748, #7188. Found while searching for possible causes of #7195.

[DHowett]

So, a few notes.

• I think this is harmless. There's no executable in our package that the user shouldn't be able to launch, and nothing that will incorrectly eclipse things that are on their PATHs.
• We don't have any control over this.
• I can't find this entry in PATH when I elevate wt.exe
• Packaged applications don't follow the traditional DLL search order, so I don't think it likely that they'll inherit WT's libraries

[DHowett]

Incidentally, this and the last seven issues are the first (and second through seventh) times I've ever heard of App Paths, and I didn't know the system was maintaining it on our behalf.

[KalleOlaviNiemitalo]

• I can't find this entry in PATH when I elevate wt.exe

How do you elevate it? If I type wt.exe in the Run dialog box and press Ctrl+Shift+Enter, then the WT installation directory does appear in PATH in the Command Prompt session.

[DHowett]

Yep, using Ctrl+Shift+Enter from the Run dialog.

[KalleOlaviNiemitalo]

We don't have any control over this.

I imagine Windows Terminal could explicitly delete its installation directory from PATH in the environment block that it passes to CreateProcess.

Or use CreateEnvironmentBlock as suggested in #1125, instead of copying PATH and other variables from the environment of the WindowsTerminal.exe process.

Yep, using Ctrl+Shift+Enter from the Run dialog.

That's strange… Are you using the same version of Windows 10? Does the PATH change even get to the WindowsTerminal.exe process? Process Monitor filtering with Operation = Process Start is handy for checking this.

[ghost]

🎉This issue was addressed in #7243, which has now been successfully released as Windows Terminal Preview v1.3.2382.0.:tada:

Handy links:

• Release Notes
• Store Download

[KalleOlaviNiemitalo]

#7243 did not fix this for the following child processes:

• the editor that Windows Terminal starts for editing settings.json (and presumably defaults.json)
• C:\WINDOWS\system32\wsl.exe --list
• Web browser processes started by the Feedback menu item or by hyperlinks on the About screen

According to #7460, the extra entry in Path interferes with the loading of vcruntime140.dll from other directories in Path, if C:\Windows\System32\VCRUNTIME140.dll does not exist.

Please reopen.

[DHowett]

Huh.

[JustinGrote]

@DHowett not sure if this is related but when I do Win+R then wt.exe, currently getting this:

EDIT: It was this problem. I deleted the above registry keys and restarted, put the wt preview in my path, and everything works fine.

[KalleOlaviNiemitalo]

Retested with Windows Terminal Preview 1.12.3472.0 on Windows 10.0.19044.1415:

• 🆗 The Command Prompt session in the tab does not inherit the extra PATH.
• 🆗 No wsl.exe --list process is started.
• 🆗 The wsl.exe -d Debian process does not inherit the extra PATH.
• ⚠️ The Web browser process started by the Documentation link in the About dialog box inherits the extra path.
• ⚠️ The JSON file editor inherits the extra path.

[zadjii-msft]

Merging notes:

I can reproduce this, but it is not specific to WSL.

1. Pin Windows Terminal Preview 1.15.2002.0 to the task bar on Windows 10.0.19044.1826. (maintainer note: also repros on Win11)
2. Set Command Prompt as the default profile.
3. Close Windows Terminal Preview.
4. Start Windows Terminal Preview by left-clicking the task-bar button.
5. Execute PATH in the Command Prompt session. The output does not include the Windows Terminal Preview installation directory. ✅
6. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
7. Execute PATH in the Command Prompt session in the second tab. The output does not include the Windows Terminal Preview installation directory. ✅
8. Close Windows Terminal Preview.
9. Start Windows Terminal Preview by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
10. Execute PATH in the Command Prompt session. The output starts with Windows Terminal Preview installation directory. ❌
11. Open another tab by right-clicking the task-bar button and left-clicking the "Command Prompt" task.
12. Execute PATH in the Command Prompt session in the second tab. The output starts with Windows Terminal Preview installation directory. ❌

Probably also related:
#7188 (comment)

I can reproduce with Windows Terminal 1.1.2021.0 and Windows Terminal Preview 1.2.2022.0 on Windows 10 version 2004 (OS Build 19041.388):

• If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer starts Windows Terminal Preview. ✔
• If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer shows the access-denied dialog box. ❌
• If I disable both wt.exe app execution aliases, then wt in File Explorer shows the access-denied dialog box. 🙄 In this case though, I shouldn't expect wt to work anyway.

When I install Windows Terminal Preview, AppXSvc creates the following Registry keys:

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

Those Registry keys stay there when I enable or disable the wt.exe app execution aliases. They seem related to #6748 and #6860. If I rename the Registry keys, then the results change:

• If I enable the wt.exe app execution alias of Windows Terminal Preview, then wt in File Explorer runs Windows Terminal Preview. ✔
• If I enable the wt.exe app execution alias of Windows Terminal, then wt in File Explorer runs Windows Terminal. ✔
• If I disable both wt.exe app execution aliases, then wt in File Explorer opens http://wt/ in my Web browser. 🙄

If I disable the skype.exe app execution alias and type skype.exe in the Windows+R run box or in the File Explorer address bar, then I get a similar access-denied dialog box, so this is not specific to Windows Terminal.

If Windows needs a Registry key in App Paths, then perhaps it should keep the per-user key always synchronized with the app execution aliases, and not create the per-machine key.

So, we added wt.exe to the package[1], so that the alias could point at an exe with the same literal name. But that caused MORE issues. Sometimes, the package's install directory is prepended to the path. That causes the OS to load the wt from inside WindowsApps, instead of the actual alias.

dupes?

• Strange starting directory when launched from explorer.exe's address bar #12640
• Windows Terminal folder on path, causes problems with wt.exe #13460
• WT command in Windows Explorer does not work anymore #7188
• Windows terminal path is different if launched with wt.exe #11777

internal work

• MSFT:28217948 was duped to MSFT:29353059 which was fixed in os.2020!5514481, which should have shipped in 21307, around the time of Windows 11.

here's my understanding:

I believe that bad ACLs on WindowsApps can cause the first PERMISSION_DENIED to fail (user was NOT denied access), and bad ACLs on the WindowsTerminal package can cause the "Try Again" to fail (Package-ID-Token was rejected?)

Conclusions:

• "Win+R / Explorer.exe failed to start wt.exe": That should probably be fixed in Windows 11
• **"wt is launched with C:\Program Files\WindowsApps\Microsoft.WindowsTerminal* prepended to the path: We should probably just cut that out of the PATH ourselves, if we see it. It'll do no good.

[1]: See #6860 which was supposed to fix #6625:

It turns out that when an application's alias name doesn't match its filename (as in our case, wt.exe is an alias for WindowsTerminal.exe ), it fails out during elevated launch.

[zadjii-msft]

A thought: This might have been fixed by #14999.

[ianjoneill]

A thought: This might have been fixed by #14999.

Yep - looks like it:

And if I set compatibility.reloadEnvironmentVariables to false: