starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-31 03:45:30 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 03:45:30 +00:00
Owner
Copy Link

Originally created by @kiriDevs on GitHub (Apr 19, 2021).

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.

Originally created by @kiriDevs on GitHub (Apr 19, 2021). ### 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.
claunia added the Resolution-DuplicateCulprit-Centennial labels 2026-01-31 03:45:31 +00:00
claunia commented 2026-01-31 03:45:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 19, 2021):

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

@zadjii-msft commented on GitHub (Apr 19, 2021): 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
claunia commented 2026-01-31 03:45:32 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 19, 2021):

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!

@ghost commented on GitHub (Apr 19, 2021): 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!
claunia commented 2026-01-31 03:45:32 +00:00
Author
Owner
Copy Link

@kiriDevs commented on GitHub (Apr 19, 2021):

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.

@kiriDevs commented on GitHub (Apr 19, 2021): 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.
claunia commented 2026-01-31 03:45:33 +00:00
Author
Owner
Copy Link

@yutotakano commented on GitHub (Apr 25, 2021):

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.

@yutotakano commented on GitHub (Apr 25, 2021): 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.
claunia commented 2026-01-31 03:45:33 +00:00
Author
Owner
Copy Link

@kiriDevs commented on GitHub (Apr 25, 2021):

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.

@kiriDevs commented on GitHub (Apr 25, 2021): 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.
claunia commented 2026-01-31 03:45:33 +00:00
Author
Owner
Copy Link

@yutotakano commented on GitHub (Apr 27, 2021):

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.

@yutotakano commented on GitHub (Apr 27, 2021): 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.
claunia commented 2026-01-31 03:45:33 +00:00
Author
Owner
Copy Link

@kiriDevs commented on GitHub (Apr 27, 2021):

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.

@kiriDevs commented on GitHub (Apr 27, 2021): 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](https://github.com/microsoft/terminal/releases) BUT backup your config before, there's a change it uses a different path.
claunia commented 2026-01-31 03:45:34 +00:00
Author
Owner
Copy Link

@rlabrecque commented on GitHub (Apr 29, 2021):

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

https://aka.ms/AAcdg3i

@rlabrecque commented on GitHub (Apr 29, 2021): I was also hitting this using the Store version. Using the "Reset" option worked: ![image](https://user-images.githubusercontent.com/2047188/116626572-55d44180-a900-11eb-8c40-c3abeb3e3172.png) https://aka.ms/AAcdg3i
claunia commented 2026-01-31 03:45:34 +00:00
Author
Owner
Copy Link

@kiriDevs commented on GitHub (Apr 30, 2021):

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.

@kiriDevs commented on GitHub (Apr 30, 2021): > 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Culprit-Centennial Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13548
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?