Closed Bug 1243914 Opened 8 years ago Closed 8 years ago

Firefox 44 never opens on my Windows 7, downgrading fixes the issue

Categories

(Toolkit :: Startup and Profile System, defect)

44 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox44 - affected
firefox45 - affected
firefox46 - affected

People

(Reporter: eis, Unassigned)

References

()

Details

(Whiteboard: [44dll])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151208100201

Steps to reproduce:

Updated from Firefox 43 to 43.0.1, then to 44. Tried starting up.

Using Windows 7. Here's a list of things I tried when starting up: http://superuser.com/questions/1032737/firefox-will-not-open

Note: downgrading to 43 fixes the problem, both on my full profile as well as newly created profile.


Actual results:

firefox.exe appears in task manager as a process but no windows show up.


Expected results:

Firefox should have opened.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Did you try to reinstall FF44 (without removing your profiles, ofc)?
I did try, both with not removing and removing my profiles. These are the things I tried:

 - Start it in safe mode with shift pressed: no impact, same behavior (process appears in process list but no application starts)
 - Try to start profile manager using firefox.com -P: no impact, same behavior
 - Try to remove the binaries from C:\Program Files (x86)\Mozilla Firefox and reinstalling: no impact, same behavior when starting
 - Uninstalled Firefox using its own installer, then reinstalled: no impact
 - Removed my profile from C:\Users\myusername\AppData\Roaming\Mozilla\Firefox\Profiles: no impact, same behavior when starting
 - Removed my profile from C:\Users\myusername\AppData\Local\Mozilla\Firefox\Profiles: on first run after this complained about missing profile; reinstalling Firefox brought back to error behavior
 - Rebooted the computer: no impact
 - Run a Microsoft Security Essentials scan: no problems found
 - Checked for results in Event Viewer -> Applications, nothing interesting
 - chkdsk found no problems
Running Firefox 44 as administrator seems to also fix the issue. That is not needed with Firefox 43.
If you install a next version like FF45 or 46, does it work without using the admin rights?
https://www.mozilla.org/en-US/firefox/beta/all/
Hi,

I tested this on Win 7, I download a firefox 42 version then upgrade to 43.0.1 then to 44, it works for me, I can't reproduce the issue. 
Please download the Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.
Component: Untriaged → Application Update
Flags: needinfo?(eis)
Product: Firefox → Toolkit
I have now tested with various versions, and these are the results:

 - FF45.0b1 32-bit from beta downloads: has the issue
 - FF47.0a1 32-bit from nightly downloads: has the issue
 - FF45.0b1 64-bit from beta downloads: no issue
 - FF47.0a1 64-bit from nightly downloads: no issue

I also tried now Firefox 44 64-bit version and it hasn't got the issue. I should have mentioned earlier that I've been using 32-bit version of Firefox on my 64-bit Windows 7. So the issue seems to be that since Firefox 44, all 32-bit versions of Firefox need administrative rights to run on Windows 7 64-bit.
Flags: needinfo?(eis)
Hi,
Yes this is the problem, if your Windows is on 64 bit you need to use Firefox for 64 bit.
Based on your comment I will close this issue as Resolved: WFM. Feel free to reopen it if you still reproduce this.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
This resolution makes me ask several questions.

As far as I've understood, 32-bit version upgrade stream will not switch to 64-bit firefox even on 64-bit Windows, so isn't this a serious issue if the default update stream will lead to hangs? Also, 64-bit Firefox has only limited support for plugins. Does this mean Firefox has stopped having full support for plugins in 64-bit versions of Windows?

Source: https://blog.mozilla.org/futurereleases/2015/12/15/firefox-64-bit-for-windows-available/

I don't think it's acceptable that default upgrade path will lead to Firefox that won't even start up. I have received no information that I should have switched to 64-bit version of Firefox.
And also, why is it that using administrate rights makes the 32-bit version work? Is this an approved workaround for running 32-bit version, if you want full plugin support?
I will reopen this issue, and someone with more experience on this matter can take a look at this problem.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
(In reply to eis from comment #8)
> Also, 64-bit Firefox has only
> limited support for plugins. Does this mean Firefox has stopped having full
> support for plugins in 64-bit versions of Windows?

It's a choice to not support plugins for the 64b version, like Chrome. See bug 1187005 for that.
There is probably a regression in FF44.

In your comment #6, did you test these versions with the installer?
If yes, are you able to run the standalone version by just clicking on firefox.exe.
You can test with the latest Nightly 47 32b:
http://ftp.mozilla.org/pub/firefox/nightly/2016/01/2016-01-31-03-03-47-mozilla-central/firefox-47.0a1.en-US.win32.zip
Unzip the /firefox archive and run firefox.exe.
Benjamin, any ideas? Sounds like there might be a 32 bit binary loading (plugin, lsp, or malware, etc.) with Firefox that is preventing startup on 32 bit and not loading on 64 bit so it doesn't prevent startup.
Component: Application Update → Startup and Profile System
Flags: needinfo?(benjamin)
Possible debugging options:
* check the exit code to see whether Firefox is exiting early, or whether this is a crash
* Use process monitor to see which file(s) are opened by Firefox immediately before it shuts down/crashes
* If it's a crash, use some field-debugging tool to catch a dump of the crash.

Aaron, any more specific thoughts?
Flags: needinfo?(benjamin) → needinfo?(aklotz)
[Tracking Requested - why for this release]: This is a worrying bug. I think release drivers ought to check and see if this is showing up in SUMO or other channels so we can prioritize if this is more than a one-off problem.
Hi Florin, is your team able to repro this issue? This seems to be a problem running Fx44 (on wards) 32-bit version on 64-bit version of win7. 

Hi Matt, since you worked on the sha-1 deprecation (somewhat related), wondering if you can help root cause. Thanks!
Flags: needinfo?(mhowell)
Flags: needinfo?(florin.mezei)
(In reply to Loic from comment #12)
> In your comment #6, did you test these versions with the installer?
> If yes, are you able to run the standalone version by just clicking on
> firefox.exe.

I used the installer versions. Indeed, I am able to run the standalone version as per your instructions. It seems to work just fine.
(In reply to Ritu Kothari (:ritu) from comment #17)
> Hi Matt, since you worked on the sha-1 deprecation (somewhat related),
> wondering if you can help root cause. Thanks!

I don't think it's that, the startup problems that I've seen code signature failures cause don't present with quite the same symptoms; in those cases, nothing ever shows up in task manager at all because Windows refuses to create the process, and running as administrator doesn't help.
Flags: needinfo?(mhowell)
(In reply to eis from comment #18)

Sorry, was too quick to claim that standalone version works. It worked for the first time, after exiting that instance and killing a stray firefox.exe process that was left hanging, it never started up again and went back to problem behaviour.
Ok, so the standalone version works *as long as I don't have another, installer-installed version of Firefox 32-bit installed on my computer*. Highly strange.
(In reply to eis from comment #18)
> (In reply to Loic from comment #12)
> > In your comment #6, did you test these versions with the installer?
> > If yes, are you able to run the standalone version by just clicking on
> > firefox.exe.
> 
> I used the installer versions. Indeed, I am able to run the standalone
> version as per your instructions. It seems to work just fine.
With the Nightly you installed with the installer which is typically installed into "C:\Program Files (x86)\Nightly" on a x64 Windows OS try double clicking firefox.exe to see if it launches.

If that doesn't work, try renaming the installation directory which for Nightly (e.g. the version from comment #6) is typically "C:\Program Files (x86)\Nightly" on a x64 Windows OS. Create a new directory Nightly directory under "C:\Program Files (x86)" then take the contents of the unzipped Nightly you tested and copy (do not move) the contents into "C:\Program Files (x86)\Nightly". Then try launching firefox.exe.
(In reply to eis from comment #21)
> Ok, so the standalone version works *as long as I don't have another,
> installer-installed version of Firefox 32-bit installed on my computer*.
> Highly strange.

That was likely caused by a firefox.exe process that was still running (no idea why it would be but it might be related) since launching a new firefox.exe process will just hand it off to the copy that was running.

With this new info the steps I asked you to perform in comment #22 are likely not valuable.
At this point the recommendations in comment #14 are the best route forward.
Unfortunately, we were unable to reproduce this issue on two machines running Windows 7 64-bit.
Tried with Fx 44 and newer versions. Also tried by updating Fx 42 to 43.0.1 to 44 and it worked.
Testing was performed using both standard and administrator accounts.
Flags: needinfo?(florin.mezei)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #14)
> Aaron, any more specific thoughts?

I've seen a few bugs for 44 that I suspect are all related, this one included. In the other bugs, some users *have* managed to obtain crash reports that are showing what amounts to heap corruption. Interestingly, the corruption is in the Windows heap, not jemalloc.

I think a good way to attack this would be to enable the heap validation GFlag for firefox.exe. It will slow things down, but it will also force a crash at the bad heap operation.

Of course, it is imperative that the flag be disabled again once it is no longer needed. :-)
Flags: needinfo?(aklotz)
Aaron, is that something you can help eis accomplish? Is that something we can turn on in release builds, or need to do a custom try build to enable that flag?
Flags: needinfo?(aklotz)
This is a flag that eis would need to temporarily enable on their computer. Is that something that you'd be comfortable with?
Flags: needinfo?(aklotz) → needinfo?(eis)
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #28)
> This is a flag that eis would need to temporarily enable on their computer.
> Is that something that you'd be comfortable with?

Sure, let me know what to do.
Flags: needinfo?(eis)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #14)
> * check the exit code to see whether Firefox is exiting early, or whether
> this is a crash

I tried to do this by running firefox.exe from cmd prompt and then doing "echo Exit Code is %errorlevel%". Doing that I noticed that I don't have the issue there, starting firefox from cmd prompt... Problem seems to be appearing only if I start it by doubleclicking the quick launch icon, which I've always done. I don't know how to get an exit code out of that.
I made a quick video about the behaviour the way I see it. In this video, I have Firefox 44 32-bit installed but not running, and I click the quick start link, wait, and then for another time. https://www.youtube.com/watch?v=057Zg6LPdNQ
(In reply to eis from comment #30)
> I tried to do this by running firefox.exe from cmd prompt and then doing
> "echo Exit Code is %errorlevel%". Doing that I noticed that I don't have the
> issue there, starting firefox from cmd prompt... Problem seems to be
> appearing only if I start it by doubleclicking the quick launch icon, which
> I've always done. I don't know how to get an exit code out of that.

That's a very interesting observation.
I have posted instructions at https://pastebin.mozilla.org/8858430
Feel free to contact me via this bug or email (see my bugzilla profile) if you're experiencing any problems.
Flags: needinfo?(eis)
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #33)

However, like I explained in the beginning, running firefox.exe -P from the command line does lead to the problem situation. It might be that I never tried just firefox.exe.

By using firefox -P I am able to test the error level. It is zero. This confirms what I suspected that the process does not crash - I have Soluto in use, which does alert me whenever any process crashes and it hasn't alerted me in investigating this.

(Note: There has also appeared at least some people in superuser seeing the same thing I am seeing, http://superuser.com/a/1034717/112204)
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #34)
> I have posted instructions at https://pastebin.mozilla.org/8858430

I did follow the instructions. Two observations:

 - Firefox didn't seem to crash, and I guess gflags will only catch anything if it does crash?
 - Firefox started up just fine when gflags were enabled. When I disabled the selections, it returned back to the problematic behaviour. Same startup in both cases, clicked the pinned icon on my taskbar.
Flags: needinfo?(eis)
Having the same issue.

The facts:
- it's revealed after update to v44
- it crashed occasionally on startup
- it can be system crash related to `ntdll.dll` without starting Crash reporter
- it can be hanging on start up without crash (but no window loaded and starter process still in memory)
- it's happened more often when I (or other program) start second instance of FF (may be with other command line parameters)

Here is screenshot link showing hanging process in memory:
https://yadi.sk/i/xa4KuOhDoDt5x
Does deleting the file extensions.json and lock file from the user profile after terminating firefox.exe process in task manager allow the browser to launch?
(In reply to Toady from comment #38)
> Does deleting the file extensions.json and lock file from the user profile
> after terminating firefox.exe process in task manager allow the browser to
> launch?

In the very first steps I already tried deleting the entire profile folders, but even that did not help.
I see 64 bit helps you. do you perchance have nvidia hardware as well?
Blocks: 1243237
Flags: needinfo?(eis)
(In reply to Patrick McManus [:mcmanus] from comment #40)
> I see 64 bit helps you. do you perchance have nvidia hardware as well?

NVIDIA GeForce GTX 670.
Flags: needinfo?(eis)
Whiteboard: [44dll]
As of today, the problem stopped happening. I can't reproduce it anymore. Sorry. This occurred when I booted my machine once more - I have booted it already in the past and it didn't help, but this time the problem seems to be gone, at least for now.
very likely a dup of 1243098
FYI, Firefox 44.0.2 (due for release today) has a hopeful fix for this issue. Please try it out when you get a chance :)
The reporter from dupe bug 1247738 says 44.0.2 fixed his issue.
I confirm the bug seems to be gone with 44.0.2, since I can't reproduce it anymore.
Not tracking as it seems to be a dup of bug 1243098
Hi, 
we have deployed an APP-V Application of Firefox ESR (starting on Version 38) in our company.
At the moment we have more and more issues of exactly the same behaviour. On some PCs Firefox will not be started, while Process is running in task manager. Same behaviour with safe-mode and Profile Manager.
The issue is also not resolved when completely deleting the cached Version of the APP-V Firefox and loading it completely new (Firefox will then be version 38.0.1 again).
I can not say on which update the issue comes up, since on some PCs Firefox still works (on newest ESR Version 45.2.0) and it only gets updated when in use, so it might have been some Version in between causing the issue...
Is there already any fix known for this issue?!
[Tracking Requested - why for this release]:
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: