starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Process Model v3 / Tab tear-out ship list #19490

New Issue
Open
opened 2026-01-31 06:44:56 +00:00 by claunia · 17 comments
claunia commented 2026-01-31 06:44:56 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Mar 6, 2023).

Moving this to separate from #14900. I want that to SPECIFICALLY track tag dragging UX issues (which could apply to us or maybe anyone else using TabView).

For general tab tear-out &U drag drop UX issues, see: ---> #14900 <---

This is a list of things we need to fix to get #5000 / #1256 out the door.

Original PRs:

PR Blockers

We shouldn't even merge these to main like this

### PR bugs
- [x] I went into settings to turn on the tray icon, and it crashed when I hit Save. (fixed in 35c7474ab)
- [x] Another curious A/V crash when hot-reloading, with a null Dispatcher? (fixed in 6e4b2e104)
- [x] (ainulindale) Windows don't get activated when they're first created (fixed in 704220f7e)
- [x] (ainu) defterm is ALL SORTS of fucked (fixed in a1a86eb6c)
- [x] (party) tear-out of a single window (with no other running windows) closes the Terminal
- [x] (party) Tear-out a window upscales it on high DPI (805b880da)
- [x] (?) `wt -w _quake` is broken?

Ship blockers

We can merge these, but iterate in post

### Follow-ups
- [x] Opening settings in two windows at the same time causes a crash (This is upstream MUX#7283)
- [x] I launched an elevated profile, then closed it, and admin terminal stuck around in the tray
- [x] centerOnLaunch:true overrides the tear-out position (fixed in b107f7d20)
- [x] Tearing out of a maximized window shouldn't stay maximized (805b880da)
- [x] `_windowExitedHandler()` would have to be called inside the try clause as a `wil::scope_exit`
- [x] (ainulindale) remove isolated monarch `features.xml`
- [x] Setting terminal as defterm, via the Settings app, while the Terminal is running, opens the previously set terminal (stable), not the Preview one - **we think this was just a bad sefterm build, but need to retry to confirm**
- [x] If you tear out of a single window with session restore turned on, and two windows in `state.json`, then when recreating the window, we'll restore the other window from state (and possibly explode 💥)
- [x] (silmarillion) attaching a tab to an existing window throws a rendered warning?? -2005270527 - **we haven't seen this in a long time**
- [x] (silmarillion) moving a tab to a larger window doesn't resize the control - **THIS WAS AN ATLAS BUG**
- [ ] https://github.com/microsoft/terminal/issues/15156
- [x] https://github.com/microsoft/terminal/issues/15144
- [x] https://github.com/microsoft/terminal/issues/15121
- [x] https://github.com/microsoft/terminal/issues/6507
- [x] That one internal thread about hidden windows, see https://github.com/microsoft/terminal/commit/2c16e7c07b496e2bfbd399d2534d7d3a0ebb1db5#r109802295
- [ ] #15209
- [x] MSFT:43995981
- [x] (move pane to new window) The window should not be allowed to be named "new". This is in monarch somewhere.
- [x] (move pane to new window)  We should not do anything if the target is the source window

_windowExitedHandler() would have to be called inside the try clause as a wil::scope_exit

see discussion in https://github.com/microsoft/terminal/pull/14843#discussion_r1140486873

Let's just do it in post

### In post
- [x] Evaluate moving the `_ProcessLazySettingsChanges` block in `AppLogic::Create` to after the page is initialized
- [ ] `openSettings` should take a `page` param to open to a specific page.
- [ ] `moveTab`/`Pane` should accept `next` and `previous` to move tabs to the next/previous window. Inspired by #15156
- [ ] Dropping a tab from 100% to High DPI creates the window at a position that's about 1 scaling factor offset from where it should
- [ ] Investigate using a helper struct for passing panes, tabs, content between windows, instead of serializing to JSON. Might need to be stored in ContentManager until the new window can open the content.
- [ ] If we tear out the only tab in a window, to a new window, can we just... move the window there? ;D
- [ ] Tell users why they can't drop a tab; perhaps with a message? Are we allowed to include arbitrary "YOU CANNOT DROP BECAUSE" text?
- [ ] `--isolated` as a cmdline arg
- [ ] `--isolated` shouldn't globalhotkeys, tray icon, defterm, _quake
- [ ] #15271
- [ ] Can we just cover the entire tabview with the drag rect when there's only one tab?
- [ ] https://github.com/microsoft/terminal/issues/15895
- [ ] https://github.com/microsoft/terminal/issues/15763

Did we fix it?

Things we may have accidentally fixed on the way?

### Fixed?
* [ ] #14012
Originally created by @zadjii-msft on GitHub (Mar 6, 2023). Moving this to separate from #14900. I want that to SPECIFICALLY track tag dragging UX issues (which could apply to us or maybe anyone else using TabView). ### For general tab tear-out &U drag drop UX issues, see: ---> **#14900** <--- This is a list of things we need to fix to get #5000 / #1256 out the door. ## Original PRs: * [x] #14825 * [x] #14843 * [x] #14851 * [x] #14866 * [x] #14901 * [x] #14935 ## PR Blockers _We shouldn't even merge these to `main` like this_ ```[tasklist] ### PR bugs - [x] I went into settings to turn on the tray icon, and it crashed when I hit Save. (fixed in 35c7474ab) - [x] Another curious A/V crash when hot-reloading, with a null Dispatcher? (fixed in 6e4b2e104) - [x] (ainulindale) Windows don't get activated when they're first created (fixed in 704220f7e) - [x] (ainu) defterm is ALL SORTS of fucked (fixed in a1a86eb6c) - [x] (party) tear-out of a single window (with no other running windows) closes the Terminal - [x] (party) Tear-out a window upscales it on high DPI (805b880da) - [x] (?) `wt -w _quake` is broken? ``` ## Ship blockers _We can merge these, but iterate in post_ ```[tasklist] ### Follow-ups - [x] Opening settings in two windows at the same time causes a crash (This is upstream MUX#7283) - [x] I launched an elevated profile, then closed it, and admin terminal stuck around in the tray - [x] centerOnLaunch:true overrides the tear-out position (fixed in b107f7d20) - [x] Tearing out of a maximized window shouldn't stay maximized (805b880da) - [x] `_windowExitedHandler()` would have to be called inside the try clause as a `wil::scope_exit` - [x] (ainulindale) remove isolated monarch `features.xml` - [x] Setting terminal as defterm, via the Settings app, while the Terminal is running, opens the previously set terminal (stable), not the Preview one - **we think this was just a bad sefterm build, but need to retry to confirm** - [x] If you tear out of a single window with session restore turned on, and two windows in `state.json`, then when recreating the window, we'll restore the other window from state (and possibly explode 💥) - [x] (silmarillion) attaching a tab to an existing window throws a rendered warning?? -2005270527 - **we haven't seen this in a long time** - [x] (silmarillion) moving a tab to a larger window doesn't resize the control - **THIS WAS AN ATLAS BUG** - [ ] https://github.com/microsoft/terminal/issues/15156 - [x] https://github.com/microsoft/terminal/issues/15144 - [x] https://github.com/microsoft/terminal/issues/15121 - [x] https://github.com/microsoft/terminal/issues/6507 - [x] That one internal thread about hidden windows, see https://github.com/microsoft/terminal/commit/2c16e7c07b496e2bfbd399d2534d7d3a0ebb1db5#r109802295 - [ ] #15209 - [x] MSFT:43995981 - [x] (move pane to new window) The window should not be allowed to be named "new". This is in monarch somewhere. - [x] (move pane to new window) We should not do anything if the target is the source window ``` > `_windowExitedHandler()` would have to be called inside the try clause as a `wil::scope_exit` see discussion in https://github.com/microsoft/terminal/pull/14843#discussion_r1140486873 ## Let's just do it in post ```[tasklist] ### In post - [x] Evaluate moving the `_ProcessLazySettingsChanges` block in `AppLogic::Create` to after the page is initialized - [ ] `openSettings` should take a `page` param to open to a specific page. - [ ] `moveTab`/`Pane` should accept `next` and `previous` to move tabs to the next/previous window. Inspired by #15156 - [ ] Dropping a tab from 100% to High DPI creates the window at a position that's about 1 scaling factor offset from where it should - [ ] Investigate using a helper struct for passing panes, tabs, content between windows, instead of serializing to JSON. Might need to be stored in ContentManager until the new window can open the content. - [ ] If we tear out the only tab in a window, to a new window, can we just... move the window there? ;D - [ ] Tell users why they can't drop a tab; perhaps with a message? Are we allowed to include arbitrary "YOU CANNOT DROP BECAUSE" text? - [ ] `--isolated` as a cmdline arg - [ ] `--isolated` shouldn't globalhotkeys, tray icon, defterm, _quake - [ ] #15271 - [ ] Can we just cover the entire tabview with the drag rect when there's only one tab? - [ ] https://github.com/microsoft/terminal/issues/15895 - [ ] https://github.com/microsoft/terminal/issues/15763 ``` ## Did we fix it? _Things we may have accidentally fixed on the way?_ ```[tasklist] ### Fixed? * [ ] #14012 ```
claunia commented 2026-01-31 06:44:57 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 6, 2023):

