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

Task Manager "Switch To" from App History causes Terminal to respawn after exiting #13686

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

Originally created by @sna-scourtney on GitHub (Apr 30, 2021).

Windows Terminal version (or Windows build number)

Windows 10 Pro, 10.0.19042.928, Windows Terminal 1.7.1033.0

Other Software

Ubuntu 20.04 (stock kernel from Microsoft Store)

Steps to reproduce

  1. Run Windows Terminal with a single open bash session in Ubuntu 20.04
  2. Minimize this session
  3. Open Task Manager
  4. In Task Manager, go to the App History tab and find Windows Terminal
  5. Right-click on Windows Terminal and choose "Switch To" (this works as expected)
  6. From the bash session, type "exit" to close the WSL terminal shell

Expected Behavior

Windows Terminal should close until the next time its app icon is clicked (or it is otherwise intentionally started)

Actual Behavior

The terminal window closes as expected, but after a few seconds it spontaneously reopens at the same (or approximately the same) screen location.

This may be a very intermittent problem. I've been using Terminal extensively for about 3 weeks, but although the issue reproduces multiple times now, it has not occurred before.

I'm a programmer and know software doesn't "just break", so something has triggered this anomaly, but I have no idea what might be different. The shell in question is just an idle bash shell (non-root), and I'm not running any non-default daemons (like a database server) in the WSL environment.

Additional data about the current system status follows, but I have no idea if any of these might be related. I'm just capturing the raw data points while they are fresh in my memory.

  • I had just unlocked the screen after having it locked overnight. Normally I suspend the machine overnight, but I was working late so I just locked the screen instead.
  • The rest of Windows was basically idle other than a couple of web browser tabs sitting at non-interactive pages.
  • During the locked period, the CPU usage was high enough to spin the laptop's fans at near-max. That's why I was in Task Manager in the first place, to see what app or process was the culprit. In descending order of CPU usage history, they were: (1) MS Office (ironic, since I wasn't even using it); (2) MS My Phone (also ironic, since I have never used it whatsoever); (3) Windows Terminal.

I'm sorry for the vague report -- as a coder myself, I know this isn't going to be very useful, but at the moment this is all the data I have, and I thought it best to capture the incident early. I'll add this report to my watch list and append if I'm able to learn more.

As an aside, I'm a Linux sysadmin and not a Windows expert, so I'll be glad to run additional diags if someone can point me toward the appropriate tool. I'll gladly RTFM but have to know which "FM" to "R" first. :)

Originally created by @sna-scourtney on GitHub (Apr 30, 2021). ### Windows Terminal version (or Windows build number) Windows 10 Pro, 10.0.19042.928, Windows Terminal 1.7.1033.0 ### Other Software Ubuntu 20.04 (stock kernel from Microsoft Store) ### Steps to reproduce 1. Run Windows Terminal with a single open bash session in Ubuntu 20.04 2. Minimize this session 3. Open Task Manager 4. In Task Manager, go to the App History tab and find Windows Terminal 5. Right-click on Windows Terminal and choose "Switch To" (this works as expected) 6. From the bash session, type "exit" to close the WSL terminal shell ### Expected Behavior Windows Terminal should close until the next time its app icon is clicked (or it is otherwise intentionally started) ### Actual Behavior The terminal window closes as expected, but after a few seconds it spontaneously reopens at the same (or approximately the same) screen location. This may be a very intermittent problem. I've been using Terminal extensively for about 3 weeks, but although the issue reproduces multiple times **now**, it has not occurred before. I'm a programmer and know software doesn't "just break", so _something_ has triggered this anomaly, but I have no idea what might be different. The shell in question is just an idle bash shell (non-root), and I'm not running any non-default daemons (like a database server) in the WSL environment. Additional data about the current system status follows, but I have no idea if any of these might be related. I'm just capturing the raw data points while they are fresh in my memory. - I had just unlocked the screen after having it locked overnight. Normally I suspend the machine overnight, but I was working late so I just locked the screen instead. - The rest of Windows was basically idle other than a couple of web browser tabs sitting at non-interactive pages. - During the locked period, the CPU usage was high enough to spin the laptop's fans at near-max. That's why I was in Task Manager in the first place, to see what app or process was the culprit. In descending order of CPU usage history, they were: (1) MS Office (ironic, since I wasn't even using it); (2) MS My Phone (also ironic, since I have never used it whatsoever); (3) Windows Terminal. I'm sorry for the vague report -- as a coder myself, I know this isn't going to be very useful, but at the moment this is all the data I have, and I thought it best to capture the incident early. I'll add this report to my watch list and append if I'm able to learn more. As an aside, I'm a Linux sysadmin and not a Windows expert, so I'll be glad to run additional diags if someone can point me toward the appropriate tool. I'll gladly RTFM but have to know which "FM" to "R" first. :)
claunia added the Issue-BugNeeds-Tag-FixProduct-Terminal labels 2026-01-31 03:49:31 +00:00
claunia commented 2026-01-31 03:49:32 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Feb 22, 2023):

Verified this still occurs. Loaded it into the current milestone. Sorry for taking so long to get to this one! Thanks for being so patient!

@carlos-zamora commented on GitHub (Feb 22, 2023): Verified this still occurs. Loaded it into the current milestone. Sorry for taking so long to get to this one! Thanks for being so patient!
claunia commented 2026-01-31 03:49:32 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Apr 12, 2023):

This is most likely an issue in the way Task Manager has implemented "Switch To" and is not something we can fix on our side unfortunately. We'll make sure the appropriate people will know about this.

@lhecker commented on GitHub (Apr 12, 2023): This is most likely an issue in the way Task Manager has implemented "Switch To" and is not something we can fix on our side unfortunately. We'll make sure the appropriate people will know about this.
claunia commented 2026-01-31 03:49:32 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2024):

We ended up looking into this! It definitely seems like a Task Manager issue -- it reproduces with Notepad as well (!) -- which we'll bring up for their engineers to handle. It impacts all packaged Win32 applications.

@DHowett commented on GitHub (Sep 4, 2024): We ended up looking into this! It definitely seems like a Task Manager issue -- it reproduces with Notepad as well (!) -- which we'll bring up for their engineers to handle. It impacts all packaged Win32 applications.
claunia commented 2026-01-31 03:49:32 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2024):

Filed as MSFT:53670776

@DHowett commented on GitHub (Sep 4, 2024): Filed as MSFT:53670776
claunia commented 2026-01-31 03:49:33 +00:00
Author
Owner
Copy Link

@sna-scourtney commented on GitHub (Sep 5, 2024):

Thanks for the ongoing follow-up on this issue. I have moved to Linux as my main o.s., so it's no longer applicable to my own situation, but I'm glad for the sake of others that it will eventually be fixed by Microsoft.

@sna-scourtney commented on GitHub (Sep 5, 2024): Thanks for the ongoing follow-up on this issue. I have moved to Linux as my main o.s., so it's no longer applicable to my own situation, but I'm glad for the sake of others that it will eventually be fixed by Microsoft.
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-Bug Needs-Tag-Fix Product-Terminal
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#13686
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?