1140397 - Blocklist guard64.dll version 5.10.31649.2253 or older (Firefox 38.0a2 win64 doesn't start in Windows 7 x64)

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Jesse Raatikainen]

Attachment: The Windows error dialog

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.

Comment 1

[Jesse Raatikainen]

Attachment: Data about the crash from Event Viewer

Comment 2

[Jesse Raatikainen]

Attachment: Stack trace created with Windbg

Comment 3

[Jesse Raatikainen]

Attachment: Crash dump compressed with 7zip

Comment 4

[Catalin Varga [QA][:VarCat]]

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 .

Comment 5

[Jesse Raatikainen]

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.

Comment 6

[Jesse Raatikainen]

Updating guard64.dll to version 6.3.302093 or higher will prevent the crash: tested on 38.0a2 and the latest nightly.

Comment 7

[Masatoshi Kimura [:emk]]

Blocklisting would make sense.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

Is there any information about how prevalent this crash is?

Comment 9

[Jorge Villalobos [:jorgev] (he/him)]

This bug doesn't appear to be valid anymore.

Comment 10

[jscher2000]

A user reported a new occurrence of this problem on SuMo: https://support.mozilla.org/questions/1225790

Very difficult to track down...

Comment 11

[Mark Straver]

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

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 13

[Mark Straver]

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.

Comment 14

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.