This bug is for crash report bp-d75a71ce-a28b-4af0-9e76-63abb0200318.

Top 10 frames of crashing thread:

0 kernelbase.dll RaiseException 
1 msvcrt.dll CxxThrowException 
2 wincorlib.dll __abi_WinRTraiseCOMException 
3 windows.ui.cred.dll __abi_WinRTraiseException 
4 windows.ui.cred.dll Windows::UI::Xaml::Application::LoadComponent 
5 windows.ui.cred.dll CredUX::Frame::[CredUX::__IFramePublicNonVirtuals]::InitializeComponent 
6 windows.ui.cred.dll CredUX::Frame::Frame 
7 windows.ui.cred.dll Frame_CreateInstance 
8 windows.ui.cred.dll CredUXViewProviderImpl::GetView 
9 windows.ui.creddialogcontroller.dll CredUXViewDefinition::v_GetRootElement 

Steps to reproduce:

1. Access about:logins
2. Updated the browser (from 75.0a1(20200307213339);
3. Accessed about:logins
4. Click on the show password button;
5. Crashed;
6. On restart/reload I got asked for the OS-unlock password even tho I did not have one set.

6. On restart/reload I got asked for the OS-unlock password even tho I did not have one set.

This behavior is logged in Bug 1623279.

This is the stack from "Thread 36, Name: StreamTrans #2",

0 win32u.dll NtUserMsgWaitForMultipleObjectsEx
1 user32.dll unsigned long RealMsgWaitForMultipleObjectsEx(unsigned long, void* const*, unsigned long, unsigned long, unsigned long)
2 combase.dll CCliModalLoop::BlockFn(void**, unsigned long, unsigned long*) onecore\com\combase\dcomrem\callctrl.cxx:2233
3 combase.dll ClassicSTAThreadWaitForHandles(unsigned long, unsigned long, unsigned long, void**, unsigned long*) onecore\com\combase\dcomrem\classicsta.cpp:51
4 combase.dll CoWaitForMultipleHandles(unsigned long, unsigned long, unsigned long, void**, unsigned long*) onecore\com\combase\dcomrem\sync.cxx:123
5 windows.ui.creddialogcontroller.dll WaitForCompletion<Windows::Foundation::IAsyncOperationCompletedHandler<Windows::Internal::UI::Credentials::Controller::RequestCredentialsData*>, Windows::Foundation::IAsyncOperation<Windows::Internal::UI::Credentials::Controller::RequestCredentialsData*> >(Windows::Foundation::IAsyncOperation<Windows::Internal::UI::Credentials::Controller::RequestCredentialsData*>, tagCOWAIT_FLAGS, void)
6 windows.ui.creddialogcontroller.dll PromptInternal(Windows::Internal::Shell::PlatformExtensions::ICredUX*, Windows::Internal::UI::Credentials::Controller::CredUIStyle, Windows::Internal::UI::Credentials::Controller::ICredUXExtension*, Windows::Internal::UI::Credentials::Controller::IConsentUXContext*, Windows::Internal::UI::Credentials::Controller::ICredUXSecurePrompt*, unsigned long, _CREDUI_CONTEXT const*, CREDUI_INFO_INTERNAL*, unsigned long, unsigned long*, void const*, unsigned long, void**, unsigned long*, int*, unsigned long, bool*)
7 windows.ui.creddialogcontroller.dll CredUXController::Prompt(unsigned long, _CREDUI_CONTEXT const*, CREDUI_INFO_INTERNAL*, unsigned long, unsigned long*, void const*, unsigned long, void**, unsigned long*, int*, unsigned long, unsigned long*)
8 wincredui.dll CredUIPromptForWindowsCredentialsWorkerInternal
9 wincredui.dll CredUIInternalPromptForWindowsCredentialsWorker
10 wincredui.dll CredUIInternalPromptForWindowsCredentialsW
11 credui.dll CredUIPromptForWindowsCredentialsW
12 xul.dll mozilla::detail::RunnableFunction<`lambda at Z:/task_1584481299/build/src/security/manager/ssl/OSReauthenticator.cpp:278:7'>::Run()

The crash report says this was Windows 10 build 18362 with en-US locale. I am running build 18363 locally and can't reproduce it.

@Cristian, are the STR from comment #0 reproducible every time for you?

This happened only 1 time for me unfortunately.
Attempted to reproduce today but no crash encountered.

The volume of this seems to be low in crash-stats so lowering the priority. (bug 1626801 is making the signature more granular)

Replacing the old generic signature with the new one.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

I cannot reproduce now using STR, and I use about:logins a lot and have never crashed using it.

Only a handful on crash-stats in last 6 months, and none since mid-November bp-71f547b1-0acd-452c-bcbd-96e1b0201113 version 82

Worth keeping bug open?

(In reply to Wayne Mery (:wsmwk) from comment #7)

Only a handful on crash-stats in last 6 months, and none since mid-November bp-71f547b1-0acd-452c-bcbd-96e1b0201113 version 82

That's because the feature that causes this is Nightly-only: https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/browser/app/profile/firefox.js#1915,1917,1920-1921

We should disable the feature for Nightly but this bug will likely come back when more Windows users get the feature.

Yeah we should keep the bug open as long as the feature is enabled in Nightly, and perhaps even after as we do want to try and ship this eventually and we'll want to keep an eye out for these crashes at that point.

Closing because no crashes reported for 12 weeks.