1529593 - Launcher Process - Disabled due to failure in Application Basics section in about:support/Troubleshooting Information after opening Mozilla Firefox from external software

Status: VERIFIED FIXED

(Firefox :: Launcher Process, defect, P1)

Description

[Gary [:streetwolf52]]

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

Steps to reproduce:

1. Make sure browser.launcherProcess.enabled is set to true.
2. Restart PC and enter UEFI setup.
3. Change memory speed to another value.
4. Reboot PC.
5. Start Fx.

Actual results:

about:support displays 'Launcher Process Disabled due to failure.'
'browser.launcherProcess.enabled' is still set to true however.

To make the Launcher Process enabled again I have to set it to false, restart Fx, and then set it to true. It's possible, though not tested, that changing other UEFI options might also produce the same results. I have not seen this however.

100% reproducible on my machine for the memory speed change.

Expected results:

Launcher Process should remain enabled when changing memory speed in BIOS.

Comment 1

[Gary [:streetwolf52]]

Correction:

To enable the Launcher Process in about:support all I need to do is set browser.launcherProcess.enabled to false then set browser.launcherProcess.enabled to true.

Comment 2

[Matthew N. [:MattN]]

Aaron, can you please triage and assign a priority?

Comment 3

[Gary [:streetwolf52]]

My issue might be related to altering other options in the UEFI besides memory speed. Suffice it to say that very often when I change things in my UEFI I often get Launcher Process disabled.

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

• Are you overclocking, by any chance?
• Could this be confounded by the fact that, by virtue of the fact that you've just rebooted to change your UEFI settings, you're getting a freshly-updated Nightly? ie, can you reproduce this by just updating Nightly and restarting?

Comment 5

[Gary [:streetwolf52]]

(In reply to Aaron Klotz [:aklotz] from comment #4)

• Are you overclocking, by any chance?
• Could this be confounded by the fact that, by virtue of the fact that
  you've just rebooted to change your UEFI settings, you're getting a
  freshly-updated Nightly? ie, can you reproduce this by just updating Nightly
  and restarting?

Yes I overclock but the issue doesn't always happen when I do so.

I'm confused by your second comment. I've never had the issue when I've updated to the latest Nightly. Is this what you wanted answered?

As I said about:support shows the LP as disabled while the controlling pref is still true. Can the problem just be that about:support is incorrect?

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Gary [:streetwolf] from comment #5)

I'm confused by your second comment. I've never had the issue when I've updated to the latest Nightly. Is this what you wanted answered?

Yes.

As I said about:support shows the LP as disabled while the controlling pref is still true. Can the problem just be that about:support is incorrect?

Unlikely. Disabled due to failure happens even though the pref is on.

Once bug 1460433 lands (which is very soon) we should be able to obtain better information about why the launcher process is failing on you. Until then I'm going to mark this P3. We can revisit this once you have a Nightly build that contains those changes.

Comment 7

[Gary [:streetwolf52]]

Sounds like a plan.

Comment 8

[Gary [:streetwolf52]]

An update on this problem please?

Comment 9

[Gary [:streetwolf52]]

Is anyone still looking into this?

I'm on Nightly 70. Bug 1460433 I assume is baked into 70. I am still having the same issue. It never stopped through the various Nightly versions since I first reported this. Besides certain BIOS changes causing the problem, there are times when I haven't made any BIOS changes and the Process Launcher becomes disabled. Again I have to enable then disable the pref and restart Fx to have it stay enabled, at least until it happens again.

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

• Please do not adjust the priority flags; they have specific meanings.
• You're going to need to do some troubleshooting. Start Firefox with the following command line options:
  • -force-launcher
  • -log-launcher-error

Once you have checked about:support and verified that the launcher process is still disabled due to failure, go to the Windows Event Viewer and look under Windows Logs -> Application. You should see an Error entry for Firefox. Examine the event's properties, go to the detailed view, and paste the information from that view into this bug.

Comment 11

[Gary [:streetwolf52]]

Sorry for the change I made. I added the two options to my Fx shortcut and as soon as the Process Launcher gets disabled I'll get the data you requested.

Comment 12

[Gary [:streetwolf52]]

Ever since I added the two command line parameters on my Fx shortcut I haven't had Launcher Process disable itself. This is after I made BIOS changes that should have caused a failure. Can the params be 'fixing' my problem in and of itself or do I have to wait a little longer until it fails again?

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Gary [:streetwolf] from comment #12)

Can the params be 'fixing' my problem in and of itself or do I have to wait a little longer until it fails again?

-force-launcher resets the "disabled due to failure" state, so after using it the first time, I'd recommend removing it from the shortcut and just leaving -log-launcher-error so that, if it fails again, we get a log.

Comment 14

[Gary [:streetwolf52]]

Will do.

Comment 15

[Gary [:streetwolf52]]

I just had a 'Disabled due to failure' in about:support. It appears that by running the benchmark option in CPU-Z is a reliable way to repro the problem for me. Unfortunately even with '-log-launcher-error' on my Fx shortcut command line did not produce an event log entry.

Link to CPU-Z @ https://www.cpuid.com/softwares/cpu-z.html. Version 1.90 is the latest.

Comment 16

[Gary [:streetwolf52]]

Attachment: CPU-Z screenshot.

In CPU-Z you click on the Tab called 'Bench'. Then you click the button 'Bench CPU'. After processing is complete the button 'Submit and Compare' becomes active. Clicking on this button will open up Firefox to show you the results of the bench test. Opening of Fx is the key to making the Launcher disabled. Running the bench without clicking on 'submit and compare' won't force the error.

Comment 17

[(No longer employed by Mozilla) Aaron Klotz]

Unfortunately because Firefox is being started indirectly, you do not get a chance to supply -log-launcher-error on the command line. :-(

Another way to force Firefox to write the error to the event log is to disable Telemetry in your preferences. Would you mind giving that a try?

Comment 18

[Gary [:streetwolf52]]

Just discovered that any link in CPU-Z that opens up Fx will disable the launcher.

I'll try whatever you need me to do.

Comment 19

[Gary [:streetwolf52]]

What is the name of the pref?

Comment 20

[(No longer employed by Mozilla) Aaron Klotz]

datareporting.healthreport.uploadEnabled

Comment 21

[Gary [:streetwolf52]]

I started opening up links in other programs and so far all caused the launcher to be disabled.

Comment 22

[Gary [:streetwolf52]]

I have the pref set to false already. Now what?

Comment 23

[Gary [:streetwolf52]]

Does this seem strange to you? I created a brand new profile with no add-ons. I made it my default. I then ran a program with a link in it that opens up this new Fx. My Test Fx had the launcher disabled error. I then set my normal Fx as the default and restarted Fx. My normal Fx also had the Launcher marked as disabled. Why would a failure on a different Fx show up in another Fx with a different profile?

Comment 24

[(No longer employed by Mozilla) Aaron Klotz]

Launcher process failure state is stored in the registry, because it runs before Gecko's pref system is ever started. Those registry settings are per Windows user, not per profile.

Comment 25

[Gary [:streetwolf52]]

Knowing that it is caused by links in external programs should be of some help, don't you think?

Comment 26

[(No longer employed by Mozilla) Aaron Klotz]

Yeah, especially knowing your steps to reproduce with CPU-Z, we can attempt to reproduce it locally.

Comment 27

[Gary [:streetwolf52]]

Is the fact that setting the pref you gave me to false didn't produce an event log entry indicates a bug?

Comment 28

[Gary [:streetwolf52]]

Bug 1577816 is a DUP.

Comment 30

[Toshihito Kikuchi [:toshi]]

I also reproduced the issue with CPU-Z. It seems that if we launch firefox.exe from any elevated process, the launcher process is always disabled. I think we should delete Launcher's timestamp in mozilla::LaunchUnelevated.

Comment 31

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1529593 - Make LauncherRegistryInfo delay write to the registry. r=aklotz

If the process is launched with high privileges, we update the launcher
timestamp before reachinh LaunchUnelevated to re-launch a process via shell.
In this case, we need to clear the timestamp in the registry, otherwise a new
process sees the launcher timestamp is newer than the browser timestamp, which
disables the launcher process.

Comment 32

[Toshihito Kikuchi [:toshi]]

Ok, thank you for the comment, Aaron. I understand deleting the timestamp is too cheap :) and we don't want to lose information.

Another idea I'm thinking of is to delay write to the registry. This particular issue happens because we update the launcher's timestamp too early in LauncherRegistryInfo::Check via RunAsLauncherProcess. I think we can make LauncherRegistryInfo hold a timestamp, flushing it later in LauncherMain. What do you think?

Comment 33

[(No longer employed by Mozilla) Aaron Klotz]

That's one of the ideas that I had in mind, yes! :-)

Comment 34

[Toshihito Kikuchi [:toshi]]

(In reply to Aaron Klotz [:aklotz] from comment #33)

That's one of the ideas that I had in mind, yes! :-)

Glad to hear that! Let me prepare a patch.

Comment 35

[Gary [:streetwolf52]]

Is there a patch forthcoming?

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/88558e13a0be
Make LauncherRegistryInfo delay write to the registry. r=aklotz

Comment 37

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/88558e13a0be

Comment 38

[Daniel Bodea [:danibodea]]

I have reproduced this issue with information in comment 16 on nightly v71.0a1 (2019-10-10) (64-bit).
I have verified this fix on:

• Nightly v73.0a1 (2019-12-05) (64-bit)
• Beta v72.0b2 (64-bit)
• Release v71.0 (64-bit)
  The launcher process does not fail on the fixed builds.