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

FailFastException on startup when running in the debugger #19670

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

Originally created by @j4james on GitHub (Apr 8, 2023).

Windows Terminal version

Commit ea44375f6d

Windows build number

10.0.19045.2728

Other Software

No response

Steps to reproduce

  1. To reproduce this, I think you must be running from within the debugger.
  2. I started with a blank settings file to make sure the issue wasn't dependent on any other settings, but that may not be necessary.
  3. After restarting with the defaults, open the Settings and change the launch size to 80x24, then Save and restart again, so that's the actual terminal window size.
  4. Open the Settings and change "When Terminal starts" to "Open windows from a previous session", Save that change, but leave the Settings tab open.
  5. Close the first shell tab that opened by default, but then open another shell, so you should have two tabs: the Settings tab following by a shell tab.
  6. Close the terminal and then restart it.

Expected Behavior

It should open successfully with the previously saved state.

Actual Behavior

The debugger stops with a popup indicating that an exception has occurred:

Unhandled exception at 0x00007FFAD7C3FD12 (KernelBase.dll) in WindowsTerminal.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x0000020A2A5BEA40, 0x0000000000000002).

Stack Trace 
    KernelBase.dll!RaiseFailFastException()	Unknown
    combase.dll!RoFailFastWithErrorContextInternal2(HRESULT hrError, unsigned long cStowedExceptions, _STOWED_EXCEPTION_INFORMATION_V2 * * aStowedExceptionPointers) Line 1455	C++
    Windows.UI.Xaml.dll!DirectUI::ErrorHelper::ProcessUnhandledError(DirectUI::ErrorInfo & errorInfo, unsigned int fSkipFailFastIfNoErrorContext, unsigned int * pfHandled) Line 616	C++
    Windows.UI.Xaml.dll!DirectUI::ErrorHelper::ReportUnhandledError(HRESULT hrError) Line 502	C++
    Windows.UI.Xaml.dll!CCoreServices::CLR_FireEvent(CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, unsigned int flags) Line 3231	C++
    Windows.UI.Xaml.dll!CommonBrowserHost::CLR_FireEvent(CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, unsigned int flags) Line 771	C++
    Windows.UI.Xaml.dll!CControlBase::ScriptCallback(void * pControl, CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, int flags, IScriptObject * pScriptObject, HRESULT(*)(CDependencyObject *, CEventArgs *) pInternalHandler) Line 267	C++
    [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::OnScriptCallback(CEventInfo *) Line 1338	C++
    Windows.UI.Xaml.dll!CXcpDispatcher::OnWindowMessage(HWND__ * msg, unsigned int wParam, unsigned __int64 lParam, __int64) Line 1092	C++
    [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::ProcessMessage(HWND__ *) Line 911	C++
    Windows.UI.Xaml.dll!CXcpDispatcher::WindowProc(HWND__ * hwnd, unsigned int msg, unsigned __int64 wParam, __int64 lParam) Line 842	C++
    Windows.UI.Xaml.dll!CDeferredInvoke::DispatchQueuedMessage(bool * dispatchedWork, bool * hasMoreWork) Line 301	C++
    [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::MessageTimerCallback() Line 1534	C++
    Windows.UI.Xaml.dll!CXcpDispatcher::MessageTimerCallbackStatic(void * myUserData) Line 1526	C++
    CoreMessaging.dll!Microsoft__CoreUI__Dispatch__TimeoutHandler$CallbackThunk(class System::Delegate *)	Unknown
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::TimeoutManager::Callback_OnDispatch()	Unknown
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop(struct Microsoft::CoreUI::Dispatch::RunMode,bool,bool &)	Unknown
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch()	Unknown
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_DoWork()	Unknown
    CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc(struct HWND__ *,unsigned int,unsigned __int64,__int64)	Unknown
    user32.dll!UserCallWinProcCheckWow()	Unknown
    user32.dll!DispatchClientMessage()	Unknown
    user32.dll!__fnDWORD()	Unknown
    ntdll.dll!KiUserCallbackDispatcherContinue()	Unknown
    win32u.dll!NtUserGetMessage()	Unknown
    user32.dll!GetMessageW()	Unknown
>   WindowsTerminal.exe!WindowThread::RunMessagePump() Line 38	C++
    WindowsTerminal.exe!WindowEmperor::_createNewWindowThread::__l2::<lambda_1>::operator()() Line 149	C++
    [External Code]

But if I tell the debugger to Continue a few times, it'll eventually startup successfully, so whatever is going wrong here can't be that serious.

Also if I start the Dev build from outside the debugger, then isn't anything obviously failing.

If you can't reproduce this, note that I'm still on Windows 10, so that might be a factor.

Originally created by @j4james on GitHub (Apr 8, 2023). ### Windows Terminal version Commit ea44375f6dcdfb3c8bdf05b2f02e38a72d2dde09 ### Windows build number 10.0.19045.2728 ### Other Software _No response_ ### Steps to reproduce 1. To reproduce this, I think you must be running from within the debugger. 2. I started with a blank settings file to make sure the issue wasn't dependent on any other settings, but that may not be necessary. 3. After restarting with the defaults, open the _Settings_ and change the launch size to 80x24, then _Save_ and restart again, so that's the actual terminal window size. 3. Open the _Settings_ and change "When Terminal starts" to "Open windows from a previous session", _Save_ that change, but leave the _Settings_ tab open. 4. Close the first shell tab that opened by default, but then open another shell, so you should have two tabs: the _Settings_ tab following by a shell tab. 5. Close the terminal and then restart it. ### Expected Behavior It should open successfully with the previously saved state. ### Actual Behavior The debugger stops with a popup indicating that an exception has occurred: > Unhandled exception at 0x00007FFAD7C3FD12 (KernelBase.dll) in WindowsTerminal.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x0000020A2A5BEA40, 0x0000000000000002). <details> <summary>Stack Trace</summary> KernelBase.dll!RaiseFailFastException() Unknown combase.dll!RoFailFastWithErrorContextInternal2(HRESULT hrError, unsigned long cStowedExceptions, _STOWED_EXCEPTION_INFORMATION_V2 * * aStowedExceptionPointers) Line 1455 C++ Windows.UI.Xaml.dll!DirectUI::ErrorHelper::ProcessUnhandledError(DirectUI::ErrorInfo & errorInfo, unsigned int fSkipFailFastIfNoErrorContext, unsigned int * pfHandled) Line 616 C++ Windows.UI.Xaml.dll!DirectUI::ErrorHelper::ReportUnhandledError(HRESULT hrError) Line 502 C++ Windows.UI.Xaml.dll!CCoreServices::CLR_FireEvent(CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, unsigned int flags) Line 3231 C++ Windows.UI.Xaml.dll!CommonBrowserHost::CLR_FireEvent(CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, unsigned int flags) Line 771 C++ Windows.UI.Xaml.dll!CControlBase::ScriptCallback(void * pControl, CDependencyObject * pListener, EventHandle hEvent, CDependencyObject * pSender, CEventArgs * pArgs, int flags, IScriptObject * pScriptObject, HRESULT(*)(CDependencyObject *, CEventArgs *) pInternalHandler) Line 267 C++ [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::OnScriptCallback(CEventInfo *) Line 1338 C++ Windows.UI.Xaml.dll!CXcpDispatcher::OnWindowMessage(HWND__ * msg, unsigned int wParam, unsigned __int64 lParam, __int64) Line 1092 C++ [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::ProcessMessage(HWND__ *) Line 911 C++ Windows.UI.Xaml.dll!CXcpDispatcher::WindowProc(HWND__ * hwnd, unsigned int msg, unsigned __int64 wParam, __int64 lParam) Line 842 C++ Windows.UI.Xaml.dll!CDeferredInvoke::DispatchQueuedMessage(bool * dispatchedWork, bool * hasMoreWork) Line 301 C++ [Inline Frame] Windows.UI.Xaml.dll!CXcpDispatcher::MessageTimerCallback() Line 1534 C++ Windows.UI.Xaml.dll!CXcpDispatcher::MessageTimerCallbackStatic(void * myUserData) Line 1526 C++ CoreMessaging.dll!Microsoft__CoreUI__Dispatch__TimeoutHandler$CallbackThunk(class System::Delegate *) Unknown CoreMessaging.dll!Microsoft::CoreUI::Dispatch::TimeoutManager::Callback_OnDispatch() Unknown CoreMessaging.dll!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop(struct Microsoft::CoreUI::Dispatch::RunMode,bool,bool &) Unknown CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter::OnUserDispatch() Unknown CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_DoWork() Unknown CoreMessaging.dll!Microsoft::CoreUI::Dispatch::UserAdapter_WindowProc(struct HWND__ *,unsigned int,unsigned __int64,__int64) Unknown user32.dll!UserCallWinProcCheckWow() Unknown user32.dll!DispatchClientMessage() Unknown user32.dll!__fnDWORD() Unknown ntdll.dll!KiUserCallbackDispatcherContinue() Unknown win32u.dll!NtUserGetMessage() Unknown user32.dll!GetMessageW() Unknown > WindowsTerminal.exe!WindowThread::RunMessagePump() Line 38 C++ WindowsTerminal.exe!WindowEmperor::_createNewWindowThread::__l2::<lambda_1>::operator()() Line 149 C++ [External Code] </details> But if I tell the debugger to _Continue_ a few times, it'll eventually startup successfully, so whatever is going wrong here can't be that serious. Also if I start the Dev build from outside the debugger, then isn't anything obviously failing. If you can't reproduce this, note that I'm still on Windows 10, so that might be a factor.
claunia added the Issue-BugResolution-ExternalNeeds-Tag-FixProduct-Terminal labels 2026-01-31 06:50:18 +00:00
claunia commented 2026-01-31 06:50:19 +00:00
Author
Owner
Copy Link

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

If it's anything like what I had, it's because of our recent XAML 2.7 -> 2.8 upgrade. It throws an exception because XAML can't find some files and crashes because it occurs in a noexcept function or something. It seems like msbuild just doesn't realize that there's been a nuget change? The only solution I've found is to run git clean -xfd and blow away all temporary files in my repository, because not even a clean build could solve it.

@lhecker commented on GitHub (Apr 9, 2023): If it's anything like what I had, it's because of our recent XAML 2.7 -> 2.8 upgrade. It throws an exception because XAML can't find some files and crashes because it occurs in a `noexcept` function or something. It seems like msbuild just doesn't realize that there's been a nuget change? The only solution I've found is to run `git clean -xfd` and blow away all temporary files in my repository, because not even a clean build could solve it.
claunia commented 2026-01-31 06:50:19 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 9, 2023):

Thanks for the suggestion, but that didn't seem to help. Note that I only get this exception under certain specific conditions. It doesn't seem to occur with larger window sizes, and it doesn't happen if the settings aren't open. That makes me think it can't be a missing file, otherwise I'd expect it to fail every time.

And having done some more experimenting, I don't think the settings tab necessarily has to come first, but it does need to be a background tab, i.e. some other tab must be focused when you close the terminal, so it's opening the settings tab in the background.

@j4james commented on GitHub (Apr 9, 2023): Thanks for the suggestion, but that didn't seem to help. Note that I only get this exception under certain specific conditions. It doesn't seem to occur with larger window sizes, and it doesn't happen if the settings aren't open. That makes me think it can't be a missing file, otherwise I'd expect it to fail every time. And having done some more experimenting, I don't think the settings tab necessarily has to come first, but it does need to be a background tab, i.e. some other tab must be focused when you close the terminal, so it's opening the settings tab in the background.
claunia commented 2026-01-31 06:50:19 +00:00
Author
Owner
Copy Link

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

Is this entirely predicated on having the Settings tab open? This might be that WinUI BreadcrumbBar thing we've been tracking with them. Essentially, you can't instantiate two BreadcrumbBar's on different threads in the same process. More correctly, you can't instantiate one on a different thread than the first thread you created one on. Which now happens for us whenever two windows try to open the SUI 😅

I'll go ping them again to see if we can get the fresh MUX with the fix, and hopefully this just goes away?

@zadjii-msft commented on GitHub (Apr 10, 2023): Is this entirely predicated on having the Settings tab open? This might be that WinUI BreadcrumbBar thing we've been tracking with them. Essentially, you can't instantiate two BreadcrumbBar's on different threads in the same process. More correctly, you can't instantiate one on a different thread than the first thread you created one on. Which now happens for us whenever two windows try to open the SUI 😅 I'll go ping them again to see if we can get the fresh MUX with the fix, and hopefully this just goes away?
claunia commented 2026-01-31 06:50:19 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 10, 2023):

Is this entirely predicated on having the Settings tab open?

Yes. I couldn't reproduce it without a Settings tab.

Essentially, you can't instantiate two BreadcrumbBar's on different threads in the same process. More correctly, you can't instantiate one on a different thread than the first thread you created one on. Which now happens for us whenever two windows try to open the SUI 😅

Unless I've misunderstood something, I don't think this matches my conditions. I've only got one Settings tab, and the terminal is still in the process of opening, so it's not like there have been any others opened prior to that. I don't even have another version of the terminal open.

One thing I've noticed which might be relevant: Once I've continued past all the exception popups, if I view the Settings tab that was opened in the background, the navigation panel seems to be expanded, but it's transparent. This doesn't happen if I open the Settings after the terminal has started up.

image

@j4james commented on GitHub (Apr 10, 2023): > Is this entirely predicated on having the Settings tab open? Yes. I couldn't reproduce it without a _Settings_ tab. > Essentially, you can't instantiate two BreadcrumbBar's on different threads in the same process. More correctly, you can't instantiate one on a different thread than the first thread you created one on. Which now happens for us whenever two windows try to open the SUI 😅 Unless I've misunderstood something, I don't think this matches my conditions. I've only got one _Settings_ tab, and the terminal is still in the process of opening, so it's not like there have been any others opened prior to that. I don't even have another version of the terminal open. One thing I've noticed which might be relevant: Once I've continued past all the exception popups, if I view the _Settings_ tab that was opened in the background, the navigation panel seems to be expanded, but it's transparent. This doesn't happen if I open the _Settings_ after the terminal has started up. ![image](https://user-images.githubusercontent.com/4181424/230940124-3e7ecf8f-5046-4a4b-b68d-c7dcd248c40e.png)
claunia commented 2026-01-31 06:50:20 +00:00
Author
Owner
Copy Link

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

Okay, so I got this to repro after finally getting deploying to a Win10 VM figured out.

The SUI tab had to be inactive, and the window had to be narrow enough that the nav view would normally open in the collapsed state.

Alas, the VS debugger won't let me get at the actual stowed exception. Just this garbage:

REGDB_E_CLASSNOTREG Class not registered

Not really sure what this would be. Only guess is that it's the same thing as the

Exception thrown at 0x00007FF9BF3C4F99 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070057 : 'CommonResources.xaml is not a valid absolute URI.'.
Exception thrown at 0x00007FF9BF3C4F99 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070057 : 'SettingContainerStyle.xaml is not a valid absolute URI.'.

thing we've seen for ages (and doesn't seem actually wrong?)

@zadjii-msft commented on GitHub (Apr 18, 2023): Okay, so I got this to repro after finally getting deploying to a Win10 VM figured out. The SUI tab had to be inactive, and the window had to be narrow enough that the nav view would normally open in the collapsed state. Alas, the VS debugger won't let me get at the actual stowed exception. Just this garbage: ![](https://user-images.githubusercontent.com/18356694/232872959-2ae02bcf-ae79-45fc-99ee-07043f2376c4.png) REGDB_E_CLASSNOTREG Class not registered Not really sure what this would be. Only guess is that it's the same thing as the Exception thrown at 0x00007FF9BF3C4F99 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070057 : 'CommonResources.xaml is not a valid absolute URI.'. Exception thrown at 0x00007FF9BF3C4F99 (KernelBase.dll) in WindowsTerminal.exe: WinRT originate error - 0x80070057 : 'SettingContainerStyle.xaml is not a valid absolute URI.'. thing we've seen for ages (and doesn't _seem_ actually wrong?)
claunia commented 2026-01-31 06:50:20 +00:00
Author
Owner
Copy Link

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

AAAAAAAAND it doesn't repro on Windows 11. Same settings&state, same commit, same debugger, just re-pointed at the local machine -> no failfast. Based on the stack, I'd bet that this was some Windows.UI.Xaml thing that was fixed in the Windows 11 timeframe.

@zadjii-msft commented on GitHub (Apr 18, 2023): AAAAAAAAND it doesn't repro on Windows 11. Same settings&state, same commit, same debugger, just re-pointed at the local machine -> no failfast. Based on the stack, I'd bet that this was some Windows.UI.Xaml thing that was fixed in the Windows 11 timeframe.
claunia commented 2026-01-31 06:50:20 +00:00
Author
Owner
Copy Link

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

I'm gonna close this since it seems like it's something that got fixed by the WinUI team. I really trawled through the internal bug trackers but couldn't find anything like this. I wish I could link it to something specific.

If for whatever reason I'm totally wrong and we get repros on Win11, we can always reactivate.

@zadjii-msft commented on GitHub (Apr 18, 2023): I'm gonna close this since it seems like it's something that got fixed by the WinUI team. I really trawled through the internal bug trackers but couldn't find anything like this. I wish I could link it to something specific. If for whatever reason I'm totally wrong and we get repros on Win11, we can always reactivate.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Tag-Fix Product-Terminal Resolution-External
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#19670
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?