Closed Bug 1608048 Opened 4 years ago Closed 4 years ago

Firefox 72.0.1 crashes on launch on Windows 7 with no crash report/log

Categories

(External Software Affecting Firefox :: Other, defect, P3)

defect

Tracking

(firefox-esr68 wontfix, firefox73 wontfix, firefox74 wontfix, firefox75 fixed)

RESOLVED FIXED
Tracking Status
firefox-esr68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- fixed

People

(Reporter: mcbain.asm, Assigned: gsvelto)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36

Steps to reproduce:

Initial steps:

  • Restarted Firefox when I got the auto-update popup for 72.0.1

tl;dr: Firefox 70 is last non-beta version that doesn't crash on launch without a report, Firefox 73.0b2 (beta) is the newest version that launches without crashing BUT it has other problems that make it unsuitable.

Troubleshooting steps:

  • Removed profiles (Still did not launch)
  • Downloaded latest released Firefox installer (72.0.1)
  • Uninstalled old Firefox
  • Restored removed profile (to give it something to launch to)
  • Reinstalled 72.0.1 with the "reset to defaults" checkbox checked when offered (Did not launch; same problem.)
  • Rebooted. Relaunched Firefox. (Did not run; same problem.)
  • Uninstalled 72.0.1
  • Downloaded and installed version 73 (beta), which launches the profile, loads all old tabs (with favicons) but fails to actually load any web content. All tabs are blank when active. Asking a new tab to visit "google.com" causes it to show a loading indicator in the tab but it never seems to finish loading anything.
  • Uninstalled 73 (beta)
  • Downloaded and installed version 70; It launches and complains the profile data is too new and there could be issues, suggesting I create a new profile.
  • Created new profile and it launches a window and everything seems OK, but all my stuff is trapped in that "future" profile.
  • Got frustrated, gave up, and opened Chrome to file bug report. :-/

Actual results:

Firefox failed to start after the update. At best two processes would launch then close after taking no more than around 1,400 K of memory. No crash reports were generated (or if they were, they weren't written to the filesystem in AppData/.../Pending or .../Submitted folders). The crash reporter app did not launch. Firefox will not even launch in safe mode by command line or shift, and the profile manager cannot be opened.

Expected results:

Firefox should have started up all the way, launching a window, and then reloading all my tabs. If it could not do that, then

Clarifying the "remove profiles" bit: I didn't have more than one active profile. The removal of the profiles was to test whether or not the default daily-driving profile had issues and needed to be recreated or if my two other random junk profiles from who knows when or what were causing issues. (This is because I couldn't launch the profile manager with 72.x)

Given that Firefox 73 beta launches with the profile that suggests to me it's not a profile problem, though this profile has been through many Firefox upgrades. (Two files in there, presumably no longer used, have modification dates from 2012.)

and just to note, the Firefox 70.x install doesn't stay there. After creating a new profile and launching with it, it'll offer to refresh Firefox by removing add-ons and restoring default settings. If I agree, I get auto-updated to Firefox 72.0.1 and it fails to launch, even with the new profile. This means I'm stuck short of upgrading everything to Windows 10 sooner than expected and hoping the profile still loads when copied there or dropping all the way back to the ESR. :(

I can't edit any comments it seems so apologies, but I'd like to make one last note: I do not have AVAST or Comodo installed, which Mozilla guides indicate could cause problems. The only AV I run is Microsoft Security Essentials. It's history page has no items listed in either the quarantined or detected categories relating to Firefox.

Hi,

Thanks for the details provided. Unfortunately I am not able to replicate the issue. I've tried on: Windows 10 pro, MacOS 10.14.5 and Ubuntu 18.04.3 LTS, on beta 73.0b5 (64-bit). Which version of beta were you using before the auto-update popup?

I am wondering if this may be similar to this other issue https://bugzilla.mozilla.org/show_bug.cgi?id=1608670, instead of Microsoft Security Essentials, it has Norton installed.

