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

Terminal closes when sleeping - MSIX release? #23174

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

Originally created by @thatsysadmin on GitHub (Apr 19, 2025).

Windows Terminal version

1.22.10731.0 - Windows Store, not GitHub Releases

Windows build number

24H2 26100.3775

Other Software

Not Applicable

Steps to reproduce

  • Open Windows Terminal
  • Sleep machine
  • Result: Terminal is closed

Expected Behavior

Terminal should recover with the system and not be closed out.

Actual Behavior

Terminal closes when machine sleeps and doesn't recover. I can reproduce this fairly reliably.

Originally created by @thatsysadmin on GitHub (Apr 19, 2025). ### Windows Terminal version 1.22.10731.0 - Windows Store, not GitHub Releases ### Windows build number 24H2 26100.3775 ### Other Software Not Applicable ### Steps to reproduce - Open Windows Terminal - Sleep machine - Result: Terminal is closed ### Expected Behavior Terminal should recover with the system and not be closed out. ### Actual Behavior Terminal closes when machine sleeps and doesn't recover. I can reproduce this fairly reliably.
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 08:34:25 +00:00
claunia commented 2026-01-31 08:34:26 +00:00
Author
Owner
Copy Link

@similar-issues-ai[bot] commented on GitHub (Apr 19, 2025):

We've found some similar issues:

  • #7183 , similarity score: 85%
  • #11611 , similarity score: 85%
  • #14377 , similarity score: 82%
  • #18685 , similarity score: 82%

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

@similar-issues-ai[bot] commented on GitHub (Apr 19, 2025): We've found some similar issues: - #7183 , similarity score: 85% - #11611 , similarity score: 85% - #14377 , similarity score: 82% - #18685 , similarity score: 82% If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue. > Note: You can give me feedback by 👍 or 👎 this comment.
claunia commented 2026-01-31 08:34:26 +00:00
Author
Owner
Copy Link

@thatsysadmin commented on GitHub (Apr 19, 2025):

Notes

EDIT: I've been live updating this thread about my observations. Sorry.

  • I did see some tickets about this issue, but everything's closed.
  • The Windows install is fairly fresh - installed like 3-4 weeks ago.
  • I tried to quickly capture something with WinDbg to see if there were any clues, but WinDbg seems to exhibit the same behavior even when it's not debugging anything.
  • WSL does not seem to have an impact on behavior, so not too sure what's going on.
  • Opening a classic Powershell window recovers just fine.
  • Aparantly this only happens with the one shipped in the Windows Store. The .zip build that is on GitHub releases seems fine.
@thatsysadmin commented on GitHub (Apr 19, 2025): **Notes** EDIT: I've been live updating this thread about my observations. Sorry. - I did see some tickets about this issue, but everything's closed. - The Windows install is fairly fresh - installed like 3-4 weeks ago. - I tried to quickly capture something with WinDbg to see if there were any clues, but WinDbg seems to exhibit the same behavior even when it's not debugging anything. - WSL does not seem to have an impact on behavior, so not too sure what's going on. - Opening a classic Powershell window recovers just fine. - Aparantly this only happens with the one shipped in the Windows Store. The .zip build that is on GitHub releases seems fine.
claunia commented 2026-01-31 08:34:26 +00:00
Author
Owner
Copy Link

@thatsysadmin commented on GitHub (Apr 19, 2025):

I think I figured it out but putting this in it's own comment block for clarity. I still think that this is an issue that needs to be addressed so I'm leaving it open.

So when the machine is short on memory, stuff packaged as MSIX are killed before sleep (this would explain the clean kill symptom of #18685) then restored if possible after the fact. I tried with Affinity Photo ("sideloaded" from Serif's site but packed as an MSIX, fits your definition of a standard desktop app, gets killed), WinDbg (Similar to Photo, but got it through the MS Store, also gets killed), and Microsoft Store (reloads but recovers) all have this symptom. I run with swap disabled, so that probably excaserbated the issue.

Rebooting (clearing memory) fixed this, so I'm just going to use my machine for a bit to put memory under pressure again to see if I can reproduce this.

Update 4/27/2025 - The kills start to happen around 70% memory usage.

Speculation Past This Block ^tm
The reason why the Windows Terminal .zip release was fine was because it wasn't added as an MSIX, and the system thinks that all MSIX packages can save state when closed. While it's fine for something more managed (like Microsoft Store), it's not the case for standard desktop apps that are hastily shoved into a MSIX bundle. So there probably needs to be a flag somewhere in the packaging for MSIX that tells Windows that these apps cannot recover state if they are closed and reopened (but I don't want to encourage the idea of continously writing app state to disk, because SSDs are write sensitive media at the end of the day).

