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

Clarification on WinX Menu PowerShell Fallback - Disappearance of "Windows Terminal" after Crash #17141

New Issue
Closed
opened 2026-01-31 05:33:17 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 05:33:17 +00:00
Owner
Copy Link

Originally created by @lzlrd on GitHub (Apr 3, 2022).

Windows Terminal version

1.12.10393.0

Windows build number

10.0.22581.0

Other Software

No response

Steps to reproduce

Not really sure how to describe this other than the system froze up for some reason and I hard-rebooted.

Expected Behavior

For "Windows Terminal" to appear in the WinX menu instead of "Windows PowerShell".

Actual Behavior

"Windows PowerShell" appears in the WinX menu, which according to https://github.com/microsoft/terminal/issues/12204 is supposed to fallback when wt.exe (via App Execution Aliases) is unavailable. Here's a visual of what I mean:

the screenshot

wt.exe did error out at first when being called from Run, but after performing a "Repair" from within the app's Settings it successfully runs on both an Administrator and standard user account. Furthermore, the default Terminal is set to "Windows Terminal" on both accounts. However, it still does not appear within the WinX menu. Other AEAs, such as python.exe and the Sysinternals Suite, are functioning as they should.

For now, I've hacked around the issue by adjusting the shortcuts at %LOCALAPPDATA%\Microsoft\Windows\WinX\Group3 to point to wt.exe (weirdly enough, they don't reset as I thought they would due to the requirement for WinX shortcuts to have metadata hashes) but that doesn't seem to work for the (Admin) modes which is what I really used the WinX shortcut for (as you can see in the screenshot, I've already got Terminal pinned).

Originally created by @lzlrd on GitHub (Apr 3, 2022). ### Windows Terminal version 1.12.10393.0 ### Windows build number 10.0.22581.0 ### Other Software _No response_ ### Steps to reproduce Not really sure how to describe this other than the system froze up for some reason and I hard-rebooted. ### Expected Behavior For "Windows Terminal" to appear in the WinX menu instead of "Windows PowerShell". ### Actual Behavior "Windows PowerShell" appears in the WinX menu, which according to https://github.com/microsoft/terminal/issues/12204 is supposed to fallback when `wt.exe` (via App Execution Aliases) is unavailable. Here's a visual of what I mean: ![*the screenshot*](https://user-images.githubusercontent.com/24303423/161404476-79370996-8fcd-4646-9d89-adc1642772c2.png) `wt.exe` did error out at first when being called from Run, but after performing a "Repair" from within the app's Settings it successfully runs on both an Administrator and standard user account. Furthermore, the default Terminal is set to "Windows Terminal" on both accounts. However, it still does not appear within the WinX menu. Other AEAs, such as `python.exe` and the Sysinternals Suite, are functioning as they should. For now, I've hacked around the issue by adjusting the shortcuts at `%LOCALAPPDATA%\Microsoft\Windows\WinX\Group3` to point to `wt.exe` (weirdly enough, they don't reset as I thought they would due to the requirement for WinX shortcuts to have metadata hashes) but that doesn't seem to work for the `(Admin)` modes which is what I really used the WinX shortcut for (as you can see in the screenshot, I've already got Terminal pinned).
claunia commented 2026-01-31 05:33:19 +00:00
Author
Owner
Copy Link

@lzlrd commented on GitHub (Apr 3, 2022):

I'd like to clarify on what I meant by the title a little. I think we need some sort of logging or message as to why Windows Terminal doesn't appear in the WinX menu, or at least a list of checks that are needed for it to be listed. This would help to diagnose the actual issue for each person (eg. my issue differs from https://github.com/microsoft/terminal/issues/12204 as wt.exe is runnable from pretty much anywhere).

@lzlrd commented on GitHub (Apr 3, 2022): I'd like to clarify on what I meant by the title a little. I think **we need** some sort of logging or message as to why Windows Terminal doesn't appear in the WinX menu, or at least a list of checks that are needed for it to be listed. This would help to diagnose the actual issue for each person (eg. my issue differs from https://github.com/microsoft/terminal/issues/12204 as `wt.exe` is runnable from pretty much anywhere).
claunia commented 2026-01-31 05:33:19 +00:00
Author
Owner
Copy Link

@lzlrd commented on GitHub (Apr 3, 2022):

I also found out that the feature configuration for File Explorer's tabs also reset after the crash I mentioned (I've since done DISM and SFC repairs). If Windows Terminal in the WinX menu was behind a feature config. then maybe that is related, in my case at least?

@lzlrd commented on GitHub (Apr 3, 2022): I also found out that the feature configuration for File Explorer's tabs also reset after the crash I mentioned (I've since done DISM and SFC repairs). If Windows Terminal in the WinX menu was behind a feature config. then maybe that is related, in my case at least?
claunia commented 2026-01-31 05:33:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 4, 2022):

Part of the issue here is that the WinX Menu (I think) only reloads on a reboot. So if it detects that the Terminal isn't registered yet in the Appx Catalog, then it'll stick with PowerShell for the entire session. And I think Terminal only gets registered the first time that it's actually run.

Do note that this is an experience we're trying to actively work on with the explorer.exe team, so this may be out of date in a few months.