If entering about:crashes no crash reports are present either?

I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.

Best,
Clara.

Flags: needinfo?(mcbain.asm)
Component: Untriaged → Crash Reporting
Product: Firefox → Toolkit

It wasn't a beta. I tried the beta in hopes that whatever had caused it not to launch after the crash might be resolved (by coincidence). I was on Windows 7, and I know that's now EOL but Firefox has had a history of supporting some things longer. Though I may soonish be moving to 10 making this entire report kind of silly. That said until I do, it'd be nice if every upgrade since a couple versions ago didn't die after the update.

I have the nVidia 441.87 "game ready" driver, but I was having this issue with past versions before I updated to that, too, if it matters.

Ordinarily if I hadn't gotten Firefox working again I'd have no way to view the crash reports to my knowledge since I couldn't find anything on the file system in what appeared to be the spot crash reports were written. (but maybe it moved)

However I was able to get Firefox running again by spamming the command to launch Firefox's profile manager from the command line and 1/20 attempts or something resulted in a live window, wherein I selected my old original profile, and it launched just fine ever since. I really cannot tell you why that worked, and as a programmer myself, expecting that to work is rather a bit of insanity. :D

Anyway, these are the unsubmitted crash reports I found from around and after the date I filed this ticket, which may or may not be related to the issue I was having. I submitted all of them.

ID / Date of Crash Report Generation
71ae60d1-d581-4e4c-bf40-db5fc43d9ed4 1/11/2020, 1:58 AM
e5894241-d310-436f-b99b-ddec7266c0f9 1/11/2020, 1:53 AM
8f83b6b8-9927-44f6-9c77-fe8a59a279fe 1/11/2020, 1:53 AM
94980783-c28b-4098-8e78-dc1dd56dc093 1/11/2020, 1:53 AM
7e0fd449-40c2-4029-be08-86a301bb563e 1/11/2020, 1:53 AM
fbd3e92e-add6-4cc2-b304-c1b9e9eea13e 1/11/2020, 1:53 AM
37545fca-a937-48b5-aa93-e6fccbe34321 1/10/2020, 7:10 PM
380db69f-3a44-438d-9847-78d1a30f8a57 1/10/2020, 2:32 PM

The issue that pops up the most in those and seems to have no associated bugs lists "[@ js::TenuringTracer::moveElementsToTenured ]" as the cause. One also points to an incomplete bug against Firefox 43, that I've somehow managed to cause in 72.0.1

Flags: needinfo?(mcbain.asm)

The priority flag is not set for this bug.
:gsvelto, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gsvelto)

