1823159 - Firefox window is blank on startup (KB5023706)

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[bwessels]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

After windows updates with KB5023706
Start firefox after the above windows update

Actual results:

When firefox starts it is just a blank window (not a blank web page) with just the Windows min,max,close buttons.
If I close the window is says it's not responding and sends a bug report to Microsoft
I start firefox again and now works.
If I close firefox and start again it is just a blank window again. Stop and start firefox and it works.

If I start firefox in safe mode it always starts. I then disabled all addon and restarted firefox in normal mode it starts however if I close the window and start I get the blank window

Expected results:

Firefox should start

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[bwessels]

Attachment: Windows not responding report sent to Microsoft

Windows not responding report sent to Microsoft

Comment 3

[bwessels]

Attachment: Screenshot of blank window

Comment 4

[bwessels]

Edition Windows 11 Home
Version 22H2
Installed on ‎29/‎09/‎2022
OS build 22621.1413
Experience Windows Feature Experience Pack 1000.22639.1000.0

Note I did uninstall KB5023706 and firefox started as expected. After reinstalling KB5023706 the issue is seen again.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

https://www.reddit.com/r/firefox/comments/11s2293/firefox_freezes_up_on_pc_after_1110_when_trying/
https://www.reddit.com/r/firefox/comments/11uh3sf/the_latest_windows_10_update_kb5023696_causes/

Comment 6

[Yannis Juglaret [:yannis]]

Hello,

Thank you for the report. Would you consent to taking a dump of the process and sharing it with me over email at [e-mail]? This will be the same dump as what was sent to Microsoft, but this would let us work with it directly. (It is better to not share the raw dump publicly in the bug.)

Here are the steps to take the dump:

1. Run Firefox and reproduce the hang
2. Open Windows Task Manager (CTRL+SHIFT+ESC).
3. Find Firefox.exe among the list of processes. Hopefully there will be a single Firefox process, but if there are multiple, the easiest solution is to do step 4 for all of them.
4. Right-click Firefox.exe and select “Create dump file”. Task manager should indicate where the dump file was written to.

Also, are you using any third-party apps to customize your Windows experience, e.g. ExplorerPatcher, StartAllBack, X-Mouse Button Control, ...?

Are you using a third-party antivirus? (Which?)

Comment 7

[Yannis Juglaret [:yannis]]

I received dumps from the reporter (thanks!) and info that they are using no specific third-party software.

Firefox seems to be hanging waiting for this lock:

