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

[PR #12825] Try to silently fall back to a local monarch #29257

New Issue
Open
opened 2026-01-31 09:33:46 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:33:46 +00:00
Owner
Copy Link

Original Pull Request: https://github.com/microsoft/terminal/pull/12825

State: closed
Merged: Yes

This is a crazy idea Dustin and I had.

we can't repro this at will. But we kinda have an idea of where the deref is. We don't know if the small patch (throw, and try again) will fix it. We're sure that the "just fall back to an isolated monarch" will work. I'd almost rather take a build testing the small patch first, to see if that works

This might seem crazy
in 1.12, isolated monarch. In 1.13, "small patch". In 1.14, we can wait and see

UPDATED DESCRIPTION

From the stack we think that the monarch may be null in an inlined call to _areWeTheKing. So, our really silly solution is two parts:

  • on preview, we're gonna just throw an exception and try it again. All the callers of _createMonarchAndCallbacks catch exceptions here, but they can't catch an A/V (this isn't Java). Hopefully, we should be able to try again until we find ourselves. The worry is that there's something else funky, preventing COM from EVER giving us a monarch. If that's the case, this solution will HANG the terminal on startup.
  • On release, we're just gonna fall back to a in-proc Monarch. This is definitely torn state - this window won't be able to communicate with other windows, but theoretically other windows could communicate with this process (though, they won't be talking with the fallback monarch instance). This is a bigger hammer - it'll definitely prevent us from exploding. but it's torn.

We don't have the runway to test the preview one, then submit the Release one if the Preview one doesn't work. So we're just gonna commit the big hammer to the OS now, and test the small hammer in the preview builds. If the preview version of the fix works, we'll just enable that for all 1.13+ builds, and get rid of the big hammer.

Checklist

**Original Pull Request:** https://github.com/microsoft/terminal/pull/12825 **State:** closed **Merged:** Yes --- This is a crazy idea Dustin and I had. > we can't repro this at will. But we kinda have an idea of where the deref is. We don't know if the small patch (throw, and try again) will fix it. We're sure that the "just fall back to an isolated monarch" will work. I'd almost rather take a build testing the small patch first, to see if that works > This might seem crazy > in 1.12, isolated monarch. In 1.13, "small patch". In 1.14, we can wait and see ### UPDATED DESCRIPTION From the stack we think that the monarch may be null in an inlined call to _areWeTheKing. So, our really silly solution is two parts: * on preview, we're gonna just throw an exception and try it again. All the callers of _createMonarchAndCallbacks catch exceptions here, but they can't catch an A/V (this isn't Java). Hopefully, we should be able to try again until we find ourselves. The worry is that there's something else funky, preventing COM from EVER giving us a monarch. If that's the case, this solution will HANG the terminal on startup. * On release, we're just gonna fall back to a in-proc Monarch. This is definitely torn state - this window won't be able to communicate with other windows, but theoretically other windows could communicate with this process (though, they won't be talking with the fallback monarch instance). This is a bigger hammer - it'll definitely prevent us from exploding. but it's torn. We don't have the runway to test the preview one, then submit the Release one if the Preview one doesn't work. So we're just gonna commit the big hammer to the OS now, and test the small hammer in the preview builds. If the preview version of the fix works, we'll just enable that for all 1.13+ builds, and get rid of the big hammer. ### Checklist * [x] @dhowett double check my velocity flag logic here. Should be always true for Release, and off for Dev, Preview. * [x] closes #12774
claunia added the pull-request label 2026-01-31 09:33:46 +00:00
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 pull-request
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#29257
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?