Terminal crashes when opening Settings

[GoodBoyNeon]

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19044.1826

Other Software

No response

Steps to reproduce

Open Windows Terminal
Either press Ctrl + , or open Settings from the dropdown menu

Expected Behavior

Expected to open the Settings Tab

Actual Behavior

Windows terminal crashed, sometimes it became unresponsive and crashed after a few seconds

Extra note: Opening settings(JSON) works fine through command palette

[zadjii-msft]

Are you running on an ARM PC by any chance? A Feedback Hub trace of the crash might be helpful: /feedback

[ghost]

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

[GoodBoyNeon]

https://aka.ms/AAhkd1t That's the link of the feedback. Thanks for your support!

[zadjii-msft]

Did you actually capture a recording of the crash with Feedback Hub? I'm not seeing any dumps in the backend, but it's also entirely possible that they just haven't had the time to fully propagate yet...

[zadjii-msft]

... Yea okay there comes some more data. Looks like the backend is just chugging a little slowly today.

[zadjii-msft]

Hmm. The FH dump doesn't have a terminal dump in it, but it does link to an exception in MTSM.dll, ExceptionCode=3221225477, ExceptionOffset=164756. 3221225477 is ERROR_ACCESS_DENIED, which is peculiar. Curious that the blame was on MTSM.dll, and not MTSE.dll.

(there is a ERROR_INVALID_PARAMETER logged from MTSM, but that's just the icon converter, which like, whatever)

OP was not on ARM

[zadjii-msft]

By any chance was the settings.json file open in another editor when you tried this? Or did you save the file while the settings UI was open/? Just feeling bits of #13673 here.

[GoodBoyNeon]

No, I wasn't opening the settings.json while trying that. I am not sure about if I saved the json file while the UI was open. I tried re installing though but it still crashes

[TJSC1213]

I have the same problem at all,and the version of my terminal on my windows10 is 10.0.19044.1889

[zadjii-msft]

@TJSC1213 can you submit feedback in the same way I requested above? More data might help ID the root cause here.

[salastro]

I have the exact same problem.

[thals1992]

I found that I have the same issue. I tried resetting the app as well as uninstalling the app via settings and reinstalled it from the Microsoft Store. It's running on Win 10 22H2, but the 32-bit version on my Dell Venue 8 Pro.

[zadjii-msft]

Can you submit feedback in the same way I requested above? More data might help ID the root cause here.

[shawn99452]

This occurs on my Windows 10 22H2 32-bit PC also, running Windows Terminal 1.15.3465.0. Changes made in settings.json externally take effect in Terminal, so it's reading the file ok, but any attempt to open the Settings UI from inside Terminal causes it to freeze for a second, close the dropdown menu, freeze a few more seconds, and then exit Terminal entirely. Renaming the settings.json file causes it to make a new one on startup, but the crash when opening the Settings UI still occurs with the default settings.
WindowsTerminal.exe.10184.dmp.zip

[zadjii-msft]

Can you submit feedback in the same way I requested above? More data might help ID the root cause here.

[shawn99452]

Can you submit feedback in the same way I requested above? More data might help ID the root cause here.

Trying to, but the Feedback Hub app just shows a blank screen with spinning dots forever when I click "Report a Problem". Every page in Feedback Hub except the 'Feedback' page works fine :(. I'll edit my original note, adding the link, if I get it to work. Is there another way to get the requested data, outside Feedback Hub?

[zadjii-msft]

Wow what fortuitous timing that I just wrote up: Capturing and sending dumps

[zadjii-msft]

Hmm, this is the one that I thought might be related to #15243 but ultimately the two are so different, I can't imagine they've got the same root cause.

It does seem like it's a consistent theme that you're all on 32-bit Windows. That's definitely curious. I wonder if I can even get this to repro in a 32-bit VM on a 64bit

HEY LOOK 9 YEARS LATER, SYMBOLS LOADED

SYMBOL_NAME:  microsoft_terminal_settings_model!`winrt::Microsoft::Terminal::Settings::Model::implementation::CascadiaSettings::_refreshDefaultTerminals'::`2'::<lambda_1>$_ResumeCoro$1::operator+137

MODULE_NAME: Microsoft_Terminal_Settings_Model

IMAGE_NAME:  Microsoft.Terminal.Settings.Model.dll

STACK_COMMAND:  ~15s; .ecxr ; kb

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_READ_c0000005_Microsoft.Terminal.Settings.Model.dll!_winrt::Microsoft::Terminal::Settings::Model::implementation::CascadiaSettings::_refreshDefaultTerminals_::_2_::_lambda_1_$_ResumeCoro$1::operator

OS_VERSION:  10.0.19045.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 10

IMAGE_VERSION:  1.15.2212.12005

FAILURE_ID_HASH:  {c5fe23d8-68c6-0750-b26c-7605d5cc7af0}

[zadjii-msft]

Well, the dump thinks L1139 is the failure here:

terminal/src/cascadia/TerminalSettingsModel/CascadiaSettings.cpp

Lines 1122 to 1145 in dec420e

	void CascadiaSettings::_refreshDefaultTerminals()
	{
	if (_defaultTerminals)
	{
	return;
	}
	// This is an extract of extractValueFromTaskWithoutMainThreadAwait
	// as DefaultTerminal::Available creates the exact same issue.
	std::pair<std::vector<Model::DefaultTerminal>, Model::DefaultTerminal> result{ {}, nullptr };
	til::latch latch{ 1 };
	std::ignore = [&]() -> winrt::fire_and_forget {
	const auto cleanup = wil::scope_exit([&]() {
	latch.count_down();
	});
	co_await winrt::resume_background();
	result = DefaultTerminal::Available();
	}();
	latch.wait();
	_defaultTerminals = winrt::single_threaded_observable_vector(std::move(result.first));
	_currentDefaultTerminal = std::move(result.second);
	}

I'm pretty confident we're in "wacky undefined compiler bug with coroutines and x86" territory here.

There's also no dumps of this on the backend, which is curious.

[jamespack]

I wonder if I can even get this to repro in a 32-bit VM on a 64bit

For poop and laughter I tried running in x86 on x64 Windows 11 and you cant. The process dies early on purpose because of driver reqs for conpty.