Closed Bug 1733821 Opened 3 years ago Closed 2 years ago

Endless loop of firefox.exe spawning and dying dozens of times per second

Categories

(Toolkit :: Startup and Profile System, defect)

Firefox 92
x86_64
Windows 7
defect

Tracking

()

RESOLVED FIXED
105 Branch
Tracking Status
firefox105 --- fixed

People

(Reporter: davorfilms, Assigned: rkraesig)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidedi-toolkit])

Attachments

(16 files, 2 obsolete files)

91.96 KB, image/png
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

Every now and then (I presume it's after some kind of update), when I quit firefox and then try to restart it, my mouse cursor starts relentlessly flickering and nothing happens. I don't know if it follows any pattern but it doesn't even create a crash log. Nothing. Renaming the Mozilla folder in AppData Roaming and AppData Local to "MozillaO" (so it can't find it) doesn't change this behavior. Usually I need to reinstall Firefox (after downloading it from the excrutiatingly slow mozilla webserver. What is going on there? Every time it takes me almost an hour to download the installer!) to fix it. Sometimes that does NOT fix it. Today I seem to have managed to fix it, though, by deleting the AppData/Local folder of Firefox. Don't know why, maybe it was a coincidence.

It's not a version-specific thing. This has happened to me at least 5 times now, in the course of the last 6-12 months.

Actual results:

When this flickering mouse cursor happens, here's more detail: There's one or two firefox.exe processes visible in Task Manager. When I click one of them and try to end it, even if I am very fast, I just get "process doesn't exist". Firefox obviously doesn't start or anything. The reason I can't end the process is that by the time I even manage to hit delete and enter, the process is already gone. It's spawning and killing itself endlessly, incredibly fast. Literally the only way I have found to stop this is to rename firefox.exe. If I do this, an error message pops up saying it can't find firefox.exe and then the flickering and infinite process loop stops. If I start this renamed firefox.exe, let's call it firefoxA.exe, the flickering and endless spawning starts again, same behavior as with the normal name.

I've tried renaming the Mozilla folders in Appdata Roaming and Appdata Local, so it can't be a defective plugin or something like that. Besides, the spawning and dying happens so damn fast, I doubt it has time to even read any files regarding plugins... that said, this one time I seem to have solved the issue by deleting the folder in Appdata/Local, however I don't wanna celebrate too early, maybe I haven't actually fixed it. I managed to start Firefox ONCE since that, it might just be pure luck. Usually I have to reinstall Firefox after wiping it completely. And even then I once struggled to get it running again, not sure why. Perhaps because I was trying to get my old profile working again, but perhaps that was a coincidence too, because again, renaming those folders doesn't change the behavior.

Obviously this is beyond frustrating. I have probably spent hours on this trying to fix the problem and screaming at my computer, at times where I actually needed to get work done in Firefox, but couldn't, and instead had to try and fix this completely ridiculous behavior.

Expected results:

Firefox should start normally and not require me to spend hours at completely random times to fix it.

On that note, can an administrator please change my username? This is my email and I don't want it public... I was never asked what I wanted for a username. Another completely ridiculous issue to have...

Moving to Toolkit :: Application Update for investigation, though this could belong in Toolkit :: Startup and Profile System, Firefox :: Installer, or it may be a hardware or third-party software issue.

(In reply to davorfilms from comment #1)

On that note, can an administrator please change my username?

Click your avatar in the top right corner, then choose Preferences. Enter something in the Your real name field, then click the Submit Changes button at the bottom.

Component: Untriaged → Application Update
OS: Unspecified → Windows 7
Product: Firefox → Toolkit
Hardware: Unspecified → x86_64

Thanks for the hint with the name change.

Taking a look into this. Where is your Firefox installed? is it located in program files?

  • Find your updater directory via about:support . The next time this is happening, see if <updatedir>\updates\0\update.status exists and if so delete it to see if it solves the problem.

  • Look into Launcher Process in about:support and see if it is Enabled or disabled . Having it disabled could be the cause of this.

  • When you see the problem again, navigate to the registry editor (Win+R, regedit) and into HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\Launcher . There should be registry values named <installationdir>|Browser and <installationdir>|Launcher . Check to see if those values are 0 or non-zero. See if setting <installationdir>|Browser to 0 fixes the problem.

Whiteboard: [fidedi-toolkit]

The severity field is not set for this bug.
:Amir, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ahabibi)
Severity: -- → S3
Flags: needinfo?(ahabibi)
Priority: -- → P3