Side note: This is an argument for machines to be shipping with more RAM, and if you're hitting swap, you don't have enough of it.

@thatsysadmin commented on GitHub (Apr 19, 2025): I think I figured it out but putting this in it's own comment block for clarity. I still think that this is an issue that needs to be addressed so I'm leaving it open. So when the machine is short on memory, stuff packaged as MSIX are killed before sleep (this would explain the clean kill symptom of #18685) then restored if possible after the fact. I tried with Affinity Photo ("sideloaded" from Serif's site but packed as an MSIX, fits your definition of a standard desktop app, gets killed), WinDbg (Similar to Photo, but got it through the MS Store, also gets killed), and Microsoft Store (reloads but recovers) all have this symptom. I run with swap disabled, so that probably excaserbated the issue. Rebooting (clearing memory) fixed this, so I'm just going to use my machine for a bit to put memory under pressure again to see if I can reproduce this. **Update 4/27/2025** - The kills start to happen around 70% memory usage. **Speculation Past This Block ^tm** The reason why the Windows Terminal .zip release was fine was because it wasn't added as an MSIX, and the system thinks that *all* MSIX packages can save state when closed. While it's fine for something more managed (like Microsoft Store), it's not the case for standard desktop apps that are hastily shoved into a MSIX bundle. So there probably needs to be a flag somewhere in the packaging for MSIX that tells Windows that these apps cannot recover state if they are closed and reopened (but I don't want to encourage the idea of continously writing app state to disk, because SSDs are write sensitive media at the end of the day). Side note: This is an argument for machines to be shipping with more RAM, and if you're hitting swap, you don't have enough of it.
claunia commented 2026-01-31 08:34:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 23, 2025):

Thanks for the detailed write-up!

I wonder if there's something we can add to our manifest to opt out of lifetime management? I wouldn't expect "centennial" (that is, packaged Win32) applications to be subject to an expectation that they can pause/resume/exit at will.

I'll file a bug on the MSIX team and close this one out (and reopen it if it turns out there's something we can do about it.)

@DHowett commented on GitHub (Apr 23, 2025): Thanks for the detailed write-up! I wonder if there's something we can add to our manifest to opt out of lifetime management? I wouldn't expect "centennial" (that is, packaged Win32) applications to be subject to an expectation that they can pause/resume/exit at will. I'll file a bug on the MSIX team and close this one out (and reopen it if it turns out there's something we can do about it.)
claunia commented 2026-01-31 08:34:27 +00:00
Author
Owner
Copy Link

@thatsysadmin commented on GitHub (Apr 23, 2025):

@DHowett - Before you bother the MSIX team, what about this?

There's aparantly a flag uap10:RuntimeBehavior that if set to "win32App" should opt out of lifetime management. Thing is, it also disables the filesystem and registry virtualization (probably doesn't matter because the actual shell processes run completely unrestricted anyway, so there probably wouldn't be any point).

Doing a hastily done search via GitHub for win32App doesn't return any results, and I'm not too sure how Terminal is packaged. I can't dig too much into the code because my development machine is MIA at the moment, and I'm far from it right now.

https://blogs.windows.com/windowsdeveloper/2019/10/29/identity-registration-and-activation-of-non-packaged-win32-apps/

Win32 type RuntimeBehavior
To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.

@thatsysadmin commented on GitHub (Apr 23, 2025): @DHowett - Before you bother the MSIX team, what about this? There's aparantly a flag `uap10:RuntimeBehavior` that if set to "win32App" should opt out of lifetime management. Thing is, it also disables the filesystem and registry virtualization (probably doesn't matter because the actual shell processes run completely unrestricted anyway, so there probably wouldn't be any point). Doing a hastily done search via GitHub for win32App doesn't return any results, and I'm not too sure how Terminal is packaged. I can't dig too much into the code because my development machine is MIA at the moment, and I'm far from it right now. https://blogs.windows.com/windowsdeveloper/2019/10/29/identity-registration-and-activation-of-non-packaged-win32-apps/ > Win32 type RuntimeBehavior > To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.
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-Triage
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#23174
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?