(In reply to Art McBain from comment #5)

It wasn't a beta. I tried the beta in hopes that whatever had caused it not to launch after the crash might be resolved (by coincidence). I was on Windows 7, and I know that's now EOL but Firefox has had a history of supporting some things longer. Though I may soonish be moving to 10 making this entire report kind of silly. That said until I do, it'd be nice if every upgrade since a couple versions ago didn't die after the update.

I have the nVidia 441.87 "game ready" driver, but I was having this issue with past versions before I updated to that, too, if it matters.

Ordinarily if I hadn't gotten Firefox working again I'd have no way to view the crash reports to my knowledge since I couldn't find anything on the file system in what appeared to be the spot crash reports were written. (but maybe it moved)

However I was able to get Firefox running again by spamming the command to launch Firefox's profile manager from the command line and 1/20 attempts or something resulted in a live window, wherein I selected my old original profile, and it launched just fine ever since. I really cannot tell you why that worked, and as a programmer myself, expecting that to work is rather a bit of insanity. :D

Anyway, these are the unsubmitted crash reports I found from around and after the date I filed this ticket, which may or may not be related to the issue I was having. I submitted all of them.

ID / Date of Crash Report Generation
71ae60d1-d581-4e4c-bf40-db5fc43d9ed4 1/11/2020, 1:58 AM
e5894241-d310-436f-b99b-ddec7266c0f9 1/11/2020, 1:53 AM
8f83b6b8-9927-44f6-9c77-fe8a59a279fe 1/11/2020, 1:53 AM
94980783-c28b-4098-8e78-dc1dd56dc093 1/11/2020, 1:53 AM
7e0fd449-40c2-4029-be08-86a301bb563e 1/11/2020, 1:53 AM
fbd3e92e-add6-4cc2-b304-c1b9e9eea13e 1/11/2020, 1:53 AM
37545fca-a937-48b5-aa93-e6fccbe34321 1/10/2020, 7:10 PM
380db69f-3a44-438d-9847-78d1a30f8a57 1/10/2020, 2:32 PM

The issue that pops up the most in those and seems to have no associated bugs lists "[@ js::TenuringTracer::moveElementsToTenured ]" as the cause. One also points to an incomplete bug against Firefox 43, that I've somehow managed to cause in 72.0.1

Sorry Art, this slipped by. Are you still experiencing the problem? If Firefox crashes too early then we won't get a chance to setup crash reporting. It's a known issue we haven't been able to solve yet. If you are still experiencing the problem we can still get a report using Microsoft WER and I can have a look at that.

The [@ js::TenuringTracer::moveElementsToTenured] crash signature is generally speaking caused by out-of-memory crashes but I find it very unlikely that this could happen at startup, especially with a brand new profile.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gsvelto) → needinfo?(mcbain.asm)
Priority: -- → P3
Attached file MS WER files

I still have the issue though it only seems to show up after new release updates or point release updates and very rarely in between (seen once so far).

It does crash before the Mozilla crash reporter can handle it, but now that I know what to look for I do appear to have a bunch of MS WER entries from the 9th, 24th, and a couple single reports from some other odd days.

If I had to guess, the 9th and 24th are days when it exhibited the issue and launched the program a bunch of times in various attempts to get it running again.

Flags: needinfo?(mcbain.asm)

Thanks Art, the .wer files are unfortunately not enough for me to debug the issue, I'll need a minidump for that. I suspect that firefox is crashing on your machine because of a DLL injection and we might need to block the offending DLL. To let WER produce a minidump you'll need to set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps as described here. Once you've done that Windows should generate a local minidump when Firefox crashes under C:\Users\yourusername\AppData\Local\CrashDumps. Please send it to me directly but do not attach it here because it might contain privacy-sensitive data.

Flags: needinfo?(mcbain.asm)

Sorry for not getting back sooner... it finally started happening again so I enabled the minidumps and I think I've got one. So I'll send it along. :)

Flags: needinfo?(mcbain.asm)

Alright, we tracked this down to old COMODO Internet Security DLLs being injected into Firefox. Since I found multiple reports on support.mozilla.org of users being affected by it I'll put all the non-current version of these DLLs into our block-list.

Component: Crash Reporting → Other
Product: Toolkit → External Software Affecting Firefox
Version: 72 Branch → unspecified
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
See Also: → 1619200

Gabriele, is the patch in this bug ready for landing? It seems some users are still experiencing the breakage (bug 1619200) and if we can block these dlls and potentially uplift to an RC2, that would probably be good. Thanks

Flags: needinfo?(gsvelto)

Aaron asked me if this had been verified on the bug but I couldn't verify it locally. Aaron, I replied on Phabricator, do you think this requires more testing? Unfortunately I was unable to get my hands on a crashing version of those DLLs but I verified that my patch blocks non-current ones correctly.

Flags: needinfo?(gsvelto) → needinfo?(aklotz)

Normally I would say yes, but I suppose since you have verified against older versions, I'll approve it.

Flags: needinfo?(aklotz)
Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/83f150fbc969
Block all old versions of COMODO Internet Security Essentials DLLs r=aklotz
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: