Closed kiriDevs closed 3 years ago
This might actually be a weird interaction of #9452, mixed with the unpackaged crash from #9821. For some reason, even when installed from the Store, the OS forgets that we're a packaged application and decides to run the Terminal unpackaged. That would run you right into the crash in #9821. The reasons for this are poorly understood. The time it happened to me, it went away with a reboot or toggling the "app execution alias" for wt.exe
in the system Settings app (I can't remember which). #9452 and the linked threads might have more solutions listed if that doesn't work for you. Sorry about this 😕
/dup #9821 /dup #9452
Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Just wanted to do a little update because I toyed around a bit and first of all, I found out that that execution alias was everything that kept any functionality of wt
as it's own command / app for me. It only ever failed when I tried to access C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\wt.exe
directly and always worked when accessing the app execution alias at C:\Users\kiron\AppData\Local\Microsoft\WindowsApps\wt.exe
. My start menu only worked because I apparently manually created a shortcut to that app execution alias before.
So if everyone else experiences this, it would probably be a good idea to check the permissions on the C:\Program Files\WindowsApps
folder again, as described in #9452. I don't currently assume #9821 is involved, it was just my startmenu shortcut that preserved a bit of functionality.
Using the where
command in cmd.exe, I also found out that PATHs are handled differently depending on how Windows Terminal ist started, but I assume that's a different topic so I will not elaborate this topic further at this time.
Interesting, does the Run window (and Explorer address bar) use a different wt.exe than the one in my PATH?
As @kiriDevs analysed, it seems to launch fine from %localappdata%, but the one in Program Files launched to a white window. If I run where wt
it points to the one in %localappdata% though. I've restarted my machine multiple times to see if it was a weird PATH propagation issue, but no avail.
Yes, I think they do use a different wt.exe
. The Run window seems to use the C:\Program Files\WindowsApps\Microsoft.WindowsTerminal___\wt.exe
, while the rest uses the Execution Alias located in my AppData\Local
, which seems to be working fine.
I suppose it might be something about Run and the Explorer starting it as a different user and therefore not being able to access that Execution Alias and also being subject to different permissions. However, all my permissions for ProgramFiles\WindowsApps
should be on default, as I reset them multiple times after poking around in an attempt to fix the issue for my machine.
Personally, although it seemed unrelated, the scoop
fix apparently was relevant -- I have no idea why, as I don't use scoop
nor do I call wt
from weird places, but maybe the Run dialog is an instance of "Terminal being run outside of its application package."
After downloading the msixbundle release for the fix (nothing complex, it immediately prompts you if you want to upgrade Terminal), calling wt
from the Run dialog and the Explorer URL box now work perfectly.
Thanks, that also worked for me. It apparently uses a different config (at least for me), because I was reverted to an older version of mine (which I had saved in another config file), but I had a snapshot of mine made after I deleted it last time after originally trying to fix the issue with a reload.
TL;DR: Get the .msixbundle
from the releases page here on GitHub BUT backup your config before, there's a change it uses a different path.
I was also hitting this using the Store version. Using the "Reset" option worked:
Both repairing and resetting, nor reinstalling helped with the issue.
I read that often, too, but it didn't help for me. Perhaps there are multiple causes to this, some being fixed by the reset function, some being fixed by installing the latest .msixbundle
, and some just remaining without fix as of now, as stated in #9959.
Windows Terminal version (or Windows build number)
1.7.1033.0
Other Software
No response
Steps to reproduce
After the latest update I installed, Windows Terminal is not starting correctly when invoking
wt
from the Windows Explorer or the "Run" dialogue (WIN + R
)Expected Behavior
Windows Terminal starts properly and launches an instance of my default command interpreter (or the one I specified with
-p
).Actual Behavior
I get a completely white screen, no title bar or anything, before it crashes and closes after a second or two. Apparently similar to the behaviour described in #9821, but I installed the release from the Microsoft Store and it only happens when started from Explorer or Run.
Both repairing and resetting, nor reinstalling helped with the issue. I can also not think or remember anything special I have done to my system or environment that could have caused this, and it started with the update to the WT version indicated above.