window explorer (and terminal) hangs when I edit the address bar in a file picker about terminal

[zadjii-msft]

Dustin repro'd this instantaneously on Windows 10, and Leonard thinks... I think this code is the problem:

terminal/src/cascadia/WinRTUtils/inc/Utils.h

Lines 15 to 55 in 49e4eea

	winrt::Windows::Foundation::IAsyncOperation<winrt::hstring> FilePicker(HWND parentHwnd, bool saveDialog, TLambda&& customize)
	{
	auto fileDialog{ saveDialog ? winrt::create_instance<IFileDialog>(CLSID_FileSaveDialog) :
	winrt::create_instance<IFileDialog>(CLSID_FileOpenDialog) };
	DWORD flags{};
	THROW_IF_FAILED(fileDialog->GetOptions(&flags));
	THROW_IF_FAILED(fileDialog->SetOptions(flags | FOS_FORCEFILESYSTEM | FOS_NOCHANGEDIR | FOS_DONTADDTORECENT)); // filesystem objects only; no recent places
	// BODGY: The MSVC 14.31.31103 toolset seems to misdiagnose this line.
	#pragma warning(suppress : 26481) // Don't use pointer arithmetic. Use span instead (bounds.1).
	customize(fileDialog.get());
	const auto hr{ fileDialog->Show(parentHwnd) };
	if (!SUCCEEDED(hr))
	{
	if (hr == HRESULT_FROM_WIN32(ERROR_CANCELLED))
	{
	co_return winrt::hstring{};
	}
	THROW_HR(hr);
	}
	winrt::com_ptr<IShellItem> result;
	THROW_IF_FAILED(fileDialog->GetResult(result.put()));
	wil::unique_cotaskmem_string filePath;
	THROW_IF_FAILED(result->GetDisplayName(SIGDN_FILESYSPATH, &filePath));
	co_return winrt::hstring{ filePath.get() };
	}
	template<typename TLambda>
	winrt::Windows::Foundation::IAsyncOperation<winrt::hstring> OpenFilePicker(HWND parentHwnd, TLambda&& customize)
	{
	return FilePicker(parentHwnd, false, customize);
	}
	template<typename TLambda>
	winrt::Windows::Foundation::IAsyncOperation<winrt::hstring> SaveFilePicker(HWND parentHwnd, TLambda&& customize)
	{
	return FilePicker(parentHwnd, true, customize);
	}

terminal/src/cascadia/TerminalSettingsEditor/Profiles_Base.cpp

Lines 109 to 125 in 49e4eea

	fire_and_forget Profiles_Base::Icon_Click(const IInspectable&, const RoutedEventArgs&)
	{
	auto lifetime = get_strong();
	const auto parentHwnd{ reinterpret_cast<HWND>(_windowRoot.GetHostingWindow()) };
	auto file = co_await OpenImagePicker(parentHwnd);
	if (!file.empty())
	{
	_Profile.Icon(file);
	}
	}
	fire_and_forget Profiles_Base::StartingDirectory_Click(const IInspectable&, const RoutedEventArgs&)
	{
	auto lifetime = get_strong();
	const auto parentHwnd{ reinterpret_cast<HWND>(_windowRoot.GetHostingWindow()) };
	auto folder = co_await OpenFilePicker(parentHwnd, [](auto&& dialog) {

Those sorta attempt to do the work async, but actually don't make it async at all

[zadjii-msft]

Hmm. We once had a similar report in #8957, but that was when users were running the Terminal elevated, and was also fixed in like, 1.7.

There was also #9984, which sounds almost exactly the same, but OP disappeared on that one.

I also can't repro this here on Windows 11.

Filing /feedback with the Feedback hub (but with the area set to like, "Files and Online Storage > File Explorer") may work to get a trace:

[KamenRevice]

Here's a link to the feedback recorded in the feedback center
Does this have anything to do with the network driver clouddriver2 that I installed

[zadjii-msft]

Huh. Interestingly enough, it looks like you're the only one who's hit this?

• Apparently I can't promote the feedback hub feedback to an MSFT: work item. That's weird, but I think we're changing some backend bits.
• I can still get to feedback ID 9a191c39-d40a-4559-82ed-d23e3cfec3a1
• It's got three .dmps for explorer.exe,
• and a link to a bucket: 1568601951875420617 (BucketDetails?BucketIdentifier=1568601951875420617).
  • There's only exactly one hit for this specific bucket in the last 90 days.
  • It's a moapphang in microsoft.windowsterminal_1.19.10821.0_x64__8wekyb3d8bbwe, and we have other moapphang's hanging around too, but I don't think they're related
  • There's nothing else interesting in the bucket...

[KamenRevice]

Really? Did you locate the bug so quickly, and how long will it take to fix it, please?

[zadjii-msft]

I have no idea if that's the actual source of the bug or not. We had coincidentally just been chatting about how this particular code didn't work as expected. And it sure seems like this is the kind of thing that might cause this bug.

No ideas how long it would take to fix. It might not even be the correct source of the bug 🤷