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

Windows Terminal crashing on exit when settings.json is corrupted #18411

New Issue
Closed
opened 2026-01-31 06:13:10 +00:00 by claunia · 17 comments
claunia commented 2026-01-31 06:13:10 +00:00
Owner
Copy Link

Originally created by @levicki on GitHub (Sep 9, 2022).

Originally assigned to: @DHowett on GitHub.

Windows Terminal version

1.14.2281.0

Windows build number

10.0.19044.1949

Other Software

No response

Steps to reproduce

If there is an error in settings.json Windows Terminal will report it on startup:

image

Dismissing the error dialog by clicking the OK button, and then closing the application by any means (clicking [X] in the top right corner or pressing Alt-F4) leads to Just-In-Time debugger being launched (or a crash if you don't have Visual Studio or another debugger installed).

Exception details:

Unhandled exception at 0x00007FFBE890EE0E (Windows.UI.Xaml.dll) in WindowsTerminal.exe: 0xC0000005: Access violation reading location 0x0000000000000130.

Call stack:

 	[Inline Frame] Windows.UI.Xaml.dll!DirectUI::DXamlCore::GetWindow() Line 278	C++
 	Windows.UI.Xaml.dll!DirectUI::ContentDialog::DetachEventHandlersForOpenDialog() Line 2507	C++
 	Windows.UI.Xaml.dll!DirectUI::ContentDialog::~ContentDialog() Line 74	C++
 	Windows.UI.Xaml.dll!ctl::ComObject<DirectUI::ContentDialog>::`scalar deleting destructor'(unsigned int)	C++
 	Windows.UI.Xaml.dll!ctl::ComBase::ReleaseImpl() Line 307	C++
 	[Inline Frame] TerminalApp.dll!winrt::Windows::Foundation::IUnknown::release_ref() Line 2140	C++
 	[Inline Frame] TerminalApp.dll!winrt::Windows::Foundation::IUnknown::{dtor}() Line 2045	C++
>	TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::~AppLogic() Line 57	C++
 	TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::`scalar deleting destructor'(unsigned int)	C++
 	TerminalApp.dll!winrt::implements<winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::AppLogic,winrt::TerminalApp::IDirectKeyListener,winrt::TerminalApp::IDialogPresenter,IInitializeWithWindow>::Release() Line 7859	C++
 	ucrtbase.dll!<lambda>(void)()	Unknown
 	ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda>(void) &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c>>()	Unknown
 	ucrtbase.dll!_execute_onexit_table()	Unknown
 	TerminalApp.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182	C++
 	TerminalApp.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293	C++
 	ntdll.dll!LdrpCallInitRoutine()	Unknown
 	ntdll.dll!LdrShutdownProcess()	Unknown
 	ntdll.dll!RtlExitUserProcess()	Unknown
 	kernel32.dll!ExitProcessImplementation()	Unknown
 	ucrtbase.dll!exit_or_terminate_process()	Unknown
 	ucrtbase.dll!common_exit()	Unknown
 	WindowsTerminal.exe!__scrt_common_main_seh() Line 295	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

Offending settings.json is attached.

I also have a minidump taken with:

procdump.exe -ma -e -x C:\winterm Microsoft.WindowsTerminal_1.14.2281.0_x64__8wekyb3d8bbwe

If there is any way to share it without being publicly visible please let me know, I have it ready for upload.

settings.zip

Expected Behavior

Application should not crash on exit when settings.json is corrupted.

Actual Behavior

Application crashes on exit when settings.json is corrupted.

Originally created by @levicki on GitHub (Sep 9, 2022). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version 1.14.2281.0 ### Windows build number 10.0.19044.1949 ### Other Software _No response_ ### Steps to reproduce If there is an error in `settings.json` Windows Terminal will report it on startup: ![image](https://user-images.githubusercontent.com/16415478/189353671-ea5c28df-c1e7-48ae-aeab-3d38c25c0786.png) Dismissing the error dialog by clicking the OK button, and then closing the application by any means (clicking `[X]` in the top right corner or pressing `Alt-F4`) leads to Just-In-Time debugger being launched (or a crash if you don't have Visual Studio or another debugger installed). **Exception details:** ``` Unhandled exception at 0x00007FFBE890EE0E (Windows.UI.Xaml.dll) in WindowsTerminal.exe: 0xC0000005: Access violation reading location 0x0000000000000130. ``` **Call stack:** ``` [Inline Frame] Windows.UI.Xaml.dll!DirectUI::DXamlCore::GetWindow() Line 278 C++ Windows.UI.Xaml.dll!DirectUI::ContentDialog::DetachEventHandlersForOpenDialog() Line 2507 C++ Windows.UI.Xaml.dll!DirectUI::ContentDialog::~ContentDialog() Line 74 C++ Windows.UI.Xaml.dll!ctl::ComObject<DirectUI::ContentDialog>::`scalar deleting destructor'(unsigned int) C++ Windows.UI.Xaml.dll!ctl::ComBase::ReleaseImpl() Line 307 C++ [Inline Frame] TerminalApp.dll!winrt::Windows::Foundation::IUnknown::release_ref() Line 2140 C++ [Inline Frame] TerminalApp.dll!winrt::Windows::Foundation::IUnknown::{dtor}() Line 2045 C++ > TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::~AppLogic() Line 57 C++ TerminalApp.dll!winrt::TerminalApp::implementation::AppLogic::`scalar deleting destructor'(unsigned int) C++ TerminalApp.dll!winrt::implements<winrt::TerminalApp::implementation::AppLogic,winrt::TerminalApp::AppLogic,winrt::TerminalApp::IDirectKeyListener,winrt::TerminalApp::IDialogPresenter,IInitializeWithWindow>::Release() Line 7859 C++ ucrtbase.dll!<lambda>(void)() Unknown ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda>(void) &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c>>() Unknown ucrtbase.dll!_execute_onexit_table() Unknown TerminalApp.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182 C++ TerminalApp.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293 C++ ntdll.dll!LdrpCallInitRoutine() Unknown ntdll.dll!LdrShutdownProcess() Unknown ntdll.dll!RtlExitUserProcess() Unknown kernel32.dll!ExitProcessImplementation() Unknown ucrtbase.dll!exit_or_terminate_process() Unknown ucrtbase.dll!common_exit() Unknown WindowsTerminal.exe!__scrt_common_main_seh() Line 295 C++ kernel32.dll!BaseThreadInitThunk() Unknown ntdll.dll!RtlUserThreadStart() Unknown ``` Offending `settings.json` is attached. I also have a minidump taken with: ``` procdump.exe -ma -e -x C:\winterm Microsoft.WindowsTerminal_1.14.2281.0_x64__8wekyb3d8bbwe ``` If there is any way to share it without being publicly visible please let me know, I have it ready for upload. [settings.zip](https://github.com/microsoft/terminal/files/9535731/settings.zip) ### Expected Behavior Application should not crash on exit when `settings.json` is corrupted. ### Actual Behavior Application crashes on exit when `settings.json` is corrupted.
claunia added the Issue-BugNeeds-Tag-FixProduct-TerminalPriority-1Severity-Crash labels 2026-01-31 06:13:10 +00:00
claunia commented 2026-01-31 06:13:12 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Sep 11, 2022):

