Open Bug 1626887 Opened 2 years ago Updated 2 years ago

Firefox .msi installer does not create the Default Browser Agent task in Task Scheduler


(Toolkit :: General, defect, P3)

75 Branch



Tracking Status
firefox-esr68 --- unaffected
firefox74 --- unaffected
firefox75 + wontfix
firefox76 + wontfix
firefox77 --- fixed
firefox78 --- fixed


(Reporter: csasca, Unassigned)


(Blocks 1 open bug)



(5 files)

Affected versions

  • Firefox 75.0
  • Firefox 76.0a1

Affected platforms

  • Windows 7, 8.1, 10 (X64)

Steps to reproduce

  1. Download a .msi installer from the archive
  2. Proceed and install it
  3. After the installation process is done, access Task Scheduler
  4. Expand Task Scheduler Library

Expected result

  • Mozilla folder is created and the Default Browser Agent's task is active

Actual result

  • Mozilla folder is created but it's empty

Regression range

  • No regression, as it was just implemented

Additional notes

  • It seems that only x64 versions of Windows are affected, as on Windows 7 (x86) the task was successfully installed by a .msi installer.
Has STR: --- → yes
Severity: normal → critical

Catalin and I discussed this on Slack and agreed it's not a blocker since only the MSI is affected. I have an idea for a fix that I'll attempt, but I don't think it would merit uplift at this stage.

Assignee: nobody → mhowell
Priority: -- → P1
Pushed by
Fallback for when registering the default browser agent task fails in the MSI. r=agashlin
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

The patch landed in nightly and beta is affected.
:mhowell, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(mhowell)

This fix only affects the MSI, so it doesn't really seem important enough to me.

Flags: needinfo?(mhowell)
Flags: qe-verify+


I have tried verifying this 77.0(ID:20200525134724) , 78.0a1(ID:20200525134724) on multiple Windows 10x64 and the issue still reproduces with the same repro steps as in the Description.

I have tried verifying with a build from treeherder from comment 3 and comment 4 but there is no target.msi build to check this.

Flags: needinfo?(mhowell)

Thanks for verifying this. I can reproduce the bug as well, so maybe this fix just never actually worked. I'll look into it.

Flags: needinfo?(mhowell)
Resolution: FIXED → ---
Severity: critical → S3

I think what's happening is this:
After this bug's patch, in the MSI install scenario we're attempting to register the task twice. The first time (the attempt that was there before) fails to create the task because it can't get the right user, but before that fails it did successfully create our task folder, and it's done that as SYSTEM. The second attempt (the one that the patch here added) then comes along running as the unelevated interactive user and it can't create the task because that user doesn't have write permissions in the already existing folder, because the task scheduler service wouldn't have seen the need to create it that way.
So it seems like what we need to do is, if creating the task fails during an attempt where we have also created the task folder, we should be deleting the folder. Really we should have been doing that anyway just so we clean up after ourselves properly, but nobody thought about it before.

This is needed to prevent a failed attempt to create the task from blocking
out the ability to try again later if the two attempts are run under different
user contexts, where the second is more limited than the first, because the
less privileged attempt is unlikely to have permission to write to the folder
created by the more privileged one. In particular the MSI installer runs into
this scenario, because it makes one attempt to register the task as SYSTEM,
followed by a second attempt as the unelevated interactive user.

This is also nice because it keeps us from leaving an empty folder behind
under any circumstances, not just this specific situation.

Pushed by
Followup - Don't leave a task folder around when we fail to create a scheduled task. r=bytesized
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: mozilla77 → mozilla78


I have tried this on 79.0a1 (ID:20200603214922), 77.0.1(ID:20200602222727) and 78.0b2(ID:20200602134412) with Windows 10x64 and I still manage to reproduce the issue with the same steps as in Description.

Flags: needinfo?(mhowell)

I've finally gotten around to trying to reproduce this again with release 78.0.2, and I am not able to do so on my own systems; I always see the task being created from the MSI. I'm not sure what to do here next.

Flags: needinfo?(mhowell)
Attached image Task Sched 80.0a1.png

Tried with .msi installers for both 79.0b7 and 80.0a1 (2020-07-13) and still had no success in finding the task, only the mozilla folder will be created in Task Scheduler.

If installing with an .exe build, the task is present. This was done on a relatively clean Windows 10. I'll attach a screenshot with the latest Nightly here.

Hmm. That's the behavior I was getting before these patches, but after I do see the task get created.

Can you check in the Windows Event Viewer under the Application log for a message from the Default Browser Agent, and post the contents of that event's Details tab here? Thanks.

Flags: needinfo?(catalin.sasca)
Attached image Task error.png

Yes, here's what Event Viewer is looking like in this case. The full message in the description is as follows:

"The description for Event ID 1332 from source Firefox Default Browser Agent cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

0x80070534 in RegisterTask:192"

Flags: needinfo?(catalin.sasca)
Attached image image.png

It seems that we are still able to reproduce the issue with Firefox 83.0b5 MSI installer and Firefox 84.0a1 MSI installer on Windows 10x64 and 10x86. Only an empty Mozilla folder is created in Task Scheduler and this error is displayed in Windows Event Viewer: No mapping between account names and security IDs was done. (see attached screenshot).
Should we file a new bug or reopen this one? Thank you!

Flags: needinfo?(mhowell)

That's definitely the same bug, so I'll reopen this. Although I admit I'm not immediately sure what to do with it if the earlier patch was incomplete or couldn't support some scenarios that I didn't think of, and I don't know when I'm going to have a chance to look into it. Thanks for retesting this.

Flags: needinfo?(mhowell)
Resolution: FIXED → ---
Priority: P1 → P3
Assignee: mhowell → nobody
You need to log in before you can comment on or make changes to this bug.