@Jason Moomooa - Could you please answer the questions in comment 4?

Flags: needinfo?(davorfilms)

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #6)

@Jason Moomooa - Could you please answer the questions in comment 4?

Hi Kirk,

sorry, I didn't know Amir wanted an answer to those questions.

It is installed in C:\Program Files (x86)\Mozilla Firefox.

The update folder displayed for me is currently C:\ProgramData\Mozilla\updates\E7CF176E110C211B. I don't know if it was the same when this happened.

Launcher process: "Disabled forcibly" (I don't recall disabling it, I don't even know what it means)

Registry:
|Browser has the value bbcdac6a3b2
|Launcher has the value bbcdac60840

Since last time, the error only happened once and this time it stopped completely after I renamed the firefox.exe file and renamed it back, so I didn't get to try the suggestions, otherwise I would have reported back. I only restart my browser relatively rarely.

By the way, there are still many places where the front part of my email is visible ... like in "Reporter" of the bug and with the needinfo thing. Can that be fixed please? I would have registered with a throwaway email if I had known this.

Cheers

Flags: needinfo?(davorfilms)

I think this would be best suited for the startup and profile system team, since the launcher process is disabled and someone there might know how to troubleshoot this farther.

Component: Application Update → Startup and Profile System

It happened again and I tried the suggestions.

First I tried:
"Find your updater directory via about:support . The next time this is happening, see if <updatedir>\updates\0\update.status exists and if so delete it to see if it solves the problem."

There was indeed an update.status in one of the update folders (the one that was second of 3 when sorted by date modified) but also fairly recent. I deleted it and nothing changed.

Ended up changing the |Browser registry value to 0 and that fixed it, at least for now. Hope that helps. Thanks.

This has changed components since the Priority and the Severity were set. And I'm not entirely convinced that I'd call this an S3 severity. This definitely seems to block critical functionality and, though we seem to have some workarounds, I'm not sure that I'd call any of them "satisfactory". So I'm just going to go ahead and unset those fields for now.


