1795909 - "Firefox cannot open, please see Microsoft Store for more info"

Status: RESOLVED FIXED

(Firefox :: Installer, defect, P1)

Description

[Andrew Robbins]

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

Steps to reproduce:

Updated firefox to 106 via the Microsoft Store, launched firefox, exited firefox, launched firefox again.

Actual results:

Windows popup saying that Firefox cannot open, with no further details. Reinstalling program from store allows for launch.

Expected results:

Firefox launches. No issue on installation from mozilla.org (current browser user agent).

Comment 1

[xconverge]

I just wanted to echo this (and add myself to CC) and that there are some comments on other parts of the internet seeing the same thing, so it should be reproducible. I may have to switch off of the store version to resolve this for myself today.

Comment 2

[Rubén]

Windows 10 (21H2). Same problem. I uninstalled it and now cannot reinstall it.

Comment 3

[[e-mail] (:bhearsum)]

We don't have any data in the Partner Centre for 106 yet. I did notice two things though:

1. I'm seeing a large spike in "Unknown" crashes or hangs beginning with 105. It's unclear if that is related or not, though. I'm hoping we'll see a more clear crash with a stack trace once the 106 data comes in.
2. A hang, which I filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1795958. Probably unrelated to this bug (it's existed for months), but I'm noting it here on the off chance it is related.

I, unfortunately, cannot repro the crash on my Windows 10 VM. If anyone who is able to reproduce this can try to do with Visual Studio's debugger attached to grab a stack trace, that would be lovely. You should be able to launch the MSIX version with these instructions:
In Visual Studio, select Debug -> Other Debug Targets -> Debug Installed App Package. In the dialog, select the installed Firefox package you wish to debug and click “Start”.

Comment 4

[gigjsk]

Windows 11 (22H2), also have the same problem. The browser window also seems to become entirely unresponsive (doesn't register in Windows as not responsive, but no buttons or clicks work) upon trying to load a page after my home page has been loaded. Upon closing, the browser then fails to open with the same error message mentioned in the original post, with the same fix restoring the browser temporarily.

Comment 5

[gigjsk]

(In reply to [e-mail] (:bhearsum) from comment #3)

We don't have any data in the Partner Centre for 106 yet. I did notice two things though:

1. I'm seeing a large spike in "Unknown" crashes or hangs beginning with 105. It's unclear if that is related or not, though. I'm hoping we'll see a more clear crash with a stack trace once the 106 data comes in.
2. A hang, which I filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1795958. Probably unrelated to this bug (it's existed for months), but I'm noting it here on the off chance it is related.

I, unfortunately, cannot repro the crash on my Windows 10 VM. If anyone who is able to reproduce this can try to do with Visual Studio's debugger attached to grab a stack trace, that would be lovely. You should be able to launch the MSIX version with these instructions:
In Visual Studio, select Debug -> Other Debug Targets -> Debug Installed App Package. In the dialog, select the installed Firefox package you wish to debug and click “Start”.

I got the following output from the debug steps, all of which came before the browser opened, with no resource monitoring or further logging appearing in Visual Studio once the browser window was open:
'firefox.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Mozilla.Firefox_106.0.0.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\firefox.exe'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
'firefox.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Mozilla.Firefox_106.0.0.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\mozglue.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\crypt32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Mozilla.Firefox_106.0.0.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\msvcp140.dll'.
'firefox.exe' (Win32): Loaded 'C:\Program Files\WindowsApps\Mozilla.Firefox_106.0.0.0_x64__n80bbvh6b1yt2\VFS\ProgramFiles\Firefox Package Root\vcruntime140.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'.
The thread 0x2c68 has exited with code 0 (0x0).
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\daxexec.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\msvcp_win.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\userenv.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\container.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\combase.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\ntmarta.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\Windows.StateRepositoryClient.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\Windows.StateRepositoryCore.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\capauthz.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\win32u.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\gdi32full.dll'.
'firefox.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'.
The thread 0x561c has exited with code 0 (0x0).
The thread 0x32e4 has exited with code 0 (0x0).
The thread 0x51e8 has exited with code 0 (0x0).
The program '[10708] firefox.exe' has exited with code 0 (0x0).

Comment 6

[Ryan VanderMeulen [:RyanVM]]

I can reproduce this as well. I've halted the rollout in the Store for now until we can determine what's going on here.

Comment 7

[[e-mail] (:bhearsum)]

(In reply to gigjsk from comment #5)

(In reply to [e-mail] (:bhearsum) from comment #3)

We don't have any data in the Partner Centre for 106 yet. I did notice two things though:

1. I'm seeing a large spike in "Unknown" crashes or hangs beginning with 105. It's unclear if that is related or not, though. I'm hoping we'll see a more clear crash with a stack trace once the 106 data comes in.
2. A hang, which I filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1795958. Probably unrelated to this bug (it's existed for months), but I'm noting it here on the off chance it is related.

I, unfortunately, cannot repro the crash on my Windows 10 VM. If anyone who is able to reproduce this can try to do with Visual Studio's debugger attached to grab a stack trace, that would be lovely. You should be able to launch the MSIX version with these instructions:
In Visual Studio, select Debug -> Other Debug Targets -> Debug Installed App Package. In the dialog, select the installed Firefox package you wish to debug and click “Start”.

I got the following output from the debug steps, all of which came before the browser opened, with no resource monitoring or further logging appearing in Visual Studio once the browser window was open:

Thank you for doing this! Unfortunately, this log is just routine messages :(. If you're able to reproduce the "This app can't open" issue, it would definitely be worth trying again. Visual Studio may detect a crash or a hang in that case.

Comment 8

[gigjsk]

(In reply to [e-mail] (:bhearsum) from comment #7)

(In reply to gigjsk from comment #5)

(In reply to [e-mail] (:bhearsum) from comment #3)

We don't have any data in the Partner Centre for 106 yet. I did notice two things though:

1. I'm seeing a large spike in "Unknown" crashes or hangs beginning with 105. It's unclear if that is related or not, though. I'm hoping we'll see a more clear crash with a stack trace once the 106 data comes in.
2. A hang, which I filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1795958. Probably unrelated to this bug (it's existed for months), but I'm noting it here on the off chance it is related.

I, unfortunately, cannot repro the crash on my Windows 10 VM. If anyone who is able to reproduce this can try to do with Visual Studio's debugger attached to grab a stack trace, that would be lovely. You should be able to launch the MSIX version with these instructions:
In Visual Studio, select Debug -> Other Debug Targets -> Debug Installed App Package. In the dialog, select the installed Firefox package you wish to debug and click “Start”.

I got the following output from the debug steps, all of which came before the browser opened, with no resource monitoring or further logging appearing in Visual Studio once the browser window was open:

Thank you for doing this! Unfortunately, this log is just routine messages :(. If you're able to reproduce the "This app can't open" issue, it would definitely be worth trying again. Visual Studio may detect a crash or a hang in that case.

All I get when the "app can't open" issue comes back is an error pop-up with the following message:

Unable to activate Windows Store app 'Mozilla Firefox_n80bbvh6b1yt2!App'. The activation request failed with error "The application cannot be started. Try reinstalling the application to fix the problem".

Comment 9

[[e-mail] (:bhearsum)]

Attachment: stack trace

We just got our first surge of data from Partner Center for 106. The top error is "application_fault_60c201e_firefox.exe!unknown", which has stack traces like this. We ought to try to get our own symbols resolved here, which should give us a much better idea of what's going on (I don't know how to do that yet though).

Comment 10

[[e-mail] (:bhearsum)]

The attached stack includes BaseThreadInitThunk. The only place we call that is in WindowsDllBlocklist.cpp. That file had one (seemingly minor) change in 106: https://hg.mozilla.org/mozilla-central/rev/2676d5d346843aa519346ab20dbf353643f0b347

Florian, you were the reviewer on this, do you have any idea what's going on here? (I realize this is a longshot....)

Comment 11

[[e-mail] (:bhearsum)]

Also, via gstoll on Matrix:

FWIW it looks like Fx is trying to load a DLL and that's failing for some sort of integrity reason. LdrAppxHandleIntegrityFailure doesn't have a lot of hits on Google, unfortunately, and at least some are of the "this was crashing and then it stopped" variety.

Maybe this in the DLL blocklist doing its job?

Comment 12

[Florian Quèze [:florian]]

(In reply to [e-mail] (:bhearsum) from comment #10)

Florian, you were the reviewer on this, do you have any idea what's going on here?

Unfortunately, no.

Comment 13

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 14

[[e-mail] (:bhearsum)]

Attachment: proper stack trace

I managed to find a minidump on one of the crashes on Parter Center.

This appears to show the main thread crashing completely outside of our own code. In fact, it appears that the only thing of ours running at all in the DLL Interceptor.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

The attached stack includes BaseThreadInitThunk. The only place we call that is in WindowsDllBlocklist.cpp...In fact, it appears that the only thing of ours running at all in the DLL Interceptor.

AFAIK this is expected - any thread on Windows that we start is going to be launched off of the DLL blocklist. So this doesn't really say much.

Comment 16

[[e-mail] (:bhearsum)]

Attachment: full minidump

Here's the full minidump, in case someone else wants to inspect it themselves.

Comment 17

[[e-mail] (:bhearsum)]

Attachment: dump with more symbolification

Comment 18

[Gian-Carlo Pascutto [:gcp]]

nss3.dll!pr_LoadLibraryByPathname(const char * name, int flags) Line 509
	at /builds/worker/checkouts/gecko/nsprpub/pr/src/linking/prlink.c(509)
xul.dll!mozilla::MozAVLink(nsIFile * aFile) Line 45
	at /builds/worker/checkouts/gecko/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp(45)
xul.dll!mozilla::FFVPXRuntimeLinker::Init() Line 94
	at /builds/worker/checkouts/gecko/dom/media/platforms/ffmpeg/ffvpx/FFVPXRuntimeLinker.cpp(94)
xul.dll!mozilla::PDMInitializer::InitUtilityPDMs() Line 131
	at /builds/worker/checkouts/gecko/dom/media/platforms/PDMFactory.cpp(131)
...
xul.dll!mozilla::ipc::UtilityAudioDecoderParent::Start(mozilla::ipc::Endpoint<mozilla::ipc::PUtilityAudioDecoderParent> && aEndpoint) Line 105

This happens when the Audio Utility Process' parent side initializes the ffmpeg helper library and tries to dlopen it. This is something that may have changed recently. (Also, given that we don't decode in the parent if the Utility Process is there, why is it doing that? Checking format support?)

Alexandre, did anything change from Fx105->Fx106 that could be relevant here?

Comment 19

[[e-mail] (:bhearsum)]

(Removing the regressionwindo-wanted flag because Partner Center clearly shows this beginning with 106.)

Comment 20

[:gerard-majax]

we landed https://bugzilla.mozilla.org/show_bug.cgi?id=1780796 on 106 ?

Comment 21

[Gian-Carlo Pascutto [:gcp]]

Alexandre, did anything change from Fx105->Fx106 that could be relevant here?

Well, we enabled the Utility Process (bug 1785738). But that doesn't answer the question: Why is that running into problems on the Microsoft Store only? Ben was guessing the mozavutil DLL may not be correctly signed. But why does the Utility Process surface that issue?

Comment 22

[:gerard-majax]

no 105 line on https://hg.mozilla.org/mozilla-central/file/99c5de523ab33fc65d577220cc7c0d88420f1d8d/ipc/glue/UtilityAudioDecoderParent.cpp
but there's a 105 line https://hg.mozilla.org/mozilla-central/file/63e205c1562b8f66262fe275121993f5a2dcd981/ipc/glue/UtilityAudioDecoderParent.cpp so it would be after bug 1785738 ?

Comment 23

[[e-mail] (:bhearsum)]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #21)

Alexandre, did anything change from Fx105->Fx106 that could be relevant here?

Well, we enabled the Utility Process (bug 1785738). But that doesn't answer the question: Why is that running into problems on the Microsoft Store only? Ben was guessing the mozavutil DLL may not be correctly signed. But why does the Utility Process surface that issue?

mozavutil looks signed correctly to me - for the record.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

alissy was able to confirm that this was regressed by bug 1780796 and only when EARLY_BETA_OR_EARLIER isn't set.

Comment 25

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

The bug is marked as tracked for firefox106 (release) and tracked for firefox107 (beta). However, the bug still isn't assigned.

:yshash, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 26

[:Gijs (he/him)]

Tentatively moving this to installer as that's where most of the MSIX work happened - can be moved again later but leaving it in Fx::General isn't helping triage efforts. Also passing around Yasmin's needinfo to Ben who I believe has more context here.

Comment 27

[[e-mail] (:bhearsum)]

I believe all the real work here ended up going into https://bugzilla.mozilla.org/show_bug.cgi?id=1796391. I think that's landed with a viable fix, and I believe we're planning a pointing release this week to ship it.

Comment 28

[Pascal Chevrel:pascalc]

Fixed via bug 1796391 in 106.0.2