1376435 - Application popup complaining about memory that could not be read

Status: RESOLVED WORKSFORME

(External Software Affecting Firefox :: Other, defect)

Description

[alexf_ba124]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170607123825

Steps to reproduce:

Started Firefox with the Default profile.


Actual results:

A windows Application Error popped up - Event log details follow:
"
Event Type:	Information
Event Source:	Application Popup
Event Category:	None
Event ID:	26
Date:		27/06/2017
Time:		13:16:38
User:		N/A
Computer:	<REDCATED>
Description:
Application popup: firefox.exe - Application Error : The instruction at "0x7c9100e8" referenced memory at "0x00000010". The memory could not be "read".

Click on OK to terminate the program

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
"


The same error also occured whenn starting Thunderbird 52.2.1
"Event Type:	Information
Event Source:	Application Popup
Event Category:	None
Event ID:	26
Date:		27/06/2017
Time:		14:15:20
User:		N/A
Computer:	<REDACTED>
Description:
Application popup: thunderbird.exe - Application Error : The instruction at "0x7c9100e8" referenced memory at "0x00000010". The memory could not be "read".

Click on OK to terminate the program

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."




Expected results:

No error should have been generated in either instances.

Comment 1

[alexf_ba124]

Firefox version 52.2.0 (ESR Channel)

I will also note that in checking back, I found that Avast Anti-Virus had recently updated automatically. As I've had problems in the past with this Anti-Vrius's Web/Email-Shield trying to be too clever, it may be that there's an unexpected interaction occurring.

However, as I can't definitively say that it's down to Avast (or Zone Alarm), interacting this bug has been filed, so that Firefox or Thunderbird as a direct cause can be ruled out conclusviely before I send strongly worded letters to other venndors.

Comment 2

[alexf_ba124]

For reference:  Avast 17.5.2302 ( build 17.5.3559.0)  Definitions 170626-4...

Comment 3

[alexf_ba124]

Having changed some settings in Avast, it would seem that Avast is indeed trying to "clever" and getting it wrong.

If anyone's able to test  Firefox ESR or otherwise with "Hardened mode" enabled and can comment back it would be appreciated, as desiabling this, and "persistent, tranisent" caching improved matters.~~~~

Comment 4

[alexf_ba124]

It didn't fully solve the problem though as I'm STILL ocassionaly getting the Application popup.

Short of having a tool that LOGS every single file/library/program attempting to be accessed by any given firefox invocation I'm unable to determine how exactly Avast or some other program is being "clever".  It would be better to ensure that Firefox itself is hardened against "too-clever" third party software. 

I'd also appreciate it if someone "at a higher pay grade" sent very strongly worded technical enquiries in Avast and Check Points direction ( I use Zone Alarm as a firewall because Avast wouldn't play nice with Comodo)

Very disappointed so far.

Comment 5

[alexf_ba124]

Another consideration, is that apparently the Esr version at 52.2.0 is using a much more recent version of the Microsoft C runtime than is typically installed on XP, given that when checking stuff in Process explorer it's referencing a lot of DLL's in the program's install directory that have names indicative of this.

Is there an option to build a version of the ESR release that doesn't need to depend on a specific version of the Microsoft Visual C runtime?  I appreciate a staticly-linked version built on something like Minigw would be larger and slower, but it might help solve this memory could not be "read" issue in a different way by ensuring various runtime calls were entirely within the Firefox process, which would be less likely to cause various AV and IDS systems to be too clever about trying to force certain behaviour.

Comment 6

[alexf_ba124]

Another consideration, is that apparently the Esr version at 52.2.0 is using a much more recent version of the Microsoft C runtime than is typically installed on XP, given that when checking stuff in Process explorer it's referencing a lot of DLL's in the program's install directory that have names indicative of this.

Is there an option to build a version of the ESR release that doesn't need to depend on a specific version of the Microsoft Visual C runtime?  I appreciate a staticly-linked version built on something like Minigw would be larger and slower, but it might help solve this memory could not be "read" issue in a different way by ensuring various runtime calls were entirely within the Firefox process, which would be less likely to cause various AV and IDS systems to be too clever about trying to force certain behaviour.

Comment 7

[alexf_ba124]

What was updated in 52.2.1? because it's showing the error noted above a lot less now?

Comment 8

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Does this occur in Firefox nightly (57)?

Comment 9

[alexf_ba124]

(In reply to Emma Humphries ☕️ (she/her) [:emceeaich] (UTC-8) +needinfo me from comment #8)
> Does this occur in Firefox nightly (57)?

I can't run Nightly builds as support for XP was dropped.

I've not however seen the error message in 52.3.0 ESR.

Comment 10

[Selena Deckelmann :selenamarie :selena]

NI'd :tjr for info on mingw and ESR.

Given that this issue primarily affects XP, we may not be able to address it other than if we could provide a mingw build.

Comment 11

[Tom Ritter [:tjr]]

Yea, I'm not really sure. There are significant problems with MinGW and msvcr on XP, see https://bugzilla.mozilla.org/show_bug.cgi?id=1330608#c108 - Tor jumps through some big hoops to address them, and I have not attempted getting their patches working over here. (Nor did I plan to actually...)

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to alex.farlie from comment #9)

> I've not however seen the error message in 52.3.0 ESR.

That sounds promising. Let's close this bug as FIXED WORKSFORME. Please reopen if it happens again.