(In reply to JasonMoomooa from comment #9)

Ended up changing the |Browser registry value to 0 and that fixed it, at least for now. Hope that helps. Thanks.

Hmm. That's not really good news. It sounds like this is definitely a problem with the launcher process, not with update. That being said, this problem will probably come back after every update. This is because we turn the launcher process back on after every update, even if it was forced off.

This isn't really my component, but I'm going to try to offer some help here. There appears to be a pref called browser.launcherProcess.enabled that can be set to false (in about:config) to disable the launcher process. I'm having a bit of trouble telling from the code how effectively this will actually keep the launcher process from being used. I believe that when we are determining whether to use the launcher process, we don't actually have access to the prefs yet, so I'm concerned that this might not be 100% effective. It's hard for me to tell without spending more time digging into the code. Why don't you try disabling this functionality via pref and see if that helps? Hopefully this will keep you from running into the problem again while we try to figure out what's going on here.

It seems quite important that this bug be fixed. But, unfortunately, I'm not actually sure whether or not we currently have someone who is in change of the launcher process. I'm going to ask around and try to figure out who should handle this.

Severity: S3 → --
Priority: P3 → --

It looks like perhaps :toshi is the launcher process expert these days?
@toshi can you look into this?

Flags: needinfo?(tkikuchi)

I think this is a regression from bug 1720993. If the launcher child fails to open the parent (launcher) process somehow, it thinks the parent process is not Firefox.
https://searchfox.org/mozilla-central/diff/2cf695ea2dbc9da305afa02901b73f8d8f611576/browser/app/winlauncher/SameBinary.h#80

I also suspect bug 1720993, but if a child firefox.exe fails to open the handle of its parent firefox.exe for some reason, this kind of endless loop is still avoided by the registry values. More specifically, if that happens, the value of "|Launcher" is newer that the value of "|Browser" and thus the child process will decide to run as the browser here.

(In reply to JasonMoomooa from comment #7)

Launcher process: "Disabled forcibly" (I don't recall disabling it, I don't even know what it means)

Registry:
|Browser has the value bbcdac6a3b2
|Launcher has the value bbcdac60840

This result is strange. The Launcher Process status on about:support is based on the registry values. "Disabled forcibly" is equivalent to Browser=0. If Browser=bbcdac6a3b2 and Launcher=bbcdac60840 i.e. Browser > Launcher, the status should be "Enabled". The registry values might have been updated after the launcher process status was cached.

Flags: needinfo?(tkikuchi)

JasonMoomooa, next time this problem happens, can you monitor the registry values in HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\Launcher for a while before renaming firefox.exe or changing the registry values? I'd like to know if the value of "|Browser" and "|Launcher" repeatedly change or not. If neither "|Browser" nor "|Launcher" is changed during this endless loop, there is a problem in registry access. Depending on the result, I'll ask you to do more steps.

Flags: needinfo?(davorfilms)

Okay, I can try to do that next time it happens. I suppose the method would be to open regedit during the endless loop, take a screenshot, close it again, open it again, and make another screenshot?

It may also be worth noting I often spend very long periods without closing Firefox. Can easily be many days. So it wouldn't be surprising at all to me if two consequent updates are released during one run of the browser. Not sure if that would be relevant but I thought I'd mention it.

(In reply to JasonMoomooa from comment #15)

Okay, I can try to do that next time it happens. I suppose the method would be to open regedit during the endless loop, take a screenshot, close it again, open it again, and make another screenshot?

You don't have to close regedit. During the endless loop, please press F5 several times to refresh the values and see which values change. Or, instead of regedit, you can run the command reg query HKCU\software\mozilla\firefox\launcher several times to dump the registry values, which may be easier.

It may also be worth noting I often spend very long periods without closing Firefox. Can easily be many days. So it wouldn't be surprising at all to me if two consequent updates are released during one run of the browser. Not sure if that would be relevant but I thought I'd mention it.

Thank you for mentioning this. Having updates might impact this launching scenario. I'll look into it tomorrow.

Ok it happened a few more times since last time but every time it kinda randomly fixed itself after a rename.

Today it happened again and renaming did not fix it.

So I went to the registry and looked at the current registry values:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Mozilla\Firefox\Launcher]
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Telemetry"=dword:00000000
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Image"=dword:60f871a5
"C:\\Program Files\\Mozilla Firefox\\firefoax.exe|Image"=dword:5ff4ba4b
"C:\\Program Files\\Mozilla Firefox\\firefoax.exe|Browser"=hex(b):00,00,00,00,\
  00,00,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Launcher"=hex(b):40,08,c6,da,\
  bc,0b,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Browser"=hex(b):b2,a3,c6,da,\
  bc,0b,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox     .exe|Image"=dword:60f871a5
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Telemetry"=dword:00000000
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Image"=dword:626afbc9
"C:\\Program Files (x86)\\Mozilla Firefox\\firefoxA.exe|Image"=dword:614b67d8
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox343.exe|Image"=dword:626afbc9

I renamed and restarted multiple times. No change in the registry.

I changed the |Browser thing to 0 again. It stayed at 0 I think and then I started again. Endless loop again. Renamed again. It stopped. And then an empty browser window appeared despite the file being renamed. So I closed the window again, renamed again and reopened and now it works again.

In registry, an extra entry appeared at the end, while the former that I set to 0 stayed. The new state looked like this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Mozilla\Firefox\Launcher]
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Telemetry"=dword:00000000
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Image"=dword:60f871a5
"C:\\Program Files\\Mozilla Firefox\\firefoax.exe|Image"=dword:5ff4ba4b
"C:\\Program Files\\Mozilla Firefox\\firefoax.exe|Browser"=hex(b):00,00,00,00,\
  00,00,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Launcher"=hex(b):40,08,c6,da,\
  bc,0b,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox.exe|Browser"=hex(b):00,00,00,00,\
  00,00,00,00
"C:\\Program Files\\Mozilla Firefox\\firefox     .exe|Image"=dword:60f871a5
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Telemetry"=dword:00000000
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Image"=dword:626afbc9
"C:\\Program Files (x86)\\Mozilla Firefox\\firefoxA.exe|Image"=dword:614b67d8
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox343.exe|Image"=dword:626afbc9
"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Browser"=hex(b):00,00,\
  00,00,00,00,00,00```

Hope that helps. By the way why is it still set as "UNCONFIRMED"?
Flags: needinfo?(davorfilms)

(In reply to JasonMoomooa from comment #17)

I renamed and restarted multiple times. No change in the registry.

I changed the |Browser thing to 0 again. It stayed at 0 I think and then I started again. Endless loop again.

So while the loop was happening, the value of "|Browser" was always 0. How about the value of "|Launcher"?

By the way, I left Mozilla in March. Haik's team will take care of this component. Haik, can you take this? The root cause of this issue is still unclear. This looks like the loop that the launcher process launches another launcher process, but the registry values seems to indicate it's not (see comment 12 and comment 13).

Flags: needinfo?(haftandilian)

My last post contains all the registry entries that were in HKEY_CURRENT_USER\Software\Mozilla\Firefox\Launcher, as I understand it, that contains |Launcher? I exported about 5 files throughout the process and then ran over them with dupeGuru and they were all identical, save for the one at the end. Both states that were different are in my last post.

@Bob, could you take a look at this? It looks like a serious bug. Is there a good tool that would log all registry changes and PIDs that might help identify what's happening?

Flags: needinfo?(haftandilian) → needinfo?(bobowencode)

(In reply to Haik Aftandilian [:haik] from comment #20)

@Bob, could you take a look at this? It looks like a serious bug. Is there a good tool that would log all registry changes and PIDs that might help identify what's happening?

I haven't used it for a bit, but Process Monitor can do this.
Should be able to add filters to just capture what is required, otherwise the amount of data captured can be quite large.

Jason - I noticed in comment 17 that you mention changing a registry setting to 0 as part of trying to fix it and then another one appearing.
It looks like these are the ones you meant.

C:\\Program Files\\Mozilla Firefox\\firefox.exe|Browser"=hex(b):00,00,00,00,00,00,00,00
...
C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe|Browser"=hex(b):00,00,00,00,00,00,00,00

So it looks like you might have two installations, one in Program Files and one in Program Files (x86).
At one point we updated users who met certain requirements from 32-bit to 64-bit versions of Firefox in place (i.e. in Program Files (x86)).
Is it possible that you have two installations of 64-bit Firefox that are interfering with each other when they update?

Flags: needinfo?(bobowencode) → needinfo?(davorfilms)

Okay it just happened again. And this time there was nothing I could do in the registry to fix it. I even deleted the entire Launcher subfolder in the registry and nothing, it just spawned a new |Image entry. I really don't mean to be impatient, but this is a serious source of frustration for me, and it's been 8+ months. I'm really sorry if I'm being rude towards people trying to help, but how can it be that one of the biggest browsers has such issues? It can take hours of work to reinstall the browser due to slow download servers and complications with getting the old user profiles working again, and it can happen in the middle of me trying to get work done or talking to friends. Luckily I got away one more time without having to do that, but how long until I stop getting lucky? How can it be so hard to solve this?

@Bob Yes, there is a folder in C:\Program Files\Mozilla Firefox\ as well. It has a "defaults" and "uninstall" folder, dated to around July 2021 in Last Modified date and an "update-settings.ini" dated to around January 2021. There is nothing else in that folder. The "defaults" folder has a "pref" subfolder with a "channel-prefs.js" file in it dated to January 2021, nothing else. The "uninstall" folder has an "uninstall.log" in it dated to February 2021 and an "uninstall.update" dated to July 2021, nothing else.

I renamed the folder from Mozilla Firefox to "Mozilla Firefox abc" and a while after that and a few failed tries later, I managed to start Firefox again. This could be a completely random coincidence and unrelated though, I cannot tell.

Please help?

Flags: needinfo?(davorfilms)

If the launcher process tries to launch a de-elevated child and the child is not de-elevated somehow, Firefox will enter the launch loop because regInfo.Commit() will not be called when LaunchUnelevated is called. Is this a possible scenario?

(In reply to JasonMoomooa from comment #22)

Please help?

Thank you for providing all the information and trying to debug the problem. We do want to get this figured out and will be investigating this more.

Assignee: nobody → rkraesig
Attached image Event Viewer.png

(In reply to Masatoshi Kimura [:emk] from comment #23)

If the launcher process tries to launch a de-elevated child and the child is not de-elevated somehow, Firefox will enter the launch loop because regInfo.Commit() will not be called when LaunchUnelevated is called. Is this a possible scenario?

It's plausible. If that's what's happening, something should be posted to the Windows event log...


@JasonMoomooa: if you run eventvwr.msc (Win+R, eventvwr.msc) and select Windows Logs > Application from the tree on the left, you should hopefully see a stream of "Error" events with "Firefox" as the source, in the center top window. (You may have to scroll down a bit, but they'll be sorted by and tagged with the date, so it shouldn't be too difficult to find the events from 2022-05-17. There may also be events from other related sources, such as "Firefox Default Browser Agent", but those aren't important here.)

Right-clicking an event in the list and selecting Copy > Copy Details as Text should get you something useful that can be pasted into Notepad. Could you do that for the first... let's say, five "Firefox" events, and attach that to this bug report? I've attached a screenshot for reference.

Flags: needinfo?(davorfilms)

Unfortunately there doesn't seem to be any big amount of errors that day. There's one, and it was hours earlier:

Log Name:      Application
Source:        Firefox
Date:          5/17/2022 11:06:44 PM
Event ID:      2
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      
Description:
The description for Event ID 2 from source Firefox 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: 


Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Firefox" />
    <EventID Qualifiers="32775">2</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-05-17T21:06:44.000000000Z" />
    <EventRecordID>61694</EventRecordID>
    <Channel>Application</Channel>
    <Computer></Computer>
    <Security />
  </System>
  <EventData>
    <Binary>02000780E90100002F6275696C64732F776F726B65722F776F726B73706163652F6F626A2D6275696C642F646973742F696E636C7564652F6D6F7A696C6C612F57696E4865616465724F6E6C795574696C732E68</Binary>
  </EventData>
</Event>

The above is May 17th. Here's May 4th, the time before that. Again, it's one entry seemingly a few hours earlier:

Log Name:      Application
Source:        Firefox
Date:          5/4/2022 10:06:07 PM
Event ID:      2
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      
Description:
The description for Event ID 2 from source Firefox 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: 


Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Firefox" />
    <EventID Qualifiers="32775">2</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-05-04T20:06:07.000000000Z" />
    <EventRecordID>61318</EventRecordID>
    <Channel>Application</Channel>
    <Computer></Computer>
    <Security />
  </System>
  <EventData>
    <Binary>02000780E90100002F6275696C64732F776F726B65722F776F726B73706163652F6F626A2D6275696C642F646973742F696E636C7564652F6D6F7A696C6C612F57696E4865616465724F6E6C795574696C732E68</Binary>
  </EventData>
</Event>

A similar looking error happened on April 16th and on October 17th 2021. I'm not sure whether those corresponded with dates that the error happened as well but I don't readily see any entry for the day I originally made this bug report nor for the second time I wrote about it happening.

Not sure if that helps.

Flags: needinfo?(davorfilms)

Not sure if that helps.

It does, yes; thank you. It's not the smoking gun I was hoping for, but it does rule out many classes of error.


For my colleagues' reference and mine: these both arise from this line reporting a Windows error code of 2 (ERROR_FILE_NOT_FOUND). The callsite for that constructor is only in one function; the logged errors are explicable as arising from a change in the binary's filename between path-acquisition and path-query. (Which might also explain bug 1578895, come to that.)

So we know that Firefox can and will write to the Windows event log, but isn't. Despite my comment above, now that I'm looking deeper, I think this supports :emk's hypothesis — if LaunchUnelevated reports success despite the child not being de-elevated, there would indeed be no logs posted. We have code to detect whether that should be the case, but perhaps not whether it is.

How about adding the -no-deelevate option when we call LaunchUnelevated? If the child is de-elevated, the option will be ignored. If the child is elevated unexpectedly, the option will stop further de-elevation attempts.

Attachment #9277865 - Attachment mime type: application/octet-stream → image/png
Severity: -- → S2

Possible reproduction steps:

  • Start a Windows 10 VM with Firefox installed on it. (The following steps will place the machine in a very unsafe state, so I don't recommend doing it on one's daily driver.)
  • Run Command Prompt as an administrator, and type the following command:
    taskkill /f /im explorer.exe && explorer.exe /nouaccheck
  • Launch Firefox.

I say "Possible reproduction steps" because I'm not convinced this is the bug under discussion: I haven't been able to reproduce it in Windows 7. (Win7's explorer.exe doesn't accept /nouaccheck, and my other attempts to force elevation have so far not succeeded.) But the symptoms do coincide, at least.


(In reply to Masatoshi Kimura [:emk] from comment #28)

How about adding the -no-deelevate option when we call LaunchUnelevated? If the child is de-elevated, the option will be ignored. If the child is elevated unexpectedly, the option will stop further de-elevation attempts.

I'd prefer to also inform the user that they're (presumably unintentionally) operating in a dangerous mode, rather than silently continuing. But yes, something like that should probably form the core of a fix.

@JasonMoomooa:

  1. Are you aware of any system configuration changes you've made — possibly vaguely described as "turning off UAC" — that might force all applications, or at least Explorer, to start with admin privileges?
  2. The next time you restart Firefox: does adding -no-deelevate to the Firefox shortcut's "Target:" field (as "C:\...\firefox.exe" -no-deelevate) prevent the launch loop?
Flags: needinfo?(davorfilms)
  1. I'm not aware of any configuration changes, however, sometimes explorer crashes and I have to revive it via Task Manager and this only works if I tick the "with admin privileges" box. Since I restart my computer very rarely, that might be related maybe? But I can't say for sure if that was the case.

  2. Okay I will try that when it happens again.

Steps to reproduce:

  • On a Windows 7 VM, log in with an admin account other than the default "Administrator" account.
  • In the Group Policy Editor (gpedit.msc), ensure that the following policies are set appropriately:
    • Local Computer PolicyWindows SettingsSecurity SettingsLocal PoliciesSecurity Options › ...
      • User Account Control: Run all administrators in Admin Approval Mode
        • must be "Enabled"
      • User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
        • must not be "Elevate without prompting" ("Prompt for consent on the secure desktop" is suggested)
    • (Note: these will probably be the defaults on a physical machine, but may be different on a prebuilt VM image.)
  • Log out and back in. (A full restart of the VM should not be necessary.)
  • Optional:
    • Start Task Manager.
    • From the menu, select ViewSelect Columns... and ensure User Account Control (UAC) Virtualization is enabled.
    • Confirm that explorer.exe's value for this column is "Disabled".
  • Start the Command Prompt with admin privileges ("Run as administrator").
    • Execute the command taskkill /f /im explorer.exe && explorer.exe.
  • Optional:
    • Start Task Manager.
    • From the menu, select ViewSelect Columns... and ensure User Account Control (UAC) Virtualization is enabled.
    • Confirm that explorer.exe's value for this column is now "Not Allowed".
  • Attempt to start Firefox.

(In reply to JasonMoomooa from comment #31)

[...] sometimes explorer crashes and I have to revive it via Task Manager and this only works if I tick the "with admin privileges" box. [...] But I can't say for sure if that was the case.

That does seem to be it.

Note that it isn't necessary to tick the "with admin privileges" box on a fresh Windows 7 image; I suspect that this is caused by some misbehaving shell extension that's blindly expecting admin privileges and crashing Explorer on startup when they're not available. If you're interested in investigating that, this StackOverflow SuperUser page may be of assistance.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(davorfilms)

"Firefox" may be inaccurate if the current app is, e.g., "Thunderbird",
or some alternatively-branded fork of Firefox.

Also, specify the Launcher as being the event source. (Officially this
should be handled via an appropriately-declared facility identifier, but
that would involve an additional build step invoking a compiler not
distributed with the ordinary Windows SDK.)

Add a new command-line flag --attempting-deelevation which prevents
the launcher from entering an infinite loop of deelevation attempts.

Additionally, produce an enum value indicating the decisions made by the
launcher process. (Nothing is done with this value yet; that will happen
in the following commit.)

Depends on D149544

Write the deelevation-status enum value into the parent process, where
it will (hopefully) show up in the event of a crash report.

(Presenting this value more conveniently -- e.g., in about:support
and/or Firefox telemetry -- would require additional plumbing, and so
has been left to future work.)

Depends on D149545

Pushed by rkraesig@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a26263bc6bcf
[1/3] Cleanup: Improve app name as seen in Event Log r=mhowell
https://hg.mozilla.org/integration/autoland/rev/cfe326bb67cd
[2/3] Add deelevation flag; compute deelevation-attempt status r=mhowell
https://hg.mozilla.org/integration/autoland/rev/572b1fb103f7
[3/3] Write deelevation-status enum into the launched parent process r=mhowell
Blocks: 1774703
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch
Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1e957ea558fb
revert patches for causing bugs 1778267 and 1778252. r=rkraesig
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Needs to also get backed out from beta.

Flags: needinfo?(dmeehan)
Target Milestone: 103 Branch → ---
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
Status: RESOLVED → REOPENED
Regressions: 1778267
Resolution: FIXED → ---

Backed out of beta by uplifting the revert

Flags: needinfo?(dmeehan)
Target Milestone: 104 Branch → ---

Perform some minor tweaks to EnsureCommandlineSafe to make it more
easily testable, and write tests for it.

No functional changes.

... in anticipation of a rewrite thereof.

Depends on D152319

strimatch attempts to perform a generic case-insensitive match.
However, it doesn't handle edge cases very well -- and, for deep Unicode
reasons, it can't reasonably do so without being far more complicated.

However, we also don't need it to. The lowerstr input of strimatch
is only ever a constant string naming a command-line option. These are
(and probably always should be) strictly composed of lowercase ASCII,
numerals, and hyphens. That character set is one that a simple
function can properly handle.

Restricting lowerstr to be const char *, regardless of CharT, also
simplifies all the callsites of EnsureCommandlineSafe -- we no longer
need to worry about keeping sets of wide and narrow strings in agreement
with each other, nor is the macro-machinery of GetLiteral and
DECLARE_FLAG_LITERAL of any further use. Strip it all out.

Additionally and relatedly:

  • Add tests confirming that strimatch only matches things that it
    should be testing against at all.
  • Add a minor fix for a test which was discovered to crash rather than
    report failure.
  • Update some documentation in mozglue that states that some arguments
    are treated case-insensitively, which hasn't been true for a while.

Although this commit involves significant internal functional changes,
most users will see no differences. (Some users operating in Turkish or
Azerbaijani locales may notice that "-PRİVATE-WINDOW" is no longer a
recognized command-line option.)

Depends on D152320

Factor out some common code to make an upcoming rewrite simpler.

This technically includes a functional change: "/-" is no longer a valid
option prefix on Windows. ("-", "--", and "/" all remain usable.)

Depends on D152321

Replace a single check in the updater to use the header-file-only
ReadAsOption.

This is a separate commit mostly out of paranoia -- this file has no
test coverage, so if this change breaks something it should be easy to
revert in isolation.

Depends on D152322

Allow the optional argument -attempting-deelevation alongside
-osint. For security's sake, optional arguments may not occur after
the URL parameter, and may not themselves take arguments. For
convenience's sake, they are further limited to coming between -osint
and the required parameter.

We do not yet supply -attempting-deelevation in any context; this will
change in an upcoming commit.

Depends on D152323

Add a new command-line flag --attempting-deelevation which prevents
the launcher from entering an infinite loop of deelevation attempts.

Additionally, produce an enum value indicating the decisions made by the
launcher process. (Nothing is done with this value yet; that will happen
in the following commit.)

This commit was previously submitted as D149545, but has undergone
significant changes.

Depends on D152324

Write the deelevation-status enum value into the parent process, where
it will (hopefully) show up in the event of a crash report.

(Presenting this value more conveniently -- e.g., in about:support
and/or Firefox telemetry -- would require additional plumbing, and so
has been left to future work as bug 1774703.)

This commit was previously submitted as D149546, and has not changed.

Depends on D152325

Since CheckArg's aParam is declared as const CharT **, it's
treated as a deduction parameter. Unfortunately, nullptr is of type
nullptr_t, and it doesn't get coerced before template argument
deduction takes place. To allow passing nullptr, people have been
using unwieldy constructs like static_cast<const wchar_t**>(nullptr)
when aParam isn't needed.

Centralize this by adding an overload of CheckArg that explicitly
takes nullptr_t and forwards it on to the primary implementation.
Strip out all the now-unnecessary static_casts everywhere else.

No functional changes.

Depends on D152326

Eliminate the need to keep Firefox's required-argument set in sync
across files by defining it only in a new header file.

No functional changes.

Depends on D152321

Attachment #9286324 - Attachment description: Bug 1733821 - [5/9] Use ReadAsOption in updater r?#application-update-reviewers → Bug 1733821 - [5/9] Use ReadAsOption in updater r?#application-update-reviewers!
Attachment #9286326 - Attachment description: Bug 1733821 - [7/9] Add deelevation flag; compute deelevation-attempt status r?mhowell,gijs,nalexander → Bug 1733821 - [7/9] Add deelevation flag; compute deelevation-attempt status r?mhowell,nalexander

Set the size-field of the struct before passing it to Windows, as one
customarily does.

(Given that STARTUPINFOEXW exists, it's not likely that this will ever
actually cause issues. But let's not rely on that.)

No functional changes.

Depends on D152326

Attachment #9286322 - Attachment description: Bug 1733821 - [3/9] Heavily specialize strimatch() r?mhowell,gijs,nalexander → Bug 1733821 - [3/9] Heavily specialize strimatch() r?mhowell,gijs
Attachment #9286323 - Attachment description: Bug 1733821 - [4/9] Factor out ReadAsOption r?mhowell,gijs,nalexander → Bug 1733821 - [4/9] Factor out ReadAsOption r?mhowell,gijs
Attachment #9286325 - Attachment description: Bug 1733821 - [6/9] Rewrite EnsureCommandlineSafeImpl to allow optional arguments r?mhowell,gijs,nalexander → Bug 1733821 - [6/9] Rewrite EnsureCommandlineSafeImpl to allow optional arguments r?mhowell,gijs
Pushed by rkraesig@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ca7530693562
[1/9] Write tests for EnsureCommandlineSafe  r=mhowell,nalexander
https://hg.mozilla.org/integration/autoland/rev/a02eff9b3a4b
[2/9] Write tests for strimatch  r=mhowell,nalexander
https://hg.mozilla.org/integration/autoland/rev/07d1581aba16
[3/9] Heavily specialize strimatch()  r=mhowell,Gijs
https://hg.mozilla.org/integration/autoland/rev/0989c03cd071
[3.5/9] Unify Firefox arguments to EnsureCommandlineSafe  r=mhowell,nalexander
https://hg.mozilla.org/integration/autoland/rev/f1358fa40bc7
[4/9] Factor out ReadAsOption  r=mhowell,Gijs
https://hg.mozilla.org/integration/autoland/rev/6cccd7c47d77
[5/9] Use ReadAsOption in updater  r=application-update-reviewers,bytesized
https://hg.mozilla.org/integration/autoland/rev/318470101258
[6/9] Rewrite EnsureCommandlineSafeImpl to allow optional arguments  r=mhowell,Gijs
https://hg.mozilla.org/integration/autoland/rev/f2f63abc6ca8
[7/9] Add deelevation flag; compute deelevation-attempt status  r=mhowell,nalexander
https://hg.mozilla.org/integration/autoland/rev/a48e7437ee17
[8/9] Write deelevation-status enum into the launched parent process  r=mhowell
https://hg.mozilla.org/integration/autoland/rev/f680dc5f7337
[8.5/9] Drive-by fix: set size-of field for Win32 API struct  r=mhowell
https://hg.mozilla.org/integration/autoland/rev/c1ef6a96e57c
[9/9] Drive-by cleanup: add nullptr_t overload for CheckArg  r=nika

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

(It was indeed by mistake, and the above two patches are linked to the wrong bug.)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: