microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.23k stars 8.27k forks source link

Windows Terminal starts with white screen, then crashes when started from Explorer or Run dialogue #9891

Closed kiriDevs closed 3 years ago

kiriDevs commented 3 years ago

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.

zadjii-msft commented 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

ghost commented 3 years ago

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!

kiriDevs commented 3 years ago

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.

yutotakano commented 3 years ago

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.

kiriDevs commented 3 years ago

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.

yutotakano commented 3 years ago

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.

kiriDevs commented 3 years ago

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.

rlabrecque commented 3 years ago

I was also hitting this using the Store version. Using the "Reset" option worked: image

https://aka.ms/AAcdg3i

kiriDevs commented 3 years ago

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.