@zadjii-msft commented on GitHub (Apr 4, 2022): Part of the issue here is that the WinX Menu (I think) only reloads on a reboot. So if it detects that the Terminal isn't registered yet in the Appx Catalog, then it'll stick with PowerShell for the entire session. And I think Terminal only gets registered the first time that it's actually run. Do note that this is an experience we're trying to actively work on with the explorer.exe team, so this may be out of date in a few months.
claunia commented 2026-01-31 05:33:20 +00:00
Author
Owner
Copy Link

@lzlrd commented on GitHub (Apr 4, 2022):

Part of the issue here is that the WinX Menu (I think) only reloads on a reboot. So if it detects that the Terminal isn't registered yet in the Appx Catalog, then it'll stick with PowerShell for the entire session. And I think Terminal only gets registered the first time that it's actually run.

Do note that this is an experience we're trying to actively work on with the explorer.exe team, so this may be out of date in a few months.

I have rebooted a few times now, but unfortunately its still showing "Windows PowerShell". I'm quite certain that Terminal is registered? within the AppX Catalog since it appears in https://www.microsoft.com/store/productId/9N3BC2N6MWXW and performs as expected (outside of this issue).

@lzlrd commented on GitHub (Apr 4, 2022): > Part of the issue here is that the WinX Menu (I think) only reloads on a reboot. So if it detects that the Terminal isn't registered yet in the Appx Catalog, then it'll stick with PowerShell for the entire session. And I think Terminal only gets registered the first time that it's actually run. > > Do note that this is an experience we're trying to actively work on with the explorer.exe team, so this may be out of date in a few months. I have rebooted a few times now, but unfortunately its still showing "Windows PowerShell". I'm quite certain that Terminal is registered? within the AppX Catalog since it appears in https://www.microsoft.com/store/productId/9N3BC2N6MWXW and performs as expected (outside of this issue).
claunia commented 2026-01-31 05:33:20 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 5, 2022):

Sorry, by "registered in the Appx catalog", I'm talking about a very specific process that happens locally when a package is installed. The Terminal is pre-installed, but it's set up as a "delayed registration", so it's sorta in a weird state where not all parts of it have been hooked up to the rest of the OS yet. That hooking up process we call "registering with the appx catalog".

Also, there may also be a subset of builds where it's just always PowerShell. I think that's after they turned off the link to WT, but before they added the logic if they checked if wt was registered. IIRC (trying to pull a number from my head from a meeting yesterday), I believe 22583 is the build that will bring Terminal back to this menu.

@zadjii-msft commented on GitHub (Apr 5, 2022): Sorry, by "registered in the Appx catalog", I'm talking about a very specific process that happens locally when a package is installed. The Terminal is pre-installed, but it's set up as a "delayed registration", so it's sorta in a weird state where not all parts of it have been hooked up to the rest of the OS yet. That hooking up process we call "registering with the appx catalog". Also, there may also be a subset of builds where it's just _always_ PowerShell. I think that's after they turned off the link to WT, but before they added the logic if they checked if `wt` was registered. IIRC (trying to pull a number from my head from a meeting yesterday), I believe 22583 is the build that will bring Terminal back to this menu.
claunia commented 2026-01-31 05:33:20 +00:00
Author
Owner
Copy Link

@lzlrd commented on GitHub (Apr 5, 2022):

Sorry, by "registered in the Appx catalog", I'm talking about a very specific process that happens locally when a package is installed. The Terminal is pre-installed, but it's set up as a "delayed registration", so it's sorta in a weird state where not all parts of it have been hooked up to the rest of the OS yet. That hooking up process we call "registering with the appx catalog".

I see, thanks for the clarification.

Also, there may also be a subset of builds where it's just always PowerShell. I think that's after they turned off the link to WT, but before they added the logic if they checked if wt was registered. IIRC (trying to pull a number from my head from a meeting yesterday), I believe 22583 is the build that will bring Terminal back to this menu.

Alright. I did run an update between the crash and noticing the issue in question, so I'll wait till Build 22583 hits before reporting back. Thanks.

PS: It may be preferable to add a note to https://blogs.windows.com/windows-insider/2022/03/23/announcing-windows-11-insider-preview-build-22581 regarding this issue.

@lzlrd commented on GitHub (Apr 5, 2022): > Sorry, by "registered in the Appx catalog", I'm talking about a very specific process that happens locally when a package is installed. The Terminal is pre-installed, but it's set up as a "delayed registration", so it's sorta in a weird state where not all parts of it have been hooked up to the rest of the OS yet. That hooking up process we call "registering with the appx catalog". I see, thanks for the clarification. > Also, there may also be a subset of builds where it's just _always_ PowerShell. I think that's after they turned off the link to WT, but before they added the logic if they checked if `wt` was registered. IIRC (trying to pull a number from my head from a meeting yesterday), I believe 22583 is the build that will bring Terminal back to this menu. Alright. I did run an update between the crash and noticing the issue in question, so I'll wait till Build 22583 hits before reporting back. Thanks. PS: It may be preferable to add a note to https://blogs.windows.com/windows-insider/2022/03/23/announcing-windows-11-insider-preview-build-22581 regarding this issue.
claunia commented 2026-01-31 05:33:20 +00:00
Author
Owner
Copy Link

@lzlrd commented on GitHub (Apr 7, 2022):

Build 22593 seems to have fixed the issue, thanks.

@lzlrd commented on GitHub (Apr 7, 2022): Build 22593 seems to have fixed the issue, thanks.
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 Issue-Question Needs-Tag-Fix Needs-Triage Product-Terminal Resolution-Answered Resolution-External
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#17141
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?