User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150302192546 Steps to reproduce: 1. Environment: Windows 7 64-bit edition, all Windows updates installed as of 2015/03/06. 2. Download firefox-38.0a2en-GB-win64.installer.exe from mozilla.org and make a clean install to a new directory. 3. Run firefox.exe Actual results: Firefox almost instantly crashes with the exception code 0xc0000005 and fault offset 0x000000006fff150a (both from the Event Viewer). These codes are always the same. More data from the Event Viewer: Faulting application path: C:\soft\Firefox\firefox.exe Faulting module path: unknown Deleting the profile directory from %appdata% makes no difference. The same installation works perfectly when copied to a virtual machine running Windows 8.1 x64. The 32-bit edition of Aurora 38.0a2en-GB works both in Windows 7 and 8.1. Expected results: The 64-bit edition of Firefox should work in Windows 7 like it does in Windows 8.1.
I didn't manage to reproduce it with FF 38 latest 64 build. Can you please try to reproduce it using safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode#w_how-to-start-firefox-in-safe-mode), to be sure that the bug is not related with any of the installed add-ons .
I analysed the crash dump and found the reason for the crash. The crash is caused by having guard64.dll version 5.10.31649.2253 or older resident in memory. Guard64.dll is installed by Comodo Firewall. Merely having the dll resident will cause the crash - even if the firewall is completely disabled and all firewall-related tasks are killed. Digging deeper, it seems that the problem is caused by trying to execute data as code (NX violation). Unfortunately I could not find out why FF x64 triggers this incompatibility - all other 64-bit browsers I tested (IE 11, Chrome beta, Chromium 43) work fine.
Updating guard64.dll to version 6.3.302093 or higher will prevent the crash: tested on 38.0a2 and the latest nightly.
Blocklisting would make sense.
Component: Untriaged → Blocklisting
Product: Firefox → addons.mozilla.org
Summary: Firefox 38.0a2 win64 doesn't start in Windows 7 x64 → Blocklist guard64.dll version 5.10.31649.2253 or older (Firefox 38.0a2 win64 doesn't start in Windows 7 x64)
Version: 38 Branch → unspecified
Is there any information about how prevalent this crash is?
Product: addons.mozilla.org → Toolkit
This bug doesn't appear to be valid anymore.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
A user reported a new occurrence of this problem on SuMo: https://support.mozilla.org/questions/1225790 Very difficult to track down...
Some people are still using this old version of Comodo IS and since our platform refresh some users have run into this again - I'm assuming it's still a hazard, also for Firefox users, and should be blocklisted. It's confirmed that updating Comodo IS solves the problem for our users as well but not everyone will be willing to do this. Blocking the dll by version seems to be the best solution. Discussion: https://forum.palemoon.org/viewtopic.php?f=3&t=20716
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Mark, to repeat the question, is there any information about how prevalent this crash is on Firefox? It would be good to have some data on this before we do any blocking.
It is as prevalent as the number of people still running Comodo IS 5 -- which is a relatively small number of people, but it is a pretty much guaranteed crash if the combination of IS 5 and a more recent Firefox x64 is encountered. So you're looking at a relatively small number of people still running this old IS version, but if they update their (probably just as outdated) browser to a more current version or decide to switch to 64-bit, they will crash on startup. The nature of the crash seems to prevent the crash reporter from catching it, so telemetry will be minimal if at all present.
Thanks for the note. Due to the very low volume of crashes and limited circumstances under which this could appear we're not going to be installing a block for this dll. We may reconsider this in the future and will open a new report accordingly if necessary.
Status: REOPENED → RESOLVED
Closed: 2 years ago → 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.