"Opening settings in two windows at the same time causes a crash"

This is apparently a "The application called an interface that was marshalled for a different thread" bug. Interestingly, seems like you can usually step through in the debugger and continue on.

Happens any time you navigate to a page in the second terminal window. Like, all of the pages hit this on navigate. Even the Actions page, which doesn't have a SettingsContainer (so we can rule that out)

Stowed xaml exception is:

Stowed xaml exception (dropdown) 
0:047> !xamlstowed
-------------------------
Callstack for hr=8001010e - The application called an interface that was marshalled for a different thread.

    Windows_UI_Xaml!DirectUI::UIElementGenerated::InvalidateMeasure+0x7c  (7fffab98e10c) [onecoreuap\windows\dxaml\xcp\dxaml\lib\winrtgeneratedclasses\uielement.g.cpp @ 4272]
    Microsoft_UI_Xaml!ItemsRepeater::InvalidateMeasureForLayout+0x6e  (7fff30c71efe) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 780]
    Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::RoutedEventHandler,<lambda_ea38bbb57a12d8fa822b5d3c49379960> >::Invoke+0x3b  (7fff30cc982b) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.Foundation.h @ 883]
    Microsoft_UI_Xaml!event_base<event<winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable> >,winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable>,winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable> >::operator  (7fff30cc93ca) [C:\a\_work\1\s\dev\inc\event.h @ 77]
    Microsoft_UI_Xaml!StackLayout::OnItemsChangedCore+0xc3  (7fff30ccff33) [C:\a\_work\1\s\dev\Repeater\StackLayout.cpp @ 97]
    Microsoft_UI_Xaml!winrt::impl::produce<VirtualizingLayout,winrt::Microsoft::UI::Xaml::Controls::IVirtualizingLayoutOverrides>::OnItemsChangedCore+0x48  (7fff30ce0128) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 24714]
    Microsoft_UI_Xaml!ItemsRepeater::OnItemTemplateChanged+0x3e7  (7fff30c6ef67) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 621]
    Microsoft_UI_Xaml!ItemsRepeater::OnPropertyChanged+0x204  (7fff30c6f4d4) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 412]
    Microsoft_UI_Xaml!ItemsRepeaterProperties::OnLayoutPropertyChanged+0x61  (7fff30c6eb41) [C:\a\_work\1\s\dev\Generated\ItemsRepeater.properties.cpp @ 153]
    Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::PropertyChangedCallback,<lambda_7e7a26da47dff7b0d2ec2f8ae5761249> >::Invoke+0x33  (7fff30cd1ab3) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.UI.Xaml.h @ 4660]
    Windows_UI_Xaml!DirectUI::DependencyObject::NotifyPropertyChanged+0x4d7  (7fffabac0837) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 2325]
    Windows_UI_Xaml!CDependencyObject::SetEffectiveValue+0x23ae  (7fffababfc6e) [onecoreuap\windows\dxaml\xcp\components\dependencyobject\propertysystem.cpp @ 1698]
    Windows_UI_Xaml!CDependencyObject::UpdateEffectiveValue+0x3f7  (7fffabaaa317) [onecoreuap\windows\dxaml\xcp\components\dependencyobject\propertysystem.cpp @ 1979]
    Windows_UI_Xaml!CUIElement::SetValue+0x2bb  (7fffabaa942b) [onecoreuap\windows\dxaml\xcp\core\core\elements\uielement.cpp @ 784]
    Windows_UI_Xaml!CFrameworkElement::SetValue+0x25b  (7fffabaa771b) [onecoreuap\windows\dxaml\xcp\core\core\elements\framework.cpp @ 236]
    Windows_UI_Xaml!CPanel::SetValue+0x43  (7fffabaa67f3) [onecoreuap\windows\dxaml\xcp\core\core\elements\panel.cpp @ 112]
    Windows_UI_Xaml!DirectUI::DependencyObject::SetValueCore+0x2d6  (7fffab9fd7be) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 1432]
    Windows_UI_Xaml!DirectUI::DependencyObject::SetValueInternal+0x234  (7fffab9fcd1c) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 1624]
    Windows_UI_Xaml!DirectUI::DependencyObject::SetValue+0x63  (7fffab9fc9c3) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 3119]
    Microsoft_UI_Xaml!winrt::impl::produce<ItemsRepeater,winrt::Microsoft::UI::Xaml::Controls::IItemsRepeater>::put_ItemTemplate+0x101  (7fff30cd43e1) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 12965]
    Microsoft_UI_Xaml!winrt::impl::consume_Microsoft_UI_Xaml_Controls_IItemsRepeater<winrt::Microsoft::UI::Xaml::Controls::IItemsRepeater>::ItemTemplate+0x17  (7fff30c5d22f) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 1984]
    Microsoft_UI_Xaml!BreadcrumbBarItem::InstantiateFlyout+0x1fa  (7fff31002cbe) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 541]
    Microsoft_UI_Xaml!BreadcrumbBarItem::SetPropertiesForEllipsisItem+0x17  (7fff31005343) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 572]
    Microsoft_UI_Xaml!BreadcrumbBarItem::OnLoadedEvent+0x12b  (7fff310041db) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 152]
    Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::Input::PointerEventHandler,<lambda_d24ce1ad3fc78a05e655cec846f07e09> >::Invoke+0x3b  (7fff30d3e23b) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.Foundation.h @ 894]
    Windows_UI_Xaml!DirectUI::CRoutedEventSourceBase<DirectUI::IUntypedEventSource,Windows::UI::Xaml::IRoutedEventHandler,IInspectable,Windows::UI::Xaml::IRoutedEventArgs>::Raise+0x325  (7fffabba0701) [onecoreuap\windows\dxaml\xcp\dxaml\lib\JoltClasses.h @ 1093]
    Windows_UI_Xaml!DirectUI::CRoutedEventSourceBase<DirectUI::IUntypedEventSource,Windows::UI::Xaml::IRoutedEventHandler,IInspectable,Windows::UI::Xaml::IRoutedEventArgs>::UntypedRaise+0x98  (7fffabba0358) [onecoreuap\windows\dxaml\xcp\dxaml\lib\JoltClasses.h @ 995]
    Windows_UI_Xaml!CommonBrowserHost::CLR_FireEvent+0x6d1  (7fffaba196c1) [onecoreuap\windows\dxaml\xcp\control\common\shared\CommonBrowserHost.hpp @ 771]
    Windows_UI_Xaml!CControlBase::ScriptCallback+0x18b  (7fffabe1159b) [onecoreuap\windows\dxaml\xcp\control\common\shared\controlbase.cpp @ 267]
    Windows_UI_Xaml!CXcpDispatcher::OnScriptCallback+0x230  (7fffabbdee10) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1376]
    Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x77c  (7fffabbdfdac) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 844]
    user32!UserCallWinProcCheckWow+0x2ba  (7fffc5f6696a) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 281]
    user32!DispatchClientMessage+0x9c  (7fffc5f663dc) [clientcore\windows\core\ntuser\client\daytona\objfre\amd64\client.cxx @ 3156]
    user32!__fnDWORD+0x3d  (7fffc5f8da4d) [onecoreuap\restricted\windows\inc\ntuser\inc\ntcb.h @ 1214]
    ntdll!KiUserCallbackDispatcherContinue  (7fffc81b38c4) [minkernel\ntos\rtl\amd64\trampoln.asm @ 607]
    win32u!ZwUserMessageCall+0x14  (7fffc5771584) [onecoreuap\windows\core\umode\moderncore\objfre\amd64\usrstubs.asm @ 197]
    user32!SendMessageWorker+0x1f2  (7fffc5f65bc2) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 661]
    user32!SendMessageW+0x43  (7fffc5f63433) [onecoreuap\restricted\windows\inc\private\core\ntuser\client\cltxt.h @ 789]
    Windows_UI_Xaml!CXcpBrowserHost::SyncScriptCallbackRequest+0x13b  (7fffaba9388b) [onecoreuap\windows\dxaml\xcp\host\win\browserdesktop\winbrowserhost.cpp @ 1048]
    Windows_UI_Xaml!CEventManager::RaiseHelper+0x1c2  (7fffabbf98f2) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 1068]
    Windows_UI_Xaml!CEventManager::RaiseLoadedEventForObject+0xe0  (7fffabb10e4c) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 712]
    Windows_UI_Xaml!CEventManager::RaiseLoadedEvent+0x1ab  (7fffabb10b8b) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 772]
    Windows_UI_Xaml!CCoreServices::NWDrawTree+0x252b  (7fffabb0272b) [onecoreuap\windows\dxaml\xcp\core\dll\xcpcore.cpp @ 6379]
    Windows_UI_Xaml!CXcpBrowserHost::OnTick+0x1bf  (7fffabaffd6f) [onecoreuap\windows\dxaml\xcp\host\win\browserdesktop\winbrowserhost.cpp @ 545]
    Windows_UI_Xaml!CXcpDispatcher::Tick+0x152  (7fffabbde972) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1478]
    Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x4f3  (7fffabbdfb23) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 841]
    Windows_UI_Xaml!CXcpDispatcher::MessageTimerCallbackStatic+0x81  (7fffabe9b6e1) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1555]
    CoreMessaging!CFlat::SehSafe::Execute<<lambda_654db17c35df07198786f0867aa10de6> >+0x2c  (7fffc249208c) [CFlatCorlib\1.0.220606003\CFlatCorlib\SehSafe.inl @ 11]
    CoreMessaging!Microsoft::CoreUI::Dispatch::TimeoutHandler::ImportAdapter$+0xb1  (7fffc2491f91) [mincore\CoreUI\Dev\System\Dispatch\TimeoutHandler.cs @ 16]
    CoreMessaging!Microsoft::CoreUI::Dispatch::TimeoutManager::Callback_OnDispatch+0x2d0  (7fffc249ca40) [mincore\CoreUI\Dev\System\Dispatch\TimeoutManager.cs @ 229]
    CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0x43b  (7fffc249bb7b) [mincore\CoreUI\Dev\System\Dispatch\EventLoop.cs @ 689]
    CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch+0x36b  (7fffc249899b) [mincore\CoreUI\Dev\System\Dispatch\UserAdapter.cs @ 1389]
    CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::DoWork+0x201  (7fffc24984d1) [mincore\coreui\dev\system\Dispatch\UserAdapterCommonN.cpp @ 610]
    CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::WindowProc+0x4d  (7fffc249788d) [mincore\coreui\dev\system\Dispatch\UserAdapterCommonN.cpp @ 415]
    user32!UserCallWinProcCheckWow+0x2ba  (7fffc5f6696a) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 281]
    user32!DispatchClientMessage+0x9c  (7fffc5f663dc) [clientcore\windows\core\ntuser\client\daytona\objfre\amd64\client.cxx @ 3156]
    user32!__fnDWORD+0x3d  (7fffc5f8da4d) [onecoreuap\restricted\windows\inc\ntuser\inc\ntcb.h @ 1214]
    ntdll!KiUserCallbackDispatcherContinue  (7fffc81b38c4) [minkernel\ntos\rtl\amd64\trampoln.asm @ 607]
    win32u!ZwUserGetMessage+0x14  (7fffc5771564) [onecoreuap\windows\core\umode\moderncore\objfre\amd64\usrstubs.asm @ 189]
    user32!GetMessageW+0x2a  (7fffc5f8e25a) [onecoreuap\restricted\windows\inc\private\core\ntuser\client\ntcftxt.h @ 537]
    WindowsTerminal!WindowThread::WindowProc+0x8d  (7ff713d0fa0d) [D:\dev\private\OpenConsole\src\cascadia\WindowsTerminal\WindowThread.cpp @ 85]
    WindowsTerminal!`WindowThread::Start'::`2'::<lambda_1>::operator  (7ff713d0fe92) [D:\dev\private\OpenConsole\src\cascadia\WindowsTerminal\WindowThread.cpp @ 29]
    WindowsTerminal!std::invoke<`WindowThread::Start'::`2'::<lambda_1> >+0x20  (7ff713d11690) [C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.33.31517\include\type_traits @ 1537]
    WindowsTerminal!std::thread::_Invoke<std::tuple<`WindowThread::Start'::`2'::<lambda_1> >,0>+0x82  (7ff713d110d2) [C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.33.31517\include\thread @ 56]
    ucrtbased!thread_start<unsigned int  (7fff5d7e3010) [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 97]
    KERNEL32!BaseThreadInitThunk+0x1d  (7fffc626292d) [clientcore\base\win32\client\thread.c @ 75]
    ntdll!RtlUserThreadStart+0x28  (7fffc815ef48) [minkernel\ntdll\rtlstrt.c @ 1192]

