Closed Bug 1529593 Opened 2 years ago Closed 1 year ago

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

Categories

(Firefox :: Launcher Process, defect, P1)

67 Branch
x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
Firefox 71
Tracking Status
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified
firefox72 --- verified
firefox73 --- verified

People

(Reporter: streetwolf52, Assigned: toshi)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: inj+)

Attachments

(2 files)

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.

Component: Untriaged → General
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

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.

Aaron, can you please triage and assign a priority?

Blocks: 1435780
Flags: needinfo?(aklotz)

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.

  • 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?
Flags: needinfo?(garyshap)

(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?

Flags: needinfo?(garyshap)

(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.

Depends on: 1460433
Flags: needinfo?(aklotz)
Priority: -- → P3

Sounds like a plan.

Depends on: 1530531

An update on this problem please?

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.

Severity: normal → critical
Priority: P3 → P2
  • 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.

Priority: P2 → P3

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.

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?

(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.

Will do.

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.

Attached image 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.

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?

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.

What is the name of the pref?

datareporting.healthreport.uploadEnabled

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

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

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?

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.

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

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

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

Summary: Launcher Process is disabled when I change my memory speed in my computer's UEFI. → Launcher Process - Disabled due to failure in Application Basics section in about:support/Troubleshooting Information after opening Mozilla Firefox from external software

Bug 1577816 is a DUP.

Status: UNCONFIRMED → NEW
Component: General → Launcher Process
Ever confirmed: true
Blocks: 1530541
No longer blocks: 1435780
Whiteboard: inj+

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.

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.

Assignee: nobody → tkikuchi
Status: NEW → ASSIGNED
Priority: P3 → P1

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?

Flags: needinfo?(aklotz)

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

Flags: needinfo?(aklotz)

(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.

Attachment #9090892 - Attachment description: Bug 1529593 - Clear the timestamps in the registry before LaunchUnelevated. r=aklotz → Bug 1529593 - Make LauncherRegistryInfo delay write to the registry. r=aklotz
Depends on: 1527328
Keywords: checkin-needed

Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/88558e13a0be
Make LauncherRegistryInfo delay write to the registry. r=aklotz

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
Flags: qe-verify+

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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.