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

[1.18+] On Windows 10, Terminal reserves ~15 MB of memory per window opened at the same time #19908

New Issue
Closed
opened 2026-01-31 06:57:08 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 06:57:08 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (May 18, 2023).

Note

: 📌 Pinned comment: https://github.com/microsoft/terminal/issues/15384#issuecomment-1642357426

This is from me deploying to a Win10 19041 VM.

Closed a second window, then hovered over the first. At some point got:

>	Windows.UI.Xaml.Controls.dll!winrt::throw_hresult(const winrt::hresult result) Line 4524	C++
 	[Inline Frame] Windows.UI.Xaml.Controls.dll!winrt::check_hresult(winrt::hresult) Line 4612	C++
 	Windows.UI.Xaml.Controls.dll!winrt::impl::consume_Windows_UI_Xaml_IDependencyObject<AcrylicBrush>::GetValue(const winrt::Windows::UI::Xaml::DependencyProperty & dp) Line 1045	C++
 	[Inline Frame] Windows.UI.Xaml.Controls.dll!AcrylicBrushProperties::AlwaysUseFallback() Line 150	C++
 	Windows.UI.Xaml.Controls.dll!AcrylicBrush::UpdateAcrylicBrush() Line 996	C++
    ...

This one's a hard failfast that can't be continued. Window also seems to be in a normal state? In a normal _messagePump?

This happens every time I hover the split button after closing another window on Windows 10, but not on Windows 11.

Originally posted by @zadjii-msft in https://github.com/microsoft/terminal/issues/15364#issuecomment-1553479521

Originally created by @zadjii-msft on GitHub (May 18, 2023). <hr> > **Note**: 📌 Pinned comment: **https://github.com/microsoft/terminal/issues/15384#issuecomment-1642357426** <hr> This is from me deploying to a Win10 19041 VM. Closed a second window, then hovered over the first. At some point got: ``` > Windows.UI.Xaml.Controls.dll!winrt::throw_hresult(const winrt::hresult result) Line 4524 C++ [Inline Frame] Windows.UI.Xaml.Controls.dll!winrt::check_hresult(winrt::hresult) Line 4612 C++ Windows.UI.Xaml.Controls.dll!winrt::impl::consume_Windows_UI_Xaml_IDependencyObject<AcrylicBrush>::GetValue(const winrt::Windows::UI::Xaml::DependencyProperty & dp) Line 1045 C++ [Inline Frame] Windows.UI.Xaml.Controls.dll!AcrylicBrushProperties::AlwaysUseFallback() Line 150 C++ Windows.UI.Xaml.Controls.dll!AcrylicBrush::UpdateAcrylicBrush() Line 996 C++ ... ``` This one's a hard failfast that can't be continued. Window also seems to be in a normal state? In a normal `_messagePump`? #### This happens every time I hover the split button after closing another window on Windows 10, but not on Windows 11. _Originally posted by @zadjii-msft in https://github.com/microsoft/terminal/issues/15364#issuecomment-1553479521_
claunia added the Issue-BugNeeds-Tag-FixProduct-TerminalArea-Windowing labels 2026-01-31 06:57:09 +00:00
claunia commented 2026-01-31 06:57:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 18, 2023):

Relevant threads:

  • MSFT:31861775
  • MSFT:32109540
  • os.2020!6512498

Basically, when we close a DesktopWindowXamlSource, it calls to Windows_UI_Xaml!DirectUI::MetadataAPI::Reset, which resets the XAML metadata provider for the process. So, closing one DWXS on one thread fucks all the other threads with XAML.

This was fixed in Windows 11 by os.2020!5837001. That wasn't backported to Windows 10. We may be in a bad spot.

  • Not release 1.18 for Windows 10, until that's fixed?
  • Hold the release entirely until we find some workaround?
  • Manually disable process model v3 on Windows 10 (is that even possible?)
  • Leak the DesktopWindowsXamlSource (ew)
  • Use some sort of threadpool to hold on to expired windows, and re-use them for subsequent windows (this will still consume extra memory, but only up to "max number of simultaneous windows" instead of "the total number of windows opened")
  • Ship to Win11. Hold off on shipping to win10 until we do the threadpool thing?