.  0  Id: 1fbc.3300 Suspend: 0 Teb: 0000003e`38021000 Unfrozen "MainThread"
 # Child-SP          RetAddr               Call Site
00 0000003e`389fe3d8 00007ffd`515e7965     ntdll!NtWaitForAlertByThreadId+0x14
01 0000003e`389fe3e0 00007ffc`cc009ce1     ntdll!RtlAcquireSRWLockExclusive+0x165
02 (Inline Function) --------`--------     xul!mozilla::OffTheBooksMutex::Lock+0x9 [/builds/worker/workspace/obj-build/dist/include/mozilla/Mutex.h @ 65] 
03 (Inline Function) --------`--------     xul!mozilla::Monitor::Lock+0x9 [/builds/worker/workspace/obj-build/dist/include/mozilla/Monitor.h @ 31] 
04 (Inline Function) --------`--------     xul!mozilla::detail::BaseMonitorAutoLock<mozilla::Monitor>::BaseMonitorAutoLock+0x9 [/builds/worker/workspace/obj-build/dist/include/mozilla/Monitor.h @ 129] 
05 0000003e`389fe450 00007ffc`ca3c35e6     xul!mozilla::PermissionManager::CompleteMigrations+0x41 [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 2981] 
06 0000003e`389fe520 00007ffc`ca3c2750     xul!mozilla::PermissionManager::EnsureReadCompleted+0x46 [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 3477] 
07 0000003e`389fe570 00007ffc`ca3c3cc1     xul!mozilla::PermissionManager::AddInternal+0x40 [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 1713] 
08 0000003e`389fe740 00007ffc`ca3c35ee     xul!mozilla::PermissionManager::ImportLatestDefaults+0x101 [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 3673] 
09 0000003e`389fe880 00007ffc`cc00b8ad     xul!mozilla::PermissionManager::EnsureReadCompleted+0x4e [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 3478] 
0a (Inline Function) --------`--------     xul!mozilla::PermissionManager::InitDB::<lambda_6>::operator()::<lambda_1>::operator()+0x9 [/builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp @ 827] 
0b 0000003e`389fe8d0 00007ffc`cb45962e     xul!mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/extensions/permissions/PermissionManager.cpp:827:36'>::Run+0xd [/builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h @ 547] 
0c (Inline Function) --------`--------     xul!mozilla::RunnableTask::Run+0x11 [/builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp @ 539] 
0d 0000003e`389fe900 00007ffc`cb45b0ea     xul!mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal+0x78e [/builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp @ 852] 
0e (Inline Function) --------`--------     xul!mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal+0xb [/builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp @ 684] 
0f (Inline Function) --------`--------     xul!mozilla::TaskController::ProcessPendingMTTask+0x17 [/builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp @ 462] 
10 (Inline Function) --------`--------     xul!mozilla::TaskController::InitializeInternal::<lambda_3>::operator()+0x23 [/builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp @ 188] 
11 0000003e`389feb20 00007ffc`cb195c75     xul!mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:188:7'>::Run+0x4a [/builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h @ 546] 
12 0000003e`389febf0 00007ffc`cb487a7f     xul!nsThread::ProcessNextEvent+0xb55 [/builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp @ 1229] 
13 (Inline Function) --------`--------     xul!NS_ProcessNextEvent+0x35 [/builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp @ 477] 
14 0000003e`389fef90 00007ffc`ca323a4f     xul!mozilla::ipc::MessagePump::Run+0xcf [/builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp @ 85] 
15 (Inline Function) --------`--------     xul!MessageLoop::RunInternal+0x16 [/builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc @ 381] 
16 0000003e`389ff1a0 00007ffc`c994ee2e     xul!MessageLoop::RunHandler+0x2f [/builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc @ 375] 
17 0000003e`389ff1f0 00007ffc`c9aa0f38     xul!MessageLoop::Run+0x4e [/builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc @ 357] 
18 0000003e`389ff250 00007ffc`c9a9fdc7     xul!nsBaseAppShell::Run+0x28 [/builds/worker/checkouts/gecko/widget/nsBaseAppShell.cpp @ 150] 
19 0000003e`389ff290 00007ffc`ce193d81     xul!nsAppShell::Run+0x37 [/builds/worker/checkouts/gecko/widget/windows/nsAppShell.cpp @ 614] 
1a 0000003e`389ff410 00007ffc`ce207887     xul!nsAppStartup::Run+0x41 [/builds/worker/checkouts/gecko/toolkit/components/startup/nsAppStartup.cpp @ 296] 
1b 0000003e`389ff460 00007ffc`ce2086a3     xul!XREMain::XRE_mainRun+0xa87 [/builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp @ 5651] 
1c 0000003e`389ff6f0 00007ffc`cba43152     xul!XREMain::XRE_main+0x303 [/builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp @ 5851] 
1d 0000003e`389ff7b0 00007ff6`db78f125     xul!XRE_main+0x62 [/builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp @ 5907] 
1e (Inline Function) --------`--------     firefox!do_main+0xcc [/builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp @ 226] 
1f (Inline Function) --------`--------     firefox!NS_internal_main+0x35b [/builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp @ 423] 
20 0000003e`389ff8a0 00007ff6`db79fd28     firefox!wmain+0x5f5 [/builds/worker/checkouts/gecko/toolkit/xre/nsWindowsWMain.cpp @ 167] 
21 (Inline Function) --------`--------     firefox!invoke_main+0x22 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 
22 0000003e`389ffad0 00007ffd`509d26bd     firefox!__scrt_common_main_seh+0x10c [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
23 0000003e`389ffb10 00007ffd`5160a9f8     kernel32!BaseThreadInitThunk+0x1d
24 0000003e`389ffb40 00000000`00000000     ntdll!RtlUserThreadStart+0x28

I do not find another thread currently executing in PermissionManager code, which could be holding the lock.

Comment 8

[Ray Kraesig [:rkraesig]]

(In reply to Yannis Juglaret from comment #7)

I do not find another thread currently executing in PermissionManager code, which could be holding the lock.

... because it's the main thread itself. This stack describes an attempt to recursively reacquire the lock: it's unconditionally acquired first in ImportLatestDefaults (08), and then a second acquisition attempt is made in CompleteMigrations (05).

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang!

It appears that the issue is caused by a change in behaviour from bug
1799470 which made the profile available earlier during startup. If the
permission manager is started between the time when the profile becomes
available and profile-do-change, it would've previously initialized
without storage, and initialized storage after profile-do-change, but
after the changes it may initialize twice instead.

This patch changes the profile-do-change handler to check if we already
have a profile, and avoid initializing the DB twice in that situation.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1799470

Comment 11

[Ryan VanderMeulen [:RyanVM]]

bwessels, we have a test build that we think might help resolve this problem. Would you be able to test it out and let us know? Directions are below, and it won't affect your normal Firefox profile.

1.) Download and install mozregression-gui: https://github.com/mozilla/mozregression/releases/download/5.3.2/mozregression-gui.exe
2.) Once the installation is finished, start mozregression-gui
3.) At the top, there is an [S] button with a "Run a single build" tooltip - click on that.
4.) On the next screen ("Basic configuration"), change the build type from "shippable" to "opt" and the repository to "try". The application should already be set to firefox and the bits 64. Those are fine to leave as-is. Click Next.
5.) On the next screen ("Profile selection"), click the browse button and choose your Firefox profile directory. Make sure that the "Profile Persistance" option is set to clone. Click Next.

• https://support.mozilla.org/kb/profiles-where-firefox-stores-user-data#w_how-do-i-find-my-profile

6.) On the next screen ("Build selection"), change the date drop-down on the right to changeset and paste 721dc49f183fbedace097f21113f5f3ff6130f1a into the Build from: box. Click Finish.

If all goes well, you'll then see mozregression-gui do some steps and eventually launch an unbranded copy of Firefox using your regular profile data. We'd love to know if that starts up normally and operates as expected or if the bug is still happening with that.

Thanks in advance! We really appreciate all the help you've already given so far.

Comment 12

[Jay]

Not being the adressed reporter, but if it might help: I just tried the above changeset via mozregression-gui and it fixes the identical issue I have been seeing since updating last Friday.

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9324036 [details]
Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang!

Beta/Release Uplift Approval Request

• User impact if declined: Intermittent browser startup hang for some users. Currently all users appear to be on Windows, however it is possible that this could also impact users on other platforms.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: STR unknown, but has been verified to fix the issue by a user encountering the issue (see comment 12)
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a change to startup logic around the permission manager and how it is loaded from the profile, however it is a fairly straightforward change which should have no negative effects. It is possible that this does not fully fix the issue, however assuming my understanding of how the bug is triggered is correct, it should.

I would be quite surprised if this made things worse.

• String changes made/needed: None
• Is Android affected?: Unknown

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9c40ff363e56
Avoid racily initializing the PermissionManager twice during startup, r=timhuang,baku

Comment 15

[bwessels]

Hi,
It looks like it worked as it started as expected without a hang. I could not figure how to run the new firefox multiple times with my profile to verify it really worked.

Comment 16

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/9c40ff363e56

Comment 19

[Donal Meehan [:dmeehan]]

Comment on attachment 9324036 [details]
Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang!

Approved for 111.0.1 RC2

Comment 20

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-release/rev/6e9b4327e238

Comment 23

[Dianna Smith [:diannaS]]

Comment on attachment 9324036 [details]
Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang!

Approved for 112.0b5

Comment 24

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/39342955a05c

Comment 25

[Donal Meehan [:dmeehan]]

(In reply to bwessels from comment #15)

Hi,
It looks like it worked as it started as expected without a hang. I could not figure how to run the new firefox multiple times with my profile to verify it really worked.

Hi, Firefox 111.0.1 started rolling out and includes this fix.

Comment 26

[bwessels]

I just upgraded to 111.0.1 and it's working great no issues. Thanks to everyone who worked on this

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Thank you for all your help! The stack in comment 7 was crucial to finding a fix.