Endless loop of firefox.exe spawning and dying dozens of times per second
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
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.
Reporter | ||
Comment 1•3 years ago
|
||
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...
Comment 2•3 years ago
|
||
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.
Reporter | ||
Comment 3•3 years ago
|
||
Thanks for the hint with the name change.
Comment 4•3 years ago
•
|
||
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.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
The severity field is not set for this bug.
:Amir, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 6•3 years ago
|
||
@Jason Moomooa - Could you please answer the questions in comment 4?
Reporter | ||
Comment 7•3 years ago
|
||
(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
Comment 8•3 years ago
|
||
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.
Reporter | ||
Comment 9•2 years ago
|
||
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.
Comment 10•2 years ago
|
||
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.
Comment 11•2 years ago
|
||
It looks like perhaps :toshi is the launcher process expert these days?
@toshi can you look into this?
Comment 12•2 years ago
|
||
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
Comment 13•2 years ago
|
||
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.
Comment 14•2 years ago
|
||
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.
Reporter | ||
Comment 15•2 years ago
|
||
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.
Comment 16•2 years ago
•
|
||
(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.
Reporter | ||
Comment 17•2 years ago
|
||
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"?
Comment 18•2 years ago
|
||
(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).
Reporter | ||
Comment 19•2 years ago
|
||
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.
Comment 20•2 years ago
|
||
@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?
Comment 21•2 years ago
•
|
||
(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?
Reporter | ||
Comment 22•2 years ago
|
||
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?
Comment 23•2 years ago
|
||
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?
Comment 24•2 years ago
|
||
(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 | ||
Comment 25•2 years ago
|
||
(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 whenLaunchUnelevated
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.
Reporter | ||
Comment 26•2 years ago
|
||
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.
Assignee | ||
Comment 27•2 years ago
•
|
||
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.
Comment 28•2 years ago
|
||
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.
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 29•2 years ago
|
||
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 callLaunchUnelevated
? 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.
Assignee | ||
Comment 30•2 years ago
|
||
@JasonMoomooa:
- 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?
- 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?
Reporter | ||
Comment 31•2 years ago
|
||
-
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.
-
Okay I will try that when it happens again.
Assignee | ||
Comment 32•2 years ago
|
||
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 Policy › Windows Settings › Security Settings › Local Policies › Security 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)
- User Account Control: Run all administrators in Admin Approval Mode
- (Note: these will probably be the defaults on a physical machine, but may be different on a prebuilt VM image.)
- Local Computer Policy › Windows Settings › Security Settings › Local Policies › Security Options › ...
- Log out and back in. (A full restart of the VM should not be necessary.)
- Optional:
- Start Task Manager.
- From the menu, select View › Select 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
.
- Execute the command
- Optional:
- Start Task Manager.
- From the menu, select View › Select 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.
Assignee | ||
Comment 33•2 years ago
|
||
"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.)
Assignee | ||
Comment 34•2 years ago
|
||
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
Assignee | ||
Comment 35•2 years ago
|
||
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
Comment 36•2 years ago
|
||
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
Comment 37•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a26263bc6bcf
https://hg.mozilla.org/mozilla-central/rev/cfe326bb67cd
https://hg.mozilla.org/mozilla-central/rev/572b1fb103f7
Comment 38•2 years ago
|
||
Comment 39•2 years ago
|
||
Pushed by bhearsum@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1e957ea558fb revert patches for causing bugs 1778267 and 1778252. r=rkraesig
Assignee | ||
Updated•2 years ago
|
Comment 40•2 years ago
|
||
Needs to also get backed out from beta.
Comment 41•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 42•2 years ago
|
||
bugherder uplift |
Comment 43•2 years ago
|
||
Backed out of beta by uplifting the revert
Assignee | ||
Comment 44•2 years ago
|
||
Perform some minor tweaks to EnsureCommandlineSafe
to make it more
easily testable, and write tests for it.
No functional changes.
Assignee | ||
Comment 45•2 years ago
|
||
... in anticipation of a rewrite thereof.
Depends on D152319
Assignee | ||
Comment 46•2 years ago
|
||
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
Assignee | ||
Comment 47•2 years ago
|
||
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
Assignee | ||
Comment 48•2 years ago
|
||
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
Assignee | ||
Comment 49•2 years ago
|
||
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
Assignee | ||
Comment 50•2 years ago
|
||
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
Assignee | ||
Comment 51•2 years ago
|
||
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
Assignee | ||
Comment 52•2 years ago
|
||
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_cast
s everywhere else.
No functional changes.
Depends on D152326
Assignee | ||
Comment 53•2 years ago
|
||
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
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 54•2 years ago
|
||
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
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 55•2 years ago
|
||
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
Comment 56•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ca7530693562
https://hg.mozilla.org/mozilla-central/rev/a02eff9b3a4b
https://hg.mozilla.org/mozilla-central/rev/07d1581aba16
https://hg.mozilla.org/mozilla-central/rev/0989c03cd071
https://hg.mozilla.org/mozilla-central/rev/f1358fa40bc7
https://hg.mozilla.org/mozilla-central/rev/6cccd7c47d77
https://hg.mozilla.org/mozilla-central/rev/318470101258
https://hg.mozilla.org/mozilla-central/rev/f2f63abc6ca8
https://hg.mozilla.org/mozilla-central/rev/a48e7437ee17
https://hg.mozilla.org/mozilla-central/rev/f680dc5f7337
https://hg.mozilla.org/mozilla-central/rev/c1ef6a96e57c
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 59•2 years ago
|
||
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)
Assignee | ||
Comment 60•2 years ago
|
||
(It was indeed by mistake, and the above two patches are linked to the wrong bug.)
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Description
•