=========================
@$xamlstowed()                 : 1 ErrorContexts
    length           : 0x1
    [0x0]            : 0x182041d3200 : 0x8001010e in Windows_UI_Xaml!DirectUI::UIElementGenerated::InvalidateMeasure+0x7c [Type: ErrorContext *]

These look sus:

BreadcrumbBarItem::InstantiateFlyout
BreadcrumbBarItem::SetPropertiesForEllipsisItem
BreadcrumbBarItem::OnLoadedEvent

Oh dear

  • MSFT:43636600
  • MSFT:43572798
  • MSFT:43610406
  • MSFT:43536247 <---
  • MSFT:40838551 <---

Oh NOOOOO
https://github.com/microsoft/microsoft-ui-xaml/issues/7283

BreadcrumbBar causes "interface marshalled for different thread" crash in WinUI 2.7.1 (UWP)

@zadjii-msft commented on GitHub (Mar 6, 2023): ### "Opening settings in two windows at the same time causes a crash" This is apparently a "The application called an interface that was marshalled for a different thread" bug. Interestingly, seems like you can usually step through in the debugger and continue on. Happens any time you navigate to a page in the _second_ terminal window. Like, all of the pages hit this on navigate. Even the Actions page, which doesn't have a `SettingsContainer` (so we can rule that out) Stowed xaml exception is: <details> <summary>Stowed xaml exception (dropdown)</summary> ``` 0:047> !xamlstowed ------------------------- Callstack for hr=8001010e - The application called an interface that was marshalled for a different thread. Windows_UI_Xaml!DirectUI::UIElementGenerated::InvalidateMeasure+0x7c (7fffab98e10c) [onecoreuap\windows\dxaml\xcp\dxaml\lib\winrtgeneratedclasses\uielement.g.cpp @ 4272] Microsoft_UI_Xaml!ItemsRepeater::InvalidateMeasureForLayout+0x6e (7fff30c71efe) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 780] Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::RoutedEventHandler,<lambda_ea38bbb57a12d8fa822b5d3c49379960> >::Invoke+0x3b (7fff30cc982b) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.Foundation.h @ 883] Microsoft_UI_Xaml!event_base<event<winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable> >,winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable>,winrt::Windows::Foundation::TypedEventHandler<winrt::Microsoft::UI::Xaml::Controls::Layout,winrt::Windows::Foundation::IInspectable> >::operator (7fff30cc93ca) [C:\a\_work\1\s\dev\inc\event.h @ 77] Microsoft_UI_Xaml!StackLayout::OnItemsChangedCore+0xc3 (7fff30ccff33) [C:\a\_work\1\s\dev\Repeater\StackLayout.cpp @ 97] Microsoft_UI_Xaml!winrt::impl::produce<VirtualizingLayout,winrt::Microsoft::UI::Xaml::Controls::IVirtualizingLayoutOverrides>::OnItemsChangedCore+0x48 (7fff30ce0128) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 24714] Microsoft_UI_Xaml!ItemsRepeater::OnItemTemplateChanged+0x3e7 (7fff30c6ef67) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 621] Microsoft_UI_Xaml!ItemsRepeater::OnPropertyChanged+0x204 (7fff30c6f4d4) [C:\a\_work\1\s\dev\Repeater\ItemsRepeater.cpp @ 412] Microsoft_UI_Xaml!ItemsRepeaterProperties::OnLayoutPropertyChanged+0x61 (7fff30c6eb41) [C:\a\_work\1\s\dev\Generated\ItemsRepeater.properties.cpp @ 153] Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::PropertyChangedCallback,<lambda_7e7a26da47dff7b0d2ec2f8ae5761249> >::Invoke+0x33 (7fff30cd1ab3) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.UI.Xaml.h @ 4660] Windows_UI_Xaml!DirectUI::DependencyObject::NotifyPropertyChanged+0x4d7 (7fffabac0837) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 2325] Windows_UI_Xaml!CDependencyObject::SetEffectiveValue+0x23ae (7fffababfc6e) [onecoreuap\windows\dxaml\xcp\components\dependencyobject\propertysystem.cpp @ 1698] Windows_UI_Xaml!CDependencyObject::UpdateEffectiveValue+0x3f7 (7fffabaaa317) [onecoreuap\windows\dxaml\xcp\components\dependencyobject\propertysystem.cpp @ 1979] Windows_UI_Xaml!CUIElement::SetValue+0x2bb (7fffabaa942b) [onecoreuap\windows\dxaml\xcp\core\core\elements\uielement.cpp @ 784] Windows_UI_Xaml!CFrameworkElement::SetValue+0x25b (7fffabaa771b) [onecoreuap\windows\dxaml\xcp\core\core\elements\framework.cpp @ 236] Windows_UI_Xaml!CPanel::SetValue+0x43 (7fffabaa67f3) [onecoreuap\windows\dxaml\xcp\core\core\elements\panel.cpp @ 112] Windows_UI_Xaml!DirectUI::DependencyObject::SetValueCore+0x2d6 (7fffab9fd7be) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 1432] Windows_UI_Xaml!DirectUI::DependencyObject::SetValueInternal+0x234 (7fffab9fcd1c) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 1624] Windows_UI_Xaml!DirectUI::DependencyObject::SetValue+0x63 (7fffab9fc9c3) [onecoreuap\windows\dxaml\xcp\dxaml\lib\dependencyobject.cpp @ 3119] Microsoft_UI_Xaml!winrt::impl::produce<ItemsRepeater,winrt::Microsoft::UI::Xaml::Controls::IItemsRepeater>::put_ItemTemplate+0x101 (7fff30cd43e1) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 12965] Microsoft_UI_Xaml!winrt::impl::consume_Microsoft_UI_Xaml_Controls_IItemsRepeater<winrt::Microsoft::UI::Xaml::Controls::IItemsRepeater>::ItemTemplate+0x17 (7fff30c5d22f) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Microsoft.UI.Xaml.Controls.h @ 1984] Microsoft_UI_Xaml!BreadcrumbBarItem::InstantiateFlyout+0x1fa (7fff31002cbe) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 541] Microsoft_UI_Xaml!BreadcrumbBarItem::SetPropertiesForEllipsisItem+0x17 (7fff31005343) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 572] Microsoft_UI_Xaml!BreadcrumbBarItem::OnLoadedEvent+0x12b (7fff310041db) [C:\a\_work\1\s\dev\Breadcrumb\BreadcrumbBarItem.cpp @ 152] Microsoft_UI_Xaml!winrt::impl::delegate<winrt::Windows::UI::Xaml::Input::PointerEventHandler,<lambda_d24ce1ad3fc78a05e655cec846f07e09> >::Invoke+0x3b (7fff30d3e23b) [C:\a\_work\1\s\BuildOutput\Intermediates\x64\Microsoft.UI.Xaml\obj\Generated Files\winrt\Windows.Foundation.h @ 894] Windows_UI_Xaml!DirectUI::CRoutedEventSourceBase<DirectUI::IUntypedEventSource,Windows::UI::Xaml::IRoutedEventHandler,IInspectable,Windows::UI::Xaml::IRoutedEventArgs>::Raise+0x325 (7fffabba0701) [onecoreuap\windows\dxaml\xcp\dxaml\lib\JoltClasses.h @ 1093] Windows_UI_Xaml!DirectUI::CRoutedEventSourceBase<DirectUI::IUntypedEventSource,Windows::UI::Xaml::IRoutedEventHandler,IInspectable,Windows::UI::Xaml::IRoutedEventArgs>::UntypedRaise+0x98 (7fffabba0358) [onecoreuap\windows\dxaml\xcp\dxaml\lib\JoltClasses.h @ 995] Windows_UI_Xaml!CommonBrowserHost::CLR_FireEvent+0x6d1 (7fffaba196c1) [onecoreuap\windows\dxaml\xcp\control\common\shared\CommonBrowserHost.hpp @ 771] Windows_UI_Xaml!CControlBase::ScriptCallback+0x18b (7fffabe1159b) [onecoreuap\windows\dxaml\xcp\control\common\shared\controlbase.cpp @ 267] Windows_UI_Xaml!CXcpDispatcher::OnScriptCallback+0x230 (7fffabbdee10) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1376] Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x77c (7fffabbdfdac) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 844] user32!UserCallWinProcCheckWow+0x2ba (7fffc5f6696a) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 281] user32!DispatchClientMessage+0x9c (7fffc5f663dc) [clientcore\windows\core\ntuser\client\daytona\objfre\amd64\client.cxx @ 3156] user32!__fnDWORD+0x3d (7fffc5f8da4d) [onecoreuap\restricted\windows\inc\ntuser\inc\ntcb.h @ 1214] ntdll!KiUserCallbackDispatcherContinue (7fffc81b38c4) [minkernel\ntos\rtl\amd64\trampoln.asm @ 607] win32u!ZwUserMessageCall+0x14 (7fffc5771584) [onecoreuap\windows\core\umode\moderncore\objfre\amd64\usrstubs.asm @ 197] user32!SendMessageWorker+0x1f2 (7fffc5f65bc2) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 661] user32!SendMessageW+0x43 (7fffc5f63433) [onecoreuap\restricted\windows\inc\private\core\ntuser\client\cltxt.h @ 789] Windows_UI_Xaml!CXcpBrowserHost::SyncScriptCallbackRequest+0x13b (7fffaba9388b) [onecoreuap\windows\dxaml\xcp\host\win\browserdesktop\winbrowserhost.cpp @ 1048] Windows_UI_Xaml!CEventManager::RaiseHelper+0x1c2 (7fffabbf98f2) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 1068] Windows_UI_Xaml!CEventManager::RaiseLoadedEventForObject+0xe0 (7fffabb10e4c) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 712] Windows_UI_Xaml!CEventManager::RaiseLoadedEvent+0x1ab (7fffabb10b8b) [onecoreuap\windows\dxaml\xcp\core\dll\eventmgr.cpp @ 772] Windows_UI_Xaml!CCoreServices::NWDrawTree+0x252b (7fffabb0272b) [onecoreuap\windows\dxaml\xcp\core\dll\xcpcore.cpp @ 6379] Windows_UI_Xaml!CXcpBrowserHost::OnTick+0x1bf (7fffabaffd6f) [onecoreuap\windows\dxaml\xcp\host\win\browserdesktop\winbrowserhost.cpp @ 545] Windows_UI_Xaml!CXcpDispatcher::Tick+0x152 (7fffabbde972) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1478] Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x4f3 (7fffabbdfb23) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 841] Windows_UI_Xaml!CXcpDispatcher::MessageTimerCallbackStatic+0x81 (7fffabe9b6e1) [onecoreuap\windows\dxaml\xcp\win\shared\xcpwindow.cpp @ 1555] CoreMessaging!CFlat::SehSafe::Execute<<lambda_654db17c35df07198786f0867aa10de6> >+0x2c (7fffc249208c) [CFlatCorlib\1.0.220606003\CFlatCorlib\SehSafe.inl @ 11] CoreMessaging!Microsoft::CoreUI::Dispatch::TimeoutHandler::ImportAdapter$+0xb1 (7fffc2491f91) [mincore\CoreUI\Dev\System\Dispatch\TimeoutHandler.cs @ 16] CoreMessaging!Microsoft::CoreUI::Dispatch::TimeoutManager::Callback_OnDispatch+0x2d0 (7fffc249ca40) [mincore\CoreUI\Dev\System\Dispatch\TimeoutManager.cs @ 229] CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0x43b (7fffc249bb7b) [mincore\CoreUI\Dev\System\Dispatch\EventLoop.cs @ 689] CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch+0x36b (7fffc249899b) [mincore\CoreUI\Dev\System\Dispatch\UserAdapter.cs @ 1389] CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::DoWork+0x201 (7fffc24984d1) [mincore\coreui\dev\system\Dispatch\UserAdapterCommonN.cpp @ 610] CoreMessaging!Microsoft::CoreUI::Dispatch::UserAdapter::WindowProc+0x4d (7fffc249788d) [mincore\coreui\dev\system\Dispatch\UserAdapterCommonN.cpp @ 415] user32!UserCallWinProcCheckWow+0x2ba (7fffc5f6696a) [clientcore\windows\core\ntuser\client\clmsg.cxx @ 281] user32!DispatchClientMessage+0x9c (7fffc5f663dc) [clientcore\windows\core\ntuser\client\daytona\objfre\amd64\client.cxx @ 3156] user32!__fnDWORD+0x3d (7fffc5f8da4d) [onecoreuap\restricted\windows\inc\ntuser\inc\ntcb.h @ 1214] ntdll!KiUserCallbackDispatcherContinue (7fffc81b38c4) [minkernel\ntos\rtl\amd64\trampoln.asm @ 607] win32u!ZwUserGetMessage+0x14 (7fffc5771564) [onecoreuap\windows\core\umode\moderncore\objfre\amd64\usrstubs.asm @ 189] user32!GetMessageW+0x2a (7fffc5f8e25a) [onecoreuap\restricted\windows\inc\private\core\ntuser\client\ntcftxt.h @ 537] WindowsTerminal!WindowThread::WindowProc+0x8d (7ff713d0fa0d) [D:\dev\private\OpenConsole\src\cascadia\WindowsTerminal\WindowThread.cpp @ 85] WindowsTerminal!`WindowThread::Start'::`2'::<lambda_1>::operator (7ff713d0fe92) [D:\dev\private\OpenConsole\src\cascadia\WindowsTerminal\WindowThread.cpp @ 29] WindowsTerminal!std::invoke<`WindowThread::Start'::`2'::<lambda_1> >+0x20 (7ff713d11690) [C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.33.31517\include\type_traits @ 1537] WindowsTerminal!std::thread::_Invoke<std::tuple<`WindowThread::Start'::`2'::<lambda_1> >,0>+0x82 (7ff713d110d2) [C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.33.31517\include\thread @ 56] ucrtbased!thread_start<unsigned int (7fff5d7e3010) [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 97] KERNEL32!BaseThreadInitThunk+0x1d (7fffc626292d) [clientcore\base\win32\client\thread.c @ 75] ntdll!RtlUserThreadStart+0x28 (7fffc815ef48) [minkernel\ntdll\rtlstrt.c @ 1192] ========================= @$xamlstowed() : 1 ErrorContexts length : 0x1 [0x0] : 0x182041d3200 : 0x8001010e in Windows_UI_Xaml!DirectUI::UIElementGenerated::InvalidateMeasure+0x7c [Type: ErrorContext *] ``` </details> These look sus: ``` BreadcrumbBarItem::InstantiateFlyout BreadcrumbBarItem::SetPropertiesForEllipsisItem BreadcrumbBarItem::OnLoadedEvent ``` Oh dear * MSFT:43636600 * MSFT:43572798 * MSFT:43610406 * MSFT:43536247 <--- * MSFT:40838551 <--- Oh NOOOOO https://github.com/microsoft/microsoft-ui-xaml/issues/7283 > BreadcrumbBar causes "interface marshalled for different thread" crash in WinUI 2.7.1 (UWP)
claunia commented 2026-01-31 06:44:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 6, 2023):

"I went into settings to turn on the tray icon, and it crashed when I hit Save."

This was a good bug in code I wrote. There was a race between the WindowEmperor asking each window if they wanted the tray icon, and each window actually updating its own settings to know that. It would also result in a lag between toggling that setting and the icon reflecting that state - the icon wouldn't (dis)appear until the number of windows changed (and forced the emperor to re-ask if anyone wants it)

fixed in 35c7474ab

@zadjii-msft commented on GitHub (Mar 6, 2023): ## "I went into settings to turn on the tray icon, and it crashed when I hit Save." This was a good bug in code I wrote. There was a race between the WindowEmperor asking each window if they wanted the tray icon, and each window actually updating its own settings to know that. It would also result in a lag between toggling that setting and the icon reflecting that state - the icon wouldn't (dis)appear until the number of windows changed (and forced the emperor to re-ask if anyone wants it) fixed in 35c7474ab
claunia commented 2026-01-31 06:44:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 9, 2023):

"Another curious A/V crash when hot-reloading, with a null Dispatcher?"

I hit this on 1dc243641, even after I thought I fixed the one above. Dustin's got some similar crash dumps coming from his machine.

Stack 
 	TerminalApp.dll!winrt::impl::consume_Windows_UI_Core_ICoreDispatcher<winrt::Windows::UI::Core::ICoreDispatcher>::RunAsync(const winrt::Windows::UI::Core::CoreDispatcherPriority & priority, const winrt::Windows::UI::Core::DispatchedHandler & agileCallback) Line 190	C++
 	TerminalApp.dll!wil::details::dispatcher_RunAsync::Schedule<winrt::Windows::UI::Core::CoreDispatcher,enum winrt::Windows::UI::Core::CoreDispatcherPriority const &,winrt::Windows::UI::Core::DispatchedHandler &>(const winrt::Windows::UI::Core::CoreDispatcher & dispatcher, const winrt::Windows::UI::Core::CoreDispatcherPriority & <args_0>, winrt::Windows::UI::Core::DispatchedHandler & <args_1>) Line 25	C++
 	TerminalApp.dll!`wil::resume_foreground<winrt::Windows::UI::Core::CoreDispatcher>'::`2'::awaitable::await_suspend(std::coroutine_handle<void> handle) Line 130	C++
 	TerminalApp.dll!winrt::TerminalApp::implementation::TerminalWindow::UpdateSettings(winrt::TerminalApp::SettingsLoadEventArgs args) Line 755	C++
 	[External Code]	
 	TerminalApp.dll!winrt::TerminalApp::implementation::TerminalWindow::UpdateSettingsHandler(const winrt::Windows::Foundation::IInspectable & __formal, const winrt::TerminalApp::SettingsLoadEventArgs & args) Line 1147	C++
 	TerminalApp.dll!`winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs><winrt::TerminalApp::implementation::TerminalWindow,void (__cdecl winrt::TerminalApp::implementation::TerminalWindow::*)(winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &)>'::`1'::<lambda_460_>::operator()<winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &>(const winrt::Windows::Foundation::IInspectable & <args_0>, const winrt::TerminalApp::SettingsLoadEventArgs & <args_1>) Line 2520	C++
 	TerminalApp.dll!winrt::impl::delegate<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>,`winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::implementation<winrt::TerminalApp::implementation::TerminalWindow,void (__cdecl winrt::TerminalApp::implementation::TerminalWindow::*)(winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &)>'::`1'::<lambda_460_>>::Invoke(void * sender, void * args) Line 895	C++
 	TerminalApp.dll!winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::operator()(const winrt::Windows::Foundation::IInspectable & sender, const winrt::TerminalApp::SettingsLoadEventArgs & args) Line 2525	C++
 	TerminalApp.dll!winrt::impl::invoke<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>,winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::implementation::SettingsLoadEventArgs>(const winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs> & delegate, const winrt::TerminalApp::implementation::AppLogic & <args_0>, const winrt::TerminalApp::implementation::SettingsLoadEventArgs & <args_1>) Line 5890	C++
 	TerminalApp.dll!winrt::event<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>>::operator()<winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::implementation::SettingsLoadEventArgs>(const winrt::TerminalApp::implementation::AppLogic & <args_0>, const winrt::TerminalApp::implementation::SettingsLoadEventArgs & <args_1>) Line 6043	C++
 	TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::ReloadSettings() Line 526	C++
 	TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::{ctor}::__l2::<lambda_1>::operator()() Line 136	C++
 	[External Code]	
 	TerminalApp.dll!ThrottledFunc<0>::_trailing_edge::__l3::<lambda_1>::operator()() Line 116	C++
 	TerminalApp.dll!winrt::impl::delegate<winrt::Windows::System::DispatcherQueueHandler,`ThrottledFunc<0>::_trailing_edge'::`3'::<lambda_1>>::Invoke() Line 1623	C++
 	[External Code]	
>	WindowsTerminal.exe!WindowEmperor::WaitForWindows() Line 110	C++
 	WindowsTerminal.exe!wWinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, wchar_t * __formal, int __formal) Line 122	C++
 	[External Code]
  • The Emperor has no windows left in _windows
  • We're in AppLogic::ReloadSettings, and raised SettingsChanged, which got over to the TerminalWindow, which seemed not to have a root->Dispatcher()
  • This raises an interesting question - did something else already crash the Terminal, but we're only hitting it now? Was there no Terminal window running when I hit this? I thought there was one...
  • There was no Window Thread left running!
  • perhaps - something kept the TerminalWindow alive, even though the Thread had dtor'd. There's an outstanding strong ref, so that the weak ref set up up AppLogic::CreateNewWindow does successfully evaluate to a living TerminalWindow instance, but when we get to the TerminalPage, it doesn't have a dispatcher anymore, cause this thread's XAML was torn down.

Oh wait no I must have done something dumb in the last couple commits - app doesn't tear down on closing the last window anymore 🤦

WOWOWOWOWWOWOWOWOWOLWOW TIL that this is LOAD BEARING
6e4b2e104

public std::enable_shared_from_this<WindowEmperor>

public

If you don't public, then when you weak_from_this, you'll just get an empty ptr.

@zadjii-msft commented on GitHub (Mar 9, 2023): ### "Another curious A/V crash when hot-reloading, with a null Dispatcher?" I hit this on `1dc243641`, even after I thought I fixed the one above. Dustin's got some similar crash dumps coming from his machine. <details> <summary>Stack</summary> ``` TerminalApp.dll!winrt::impl::consume_Windows_UI_Core_ICoreDispatcher<winrt::Windows::UI::Core::ICoreDispatcher>::RunAsync(const winrt::Windows::UI::Core::CoreDispatcherPriority & priority, const winrt::Windows::UI::Core::DispatchedHandler & agileCallback) Line 190 C++ TerminalApp.dll!wil::details::dispatcher_RunAsync::Schedule<winrt::Windows::UI::Core::CoreDispatcher,enum winrt::Windows::UI::Core::CoreDispatcherPriority const &,winrt::Windows::UI::Core::DispatchedHandler &>(const winrt::Windows::UI::Core::CoreDispatcher & dispatcher, const winrt::Windows::UI::Core::CoreDispatcherPriority & <args_0>, winrt::Windows::UI::Core::DispatchedHandler & <args_1>) Line 25 C++ TerminalApp.dll!`wil::resume_foreground<winrt::Windows::UI::Core::CoreDispatcher>'::`2'::awaitable::await_suspend(std::coroutine_handle<void> handle) Line 130 C++ TerminalApp.dll!winrt::TerminalApp::implementation::TerminalWindow::UpdateSettings(winrt::TerminalApp::SettingsLoadEventArgs args) Line 755 C++ [External Code] TerminalApp.dll!winrt::TerminalApp::implementation::TerminalWindow::UpdateSettingsHandler(const winrt::Windows::Foundation::IInspectable & __formal, const winrt::TerminalApp::SettingsLoadEventArgs & args) Line 1147 C++ TerminalApp.dll!`winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs><winrt::TerminalApp::implementation::TerminalWindow,void (__cdecl winrt::TerminalApp::implementation::TerminalWindow::*)(winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &)>'::`1'::<lambda_460_>::operator()<winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &>(const winrt::Windows::Foundation::IInspectable & <args_0>, const winrt::TerminalApp::SettingsLoadEventArgs & <args_1>) Line 2520 C++ TerminalApp.dll!winrt::impl::delegate<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>,`winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::implementation<winrt::TerminalApp::implementation::TerminalWindow,void (__cdecl winrt::TerminalApp::implementation::TerminalWindow::*)(winrt::Windows::Foundation::IInspectable const &,winrt::TerminalApp::SettingsLoadEventArgs const &)>'::`1'::<lambda_460_>>::Invoke(void * sender, void * args) Line 895 C++ TerminalApp.dll!winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>::operator()(const winrt::Windows::Foundation::IInspectable & sender, const winrt::TerminalApp::SettingsLoadEventArgs & args) Line 2525 C++ TerminalApp.dll!winrt::impl::invoke<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>,winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::implementation::SettingsLoadEventArgs>(const winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs> & delegate, const winrt::TerminalApp::implementation::AppLogic & <args_0>, const winrt::TerminalApp::implementation::SettingsLoadEventArgs & <args_1>) Line 5890 C++ TerminalApp.dll!winrt::event<winrt::Windows::Foundation::TypedEventHandler<winrt::Windows::Foundation::IInspectable,winrt::TerminalApp::SettingsLoadEventArgs>>::operator()<winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::implementation::SettingsLoadEventArgs>(const winrt::TerminalApp::implementation::AppLogic & <args_0>, const winrt::TerminalApp::implementation::SettingsLoadEventArgs & <args_1>) Line 6043 C++ TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::ReloadSettings() Line 526 C++ TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::{ctor}::__l2::<lambda_1>::operator()() Line 136 C++ [External Code] TerminalApp.dll!ThrottledFunc<0>::_trailing_edge::__l3::<lambda_1>::operator()() Line 116 C++ TerminalApp.dll!winrt::impl::delegate<winrt::Windows::System::DispatcherQueueHandler,`ThrottledFunc<0>::_trailing_edge'::`3'::<lambda_1>>::Invoke() Line 1623 C++ [External Code] > WindowsTerminal.exe!WindowEmperor::WaitForWindows() Line 110 C++ WindowsTerminal.exe!wWinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, wchar_t * __formal, int __formal) Line 122 C++ [External Code] ``` </details> * The Emperor has _no_ windows left in `_windows` * We're in `AppLogic::ReloadSettings`, and raised `SettingsChanged`, which got over to the `TerminalWindow`, which seemed not to have a `root->Dispatcher()` * This raises an interesting question - did something else already crash the Terminal, but we're only hitting it now? Was there no Terminal window running when I hit this? I thought there was one... * There was no Window Thread left running! * perhaps - something kept the `TerminalWindow` alive, even though the `Thread` had dtor'd. There's an outstanding strong ref, so that the weak ref set up up `AppLogic::CreateNewWindow` does successfully evaluate to a living `TerminalWindow` instance, but when we get to the TerminalPage, it doesn't have a dispatcher anymore, cause this thread's XAML was torn down. Oh wait no I must have done something dumb in the last couple commits - app doesn't tear down on closing the last window anymore 🤦 WOWOWOWOWWOWOWOWOWOLWOW TIL that this is LOAD BEARING 6e4b2e104 `public std::enable_shared_from_this<WindowEmperor>` `public` If you don't `public`, then when you `weak_from_this`, you'll just get an empty ptr.
claunia commented 2026-01-31 06:44:58 +00:00
Author
Owner
Copy Link

@ForbiddenEra commented on GitHub (Mar 18, 2023):

This is a feature I've been wanting for a while; I'd be happy to give it a test if possible and see if I run into any issues.. However, I'm not quite eager enough to do anything such as building the sources myself. If there's any sort of Beta/RC containing this feature, that'd be great - I already am running the Preview build however.

I do use quite a few screens with multiple dGPUs+iGPU, fancy-zones and such, not sure if my setup would be considered any more trying towards testing (eg. dragging tabs onto other screens, across different GPUs or dropping right into a fancyzone or something - I've seen issues w/other things like browsers handling this in the past though it seems like most of those issues have been solved in those apps)

Otherwise, I'll just thank everyone for their hard work and wait for it to drop and test it then and hopefully not have to report any issues.

:)

@ForbiddenEra commented on GitHub (Mar 18, 2023): This is a feature I've been wanting for a while; I'd be happy to give it a test if possible and see if I run into any issues.. However, I'm not quite eager enough to do anything such as building the sources myself. If there's any sort of Beta/RC containing this feature, that'd be great - I already am running the `Preview` build however. I do use quite a few screens with multiple dGPUs+iGPU, fancy-zones and such, not sure if my setup would be considered any more trying towards testing (eg. dragging tabs onto other screens, across different GPUs or dropping right into a fancyzone or something - I've seen issues w/other things like browsers handling this in the past though it seems like most of those issues have been solved in those apps) Otherwise, I'll just **thank everyone for their hard work** and wait for it to drop and test it then and hopefully not have to report any issues. :)
claunia commented 2026-01-31 06:44:59 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 31, 2023):

Dustin's thing about content

Spawned from this discussion:
https://github.com/microsoft/terminal/pull/14935#discussion_r1153767035

Okay, I think I get it. If we can associate the Content directly (or the content tree) with the DataPackage, we no longer need to stash anything. We could probably also completely get rid of ContentIds and ContentManager (!).
Here's why I think that. It looks like you do always get a datapackage or a tab sender. Therefore, you can check the datapackage, read the source window, if it's the same don't detach anything. If it's different, ask the content tree to bubble a detach up to its original hosting window. detach remains driven recipient-side

@zadjii-msft commented on GitHub (Mar 31, 2023): ### Dustin's thing about content Spawned from this discussion: https://github.com/microsoft/terminal/pull/14935#discussion_r1153767035 > Okay, I think I get it. If we can associate the Content directly (or the content tree) with the DataPackage, we no longer need to stash anything. We could probably also completely get rid of ContentIds and ContentManager (!). > Here's why I think that. It looks like you do always get a datapackage or a tab sender. Therefore, you can check the datapackage, read the source window, if it's the same don't detach anything. If it's different, ask the content tree to bubble a detach up to its original hosting window. detach remains driven recipient-side
claunia commented 2026-01-31 06:44:59 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 4, 2023):

  • If we tear out the only tab in a window, to a new window, can we just... move the window there? ;D
@DHowett commented on GitHub (Apr 4, 2023): - [ ] If we tear out the only tab in a window, to a new window, can we just... move the window there? ;D
claunia commented 2026-01-31 06:44:59 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 4, 2023):

(silmarillion) moving a tab to a larger window doesn't resize the control

weirdly, it does resize SOMETHING. midnight commander is window-sized, and mouse events are the right size/position too.

Maybe a little more complicated than not sizing the control

@DHowett commented on GitHub (Apr 4, 2023): > (silmarillion) moving a tab to a larger window doesn't resize the control weirdly, it does resize SOMETHING. midnight commander is window-sized, and mouse events are the right size/position too. Maybe a little more complicated than not sizing the control
claunia commented 2026-01-31 06:45:00 +00:00
Author
Owner
Copy Link

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

tear-out-mc-000

So I don't know how folks are reproing this

@zadjii-msft commented on GitHub (Apr 4, 2023): ![tear-out-mc-000](https://user-images.githubusercontent.com/18356694/229902891-1bef723d-af17-4f6b-a4ab-d791dd53be35.gif) So I don't know how folks are reproing this
claunia commented 2026-01-31 06:45:01 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 4, 2023):

so weird! I just repro'd it on 931.

msedge_2GvscJrmrS

@DHowett commented on GitHub (Apr 4, 2023): so weird! I just repro'd it on 931. ![msedge_2GvscJrmrS](https://user-images.githubusercontent.com/189190/229904713-68126004-f0f1-49c3-98e1-c017ad24aed0.gif)
claunia commented 2026-01-31 06:45:01 +00:00
Author
Owner
Copy Link

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

I bet there's some amount of atlas-y-ness that I'm missing between the two of us

@zadjii-msft commented on GitHub (Apr 4, 2023): I bet there's some amount of atlas-y-ness that I'm missing between the two of us
claunia commented 2026-01-31 06:45:02 +00:00
Author
Owner
Copy Link

@Link1J commented on GitHub (Apr 5, 2023):

"Opening settings in two windows at the same time causes a crash" isn't the right description of the bug, because I have been able to replicate the bug in two other ways, and both only need one settings tab open. The first I found was by draging the setting tab out so that it spawns a new window. The second way I found was draging a setting tab between two windows.

So it may a problem with how BreadcrumbBarItem handles multiple Windows existing. But I don't know how the tab tear-out is implemented, so it could be that two settings tabs are spawns in both those cases, but I thought I would mention these new ways of replicating the bug.

@Link1J commented on GitHub (Apr 5, 2023): "Opening settings in two windows at the same time causes a crash" isn't the right description of the bug, because I have been able to replicate the bug in two other ways, and both only need one settings tab open. The first I found was by draging the setting tab out so that it spawns a new window. The second way I found was draging a setting tab between two windows. So it may a problem with how `BreadcrumbBarItem` handles multiple Windows existing. But I don't know how the tab tear-out is implemented, so it could be that two settings tabs are spawns in both those cases, but I thought I would mention these new ways of replicating the bug.
claunia commented 2026-01-31 06:45:03 +00:00
Author
Owner
Copy Link

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

@Link1J Yep, that's all the same thing. Basically, you can't instantiate a BreadcrumbBar on two threads in the same process. That's been fixed upstream, we're just waiting for a new package to be able to ingest.

@zadjii-msft commented on GitHub (Apr 5, 2023): @Link1J Yep, that's all the same thing. Basically, you can't instantiate a BreadcrumbBar on two threads in the same process. That's been fixed upstream, we're just waiting for a new package to be able to ingest.
claunia commented 2026-01-31 06:45:04 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 6, 2023):

(silmarillion) moving a tab to a larger window doesn't resize the control

weirdly, it does resize SOMETHING. midnight commander is window-sized, and mouse events are the right size/position too.

Maybe a little more complicated than not sizing the control

@lhecker Dustin and I just retried this thread, and it only seemed to repro with the Atlas engine enabled on 1.18.931.0. Dunno if it repros on newer builds of Atlas.

Just thought I'd let you know 😉

@zadjii-msft commented on GitHub (Apr 6, 2023): > > (silmarillion) moving a tab to a larger window doesn't resize the control > > weirdly, it does resize SOMETHING. midnight commander is window-sized, and mouse events are the right size/position too. > > Maybe a little more complicated than not sizing the control @lhecker Dustin and I just retried this thread, and it only seemed to repro with the Atlas engine enabled on 1.18.931.0. Dunno if it repros on newer builds of Atlas. Just thought I'd let you know 😉
claunia commented 2026-01-31 06:45:04 +00:00
Author
Owner
Copy Link

@ForbiddenEra commented on GitHub (Apr 8, 2023):

tear-out-mc-000

ooOOoooOOoo that looks noice!

keep up the good work everyone!!

@ForbiddenEra commented on GitHub (Apr 8, 2023): > ![tear-out-mc-000](https://user-images.githubusercontent.com/18356694/229902891-1bef723d-af17-4f6b-a4ab-d791dd53be35.gif) ooOOoooOOoo that looks noice! keep up the good work everyone!!
claunia commented 2026-01-31 06:45:05 +00:00
Author
Owner
Copy Link

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

FYI When I'm using the current main branch as my default terminal and run a very short-lived console application (like a printf("hello world") kind of application) via F5 in Visual Studio, the window will sometimes just instantly vanish again. It'll then just exist invisibly:
image

@lhecker commented on GitHub (Apr 19, 2023): FYI When I'm using the current main branch as my default terminal and run a very short-lived console application (like a `printf("hello world")` kind of application) via F5 in Visual Studio, the window will sometimes just instantly vanish again. It'll then just exist invisibly: ![image](https://user-images.githubusercontent.com/2256941/233198939-0c18904a-a360-483f-81c8-3f9333ed3632.png)
claunia commented 2026-01-31 06:45:05 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 24, 2023):

MSFT:43995981 - the _checkWindowsForNotificationIcon one

Looking at a dump, the crash is due to a race.

  • A window [A] is created. It lives its life.
  • [A] starts dying.
    • It dtors the AppHost
    • It releases its Logic() member.
  • At this moment, a new Terminal process starts.
    • this causes a ProposeCommandline in the emperor process.
    • This causes the monarch to create a new peasant for the new window.
    • This causes the monarch to raise its _WindowCreatedHandlers.
    • This gets into WindowEmperor::_checkWindowsForNotificationIcon.
    • This takes the _windows lock.
  • Thread A resumes.
    • [A] falls out the bottom of RunMessagePump
    • The cleanup triggers _windowExitedHandler
    • It attempts to lock _windows to remove itself.
  • The RPC thread (that's creating the new peasant) resumes.
    • It tries to get at the _windowThread->Logic(), but oh dear, the AppHost has already dtor'd.
@zadjii-msft commented on GitHub (Apr 24, 2023): ### MSFT:43995981 - the `_checkWindowsForNotificationIcon` one Looking at a dump, the crash is due to a race. * A window [A] is created. It lives its life. * [A] starts dying. * It dtors the `AppHost` * It releases its `Logic()` member. * At this moment, a new Terminal process starts. * this causes a `ProposeCommandline` in the emperor process. * This causes the monarch to create a new peasant for the new window. * This causes the monarch to raise its `_WindowCreatedHandlers`. * This gets into `WindowEmperor::_checkWindowsForNotificationIcon`. * This takes the `_windows` lock. * Thread A resumes. * [A] falls out the bottom of `RunMessagePump` * The cleanup triggers `_windowExitedHandler` * It attempts to lock `_windows` to remove itself. * The RPC thread (that's creating the new peasant) resumes. * It tries to get at the `_windowThread->Logic()`, but oh dear, the `AppHost` has already dtor'd.
claunia commented 2026-01-31 06:45:05 +00:00
Author
Owner
Copy Link

@ForbiddenEra commented on GitHub (Jun 16, 2023):

omgomgomg I just tried tab tear out after a recent update andddddddddd it works!!!!!! finally! so glad to have this feature.

<3 <3 for your hard works!!

@ForbiddenEra commented on GitHub (Jun 16, 2023): omgomgomg I just tried tab tear out after a recent update andddddddddd it works!!!!!! finally! so glad to have this feature. <3 <3 for your hard works!!
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-Remoting Area-Settings Area-TerminalControl Area-UserInterface Area-Windowing Issue-Task 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#19490
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?