@DHowett could you please take a look at this?

@levicki commented on GitHub (Sep 11, 2022): @DHowett could you please take a look at this?
claunia commented 2026-01-31 06:13:12 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Sep 11, 2022):

I was unable to reproduce this in both 1.14.2282.0 and 1.16.2524.0 on Win11. If anything, this bug might be Win10 specific.

@lhecker commented on GitHub (Sep 11, 2022): I was unable to reproduce this in both 1.14.2282.0 and 1.16.2524.0 on Win11. If anything, this bug might be Win10 specific.
claunia commented 2026-01-31 06:13:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 12, 2022):

Curiously enough, we've seen this before: #11980

Looks like the underlying crash is MSFT:26130824, which is fixed in Windows 11. Based on the fairly low number of hits, and the fact that the crash is only once the app is already exiting, I don't think we'll be able to get that one serviced 😕 Thanks for reporting anyways!

/dup https://task.ms/26130824

@zadjii-msft commented on GitHub (Sep 12, 2022): Curiously enough, we've seen this before: #11980 > Looks like the underlying crash is MSFT:26130824, which is fixed in Windows 11. Based on the fairly low number of hits, and the fact that the crash is only once the app is already exiting, I don't think we'll be able to get that one serviced 😕 Thanks for reporting anyways! > > /dup https://task.ms/26130824
claunia commented 2026-01-31 06:13:12 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 12, 2022):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (Sep 12, 2022): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
claunia commented 2026-01-31 06:13:13 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Sep 12, 2022):

@zadjii-msft

Curiously enough, we've seen this before: #11980

Looks like the underlying crash is MSFT:26130824, which is fixed in Windows 11. Based on the fairly low number of hits, and the fact that the crash is only once the app is already exiting, I don't think we'll be able to get that one serviced 😕 Thanks for reporting anyways!

I have no access to MSFT:26130824 so I have no idea which component is causing the crash. However, if it is fixed in Windows 11 then the fix should be backported to Windows 10 as well because October 14, 2025 is still quite far away, and I am sure Windows Terminal is not the only modern application that might be affected with the underlying issue.

Could you perhaps escalate that internally?

@levicki commented on GitHub (Sep 12, 2022): @zadjii-msft > Curiously enough, we've seen this before: #11980 > > > Looks like the underlying crash is MSFT:26130824, which is fixed in Windows 11. Based on the fairly low number of hits, and the fact that the crash is only once the app is already exiting, I don't think we'll be able to get that one serviced 😕 Thanks for reporting anyways! I have no access to MSFT:26130824 so I have no idea which component is causing the crash. However, if it is fixed in Windows 11 then the fix should be backported to Windows 10 as well because October 14, 2025 is still quite far away, and I am sure Windows Terminal is not the only modern application that might be affected with the underlying issue. Could you perhaps escalate that internally?
claunia commented 2026-01-31 06:13:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 12, 2022):

I've got a line out with the WinUI folks. We'll see, but historically this kind of bug has not met the bar for servicing, especially because it only repros when the application is already closing.

That being said, it's probably 1% of our crashes. So I'd love to tidy that up.

Curiously, I haven't seen any hits of this on 1.15 stable, so maybe it just... went away?

@zadjii-msft commented on GitHub (Sep 12, 2022): I've got a line out with the WinUI folks. We'll see, but historically this kind of bug has not met the bar for servicing, especially because it only repros when the application is _already closing_. That being said, it's probably 1% of our crashes. So I'd love to tidy that up. Curiously, I haven't seen any hits of this on 1.15 stable, so maybe it just... went away?
claunia commented 2026-01-31 06:13:13 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Sep 13, 2022):

@zadjii-msft

I've got a line out with the WinUI folks.

Thanks, I really appreciate it.

...especially because it only repros when the application is already closing.

I wonder if a repro case could be made where that happens in other situations such as during launch or before closing but at a point where the user can lose some data because of it?

Curiously, I haven't seen any hits of this on 1.15 stable, so maybe it just... went away?

So far in my 25 years of writing code I haven't seen any bugs that fixed themselves if you waited long enough unless the problem was caused by something else (bad data, bad hardware, etc). Here's to hoping, but I won't hold my breath.

@levicki commented on GitHub (Sep 13, 2022): @zadjii-msft > I've got a line out with the WinUI folks. Thanks, I really appreciate it. > ...especially because it only repros when the application is already closing. I wonder if a repro case could be made where that happens in other situations such as during launch or before closing but at a point where the user can lose some data because of it? > Curiously, I haven't seen any hits of this on 1.15 stable, so maybe it just... went away? So far in my 25 years of writing code I haven't seen any bugs that fixed themselves if you waited long enough unless the problem was caused by something else (bad data, bad hardware, etc). Here's to hoping, but I won't hold my breath.
claunia commented 2026-01-31 06:13:14 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 2, 2022):

maybe it just... went away?

haven't seen any bugs that fixed themselves

you can probably guess why I'm reopening this . . .

@DHowett commented on GitHub (Nov 2, 2022): > maybe it just... went away? > haven't seen any bugs that fixed themselves you can probably guess why I'm reopening this . . .
claunia commented 2026-01-31 06:13:14 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 2, 2022):

Might be a riff on MSFT:39213339, but there's another internal bug that's marked RI blocking

@zadjii-msft commented on GitHub (Nov 2, 2022): Might be a riff on MSFT:39213339, but there's another internal bug that's marked RI blocking
claunia commented 2026-01-31 06:13:14 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Nov 3, 2022):

you can probably guess why I'm reopening this . . .

It now meets the bar for servicing? :-)

Joking aside, this crash smells like a null pointer dereference in the destructor -- memory location is close to 0 so it looks like an an offset into a vtable of a COM interface. It might be that some initialization is skipped in the constructor when the settings are invalid and there is a null pointer used in the destructor as a result.

@levicki commented on GitHub (Nov 3, 2022): > you can probably guess why I'm reopening this . . . It now meets the bar for servicing? :-) Joking aside, this crash smells like a null pointer dereference in the destructor -- memory location is close to 0 so it looks like an an offset into a vtable of a COM interface. It might be that some initialization is skipped in the constructor when the settings are invalid and there is a null pointer used in the destructor as a result.
claunia commented 2026-01-31 06:13:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 4, 2022):

We might also be a little preemptive in reopening this one. Still tracking down the differences between the report and the RI blocking one.

Should we dedupe this with #13673 maybe? They might be the same. Need more coffee

@zadjii-msft commented on GitHub (Nov 4, 2022): We might also be a little preemptive in reopening this one. Still tracking down the differences between the report and the RI blocking one. Should we dedupe this with #13673 maybe? They might be the same. Need more coffee
claunia commented 2026-01-31 06:13:15 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Nov 8, 2022):

Need more coffee

Ain't that always the case?

@levicki commented on GitHub (Nov 8, 2022): > Need more coffee Ain't that always the case?
claunia commented 2026-01-31 06:13:15 +00:00
Author
Owner
Copy Link

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

Hmm. I can't repro this on Windows 11, on main as of today. That would make sense - the bug we originally pegged as the root cause of this is fixed in Win11.

I honestly have no idea why @DHowett reopened this one. Apparently there was a bug internally that got escalated with a similar root cause, but I can't find it. MSFT:39213339 is the closest I can find, it's about .98% of our crashes, and is firmly a platform bug.

So, I'm gonna need him to come through and tidy this up. If it is a new bug, best to start a new thread to track the separate root cause.

@zadjii-msft commented on GitHub (Jan 6, 2023): Hmm. I can't repro this on Windows 11, on `main` as of today. That would make sense - the bug we originally pegged as the root cause of this is fixed in Win11. I honestly have no idea why @DHowett reopened this one. Apparently there was a bug internally that got escalated with a similar root cause, but I can't find it. MSFT:39213339 is the closest I can find, it's about .98% of our crashes, and is firmly a platform bug. So, I'm gonna need him to come through and tidy this up. If it is a new bug, best to start a new thread to track the separate root cause.
claunia commented 2026-01-31 06:13:15 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2023):

Yep, I was wrong about how similar those bugs were. 😄

@DHowett commented on GitHub (Jan 6, 2023): Yep, I was wrong about how similar those bugs were. :smile:
claunia commented 2026-01-31 06:13:15 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 8, 2023):

@DHowett @zadjii-msft So does closing this mean that Windows 10 users of Windows Terminal and any other affected applications are screwed? Can't we at least get the OS team to backport the bugfix given how long Windows 10 is supposed to be supported?

@levicki commented on GitHub (Jan 8, 2023): @DHowett @zadjii-msft So does closing this mean that Windows 10 users of Windows Terminal and any other affected applications are screwed? Can't we at least get the OS team to backport the bugfix given how long Windows 10 is supposed to be supported?
claunia commented 2026-01-31 06:13:16 +00:00
Author
Owner
Copy Link

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

Unfortunately, yea. That's the long and short of it. Servicing is typically based on business need. We haven’t seen a lot of these crashes in the wild (fewer than 100 / month, and apparently none in the last 30 days). And the impact is fairly low - the application is already shutting down when the crash occurs. Put those together, it's an infrequent scenario with fairly low impact. I can see why the servicing team rejected this one.

@zadjii-msft commented on GitHub (Jan 10, 2023): Unfortunately, yea. That's the long and short of it. Servicing is typically based on business need. We haven’t seen a lot of these crashes in the wild (fewer than 100 / month, and apparently none in the last 30 days). And the impact is fairly low - the application is already shutting down when the crash occurs. Put those together, it's an infrequent scenario with fairly low impact. I can see why the servicing team rejected this one.
claunia commented 2026-01-31 06:13:16 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 10, 2023):

@zadjii-msft I am saying this as an end user and as a developer fully in MS ecosystem (both at work and at home) -- I am extremely dissapointed with the corporate attitude that an already implemented fix is considered too much of a hassle to backport to Win10 regardless of the supposedly low impact.

Meanwhile, new and totally unwanted advertising surfaces, user monetizing features, and dark patterns in UI design keep popping up all over the place in Win10 and Microsoft Edge, because apparently we haven't paid enough since 2015 through Win10 licensing to get the said fix included in a montly quality patch.

This of course has nothing to do with you, I am just venting my frustration and you will probably mark it as off-topic anyway.

@levicki commented on GitHub (Jan 10, 2023): @zadjii-msft I am saying this as an end user and as a developer fully in MS ecosystem (both at work and at home) -- I am extremely dissapointed with the corporate attitude that an already implemented fix is considered too much of a hassle to backport to Win10 regardless of the supposedly low impact. Meanwhile, new and totally unwanted advertising surfaces, user monetizing features, and dark patterns in UI design keep popping up all over the place in Win10 and Microsoft Edge, because apparently we haven't paid enough since 2015 through Win10 licensing to get the said fix included in a montly quality patch. This of course has nothing to do with you, I am just venting my frustration and you will probably mark it as off-topic anyway.
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 Priority-1 Product-Terminal Severity-Crash
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#18411
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?