@zadjii-msft commented on GitHub (May 18, 2023): Relevant threads: * MSFT:31861775 * MSFT:32109540 * os.2020!6512498 Basically, when we close a `DesktopWindowXamlSource`, it calls to `Windows_UI_Xaml!DirectUI::MetadataAPI::Reset`, which resets the XAML metadata provider _for the process_. So, closing one DWXS on one thread fucks all the other threads with XAML. This was fixed in Windows 11 by os.2020!5837001. That wasn't backported to Windows 10. We may be in a bad spot. * Not release 1.18 for Windows 10, until that's fixed? * Hold the release entirely until we find some workaround? * Manually disable process model v3 on Windows 10 (is that even possible?) * Leak the `DesktopWindowsXamlSource` (ew) * Use some sort of threadpool to hold on to expired windows, and re-use them for subsequent windows (this will still consume extra memory, but only up to "max number of simultaneous windows" instead of "the total number of windows opened") * Ship to Win11. Hold off on shipping to win10 until we do the threadpool thing?
claunia commented 2026-01-31 06:57:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 22, 2023):

After #15397, closing a window on Win10 will simply leak the window. This will result in a ~15 MB memory leak, which is Bad but less bad than full on crashing.

I'm working on a way to re-use old threads. That'll cause the leak to be scaled on N="max number of simultaneously open windows" rather than M="total number of closed windows over the life of the Terminal process"

@zadjii-msft commented on GitHub (May 22, 2023): After #15397, closing a window on Win10 will simply leak the window. This will result in a ~15 MB memory leak, which is **B**ad but less bad than full on crashing. I'm working on a way to re-use old threads. That'll cause the leak to be scaled on N="max number of simultaneously open windows" rather than M="total number of closed windows over the life of the Terminal process"
claunia commented 2026-01-31 06:57:10 +00:00
Author
Owner
Copy Link

@sh-shahrokhi commented on GitHub (Jun 8, 2023):

does the leak occur when running on windows 11 too?

@sh-shahrokhi commented on GitHub (Jun 8, 2023): does the leak occur when running on windows 11 too?
claunia commented 2026-01-31 06:57:10 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 8, 2023):

does the leak occur when running on windows 11 too?

It shouldn't!

@DHowett commented on GitHub (Jun 8, 2023): > does the leak occur when running on windows 11 too? It shouldn't!
claunia commented 2026-01-31 06:57:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 19, 2023):

As of #15424 merging, this has been reduced to "On Windows 10, the terminal permanently reserves ~15MB of memory per maximum number of concurrently opened windows". Still not great. But this is probably what we're going to have to live with for 1.18+.

There's possibly... a lot of XAML-side fixes that might need backporting to fix Windows 10 entirely. That's unfortunate, because it makes creating a servicing patch hard-to-impossible to create 😢

@zadjii-msft commented on GitHub (Jul 19, 2023): As of #15424 merging, this has been reduced to "On Windows 10, the terminal permanently reserves ~15MB of memory per maximum number of **concurrently** opened windows". Still not great. But this is probably what we're going to have to live with for 1.18+. There's possibly... a _lot_ of XAML-side fixes that might need backporting to fix Windows 10 entirely. That's unfortunate, because it makes creating a servicing patch hard-to-impossible to create 😢
claunia commented 2026-01-31 06:57:11 +00:00
Author
Owner
Copy Link

@driver1998 commented on GitHub (Dec 18, 2023):

While chatting about this with @MouriNaruto offline, he mentioned that it seems only the very first DesktopWindowXamlSource instance (which hosts a CoreWindow for compatibility) will need to be kept, not all of them.

He ended up firing up an empty, hidden XAML window at the very beginning of his app and be done with it:
https://github.com/microsoft/terminal/issues/6507#issuecomment-1474696835

@driver1998 commented on GitHub (Dec 18, 2023): While chatting about this with @MouriNaruto offline, he mentioned that it seems only the very first DesktopWindowXamlSource instance (which hosts a CoreWindow for compatibility) will need to be kept, not all of them. He ended up firing up an empty, hidden XAML window at the very beginning of his app and be done with it: https://github.com/microsoft/terminal/issues/6507#issuecomment-1474696835
claunia commented 2026-01-31 06:57:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 19, 2025):

Hey guess what! As of Terminal 1.23, we don't need to do the goofy window refrigeration anymore. So this will no longer be an issue.

This was fixed in #18215

@zadjii-msft commented on GitHub (Feb 19, 2025): Hey guess what! As of Terminal 1.23, we don't need to do the goofy window refrigeration anymore. So this will no longer be an issue. This was fixed in #18215
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 Area-Windowing 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#19908
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?