Closed Bug 1544001 Opened 5 years ago Closed 1 year ago

Firefox crash [@ CLocalEndpointEnumerator::OnMediaNotification ] after update

Categories

(Core :: DOM: Content Processes, defect)

66 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dannyfox, Unassigned)

Details

(Keywords: crash, Whiteboard: [tbird crash])

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Run Firefox update, follow standard/normal user procedure:

  1. Click HELP, ABOUT.
  2. Version check runs, says new FF available.
  3. Click button to update, let it download and install.
  4. Click button to restart FF.
  5. Let FF reload and check version (click HELP, ABOUT)

Actual results:

I was running FF 66.0.2 and upgrading to 66.0.3 using the normal HELP/ABOUT update procedure.

At some point in the process (and I've never noticed where), the Firefox Crash Window pops under all other windows, only to be seen when I close or move other windows. (Icon also pops up on the toolbar but is rarely noticed -- I'm busy documenting the update process.)

This has happened for several updates recently. It seems to me the previous FF "crashes" rather than closes (hence the crash window), then the new just loads and carries on as normal.

Expected results:

The old FF should have closed normally as part of the update procedure, then let the new FF take over without a fuss.

I have "submitted a report" from the crash windows whenever this happens. Today I attach the "details" in the attached text file (saved as unicode encoding via Notepad).

Hello Dan - Thanks for reporting. Do you have any crashes in about:crashes that you can paste here (please submit at least one if you haven't already done so). This will aid in our investigation. Thanks!

Flags: needinfo?(dannyfox)
Component: Untriaged → Application Update
Product: Firefox → Toolkit

These are the recently submitted reports, all related to crashes following updates. Every single one of the latest updates had the issue (and I know it goes back even farther):

bp-c63fe853-eb40-4fdf-87bf-56b310190412 12/04/2019, 10:00 a.m. (update from 66.0.2 to 66.0.3)
(Full text submitted in the text attachment above)

bp-bde02773-03be-457c-8b70-19d5b0190327 27/03/2019, 4:32 p.m. (update from 66.0.1 to 66.0.2)

bp-06a440d3-b2ea-4b27-80d2-8dc7c0190325 25/03/2019, 10:26 a.m. (update from 66.0 to 66.0.1)

bp-8da91aac-895d-4fde-a897-7ce580190320 20/03/2019, 11:04 a.m. (update from 65.0.2 to 66.0)

bp-bb09db6e-aae4-43ef-a14e-d005e0190304 04/03/2019, 12:33 a.m. (update from 65.0.1 to 65.0.2)

bp-ef6ac204-87f8-40ea-aa7b-1c4040190213 13/02/2019, 9:27 a.m. (update from 65.0 to 65.0.1)

bp-74e5bb20-4153-4668-b5bb-b04070190206 06/02/2019, 9:05 a.m. (update from 64.0.2 to 65.0)

bp-5ff0911d-cfee-4c55-876a-c29b00190111 10/01/2019, 8:58 p.m. (update from 64.0 to 64.0.2)

Note that the same updates never invoked crashes on our Laptop, which is running the exact same Windows, etc. (I explicitly noted in one entry that there was no sign of the crash which had happened a little earlier on the Tower.) But the Laptop update process has always run a little differently, even though AFAIK the software environment and FF setup are identical to the Tower. (For instance, in the past restarting Thunderbird would not result in a TB update installing and I'd have to re-do it, even though the same update on Tower was normal.)

Flags: needinfo?(dannyfox)

Interesting. Your crash reports map back to an older bug, Bug 731812 which referenced removing a USB headset. Also interesting to note that you have some norton modules installed, nortonsafeweb@symantec.com and nortonsafesearch_ul_2@symantec.com. Wondering if they may be involved in some way.

Never heard of Bug 73182, and I don't have a USB headset (only a wired audio jack).

But I've had an ongoing issue with "Norton Security" (fka "Norton Internet Security") for about three years. We've had a lot of failures of their updates on both Tower and Laptop (both Dell PCs, Win 7 Pro/32). Left unattended, automatic updates that failed would eventually lead to a cascade of errors with the entire program crashing -- ie, dead, gone, NO protection. It seemed if an update occurred during a scan (or shortly thereafter) -- and they always would during a full-system scan or custom scan of a large folder like email -- then the update(s) might/could/would fail, and then continue to do so until reboot.

I've been working with Norton Level 2 Support on the matter, especially over the past several months where they've captured logs of activity leading up to crashes. They've improved the product a lot in the time since, but it is still a bit flaky. Lately, occasional manual updates will be on the verge of completing when the entire program dies, but at least now it seems to restart automatically in a few minutes. By similar evidence in the history, I see this same type of event occurs unattended during automatic updates.

That being said, both Tower and Laptop (both Dell PCs, Win 7 Pro/32) have the Norton extensions (safeweb and safesearch) installed and active, but the FF crashes happen on the Tower most often yet only very rarely on the Laptop along with the TB (and possibly FF) restarts that didn't result in any update. If I recall correctly, I had to restart the program(s) manually on the Laptop -- close the window and re-launch them -- and then the update would actually install and take hold. (Now, there is a brief "Installing..." popup, but that wasn't always the case -- or perhaps was too quick to notice.)

@Marcia, given your comment about Norton extensions AND since I hadn't updated the LAPTOP yet to FF 66.0.3, I did some version-checking first. Short story: old versions of extensions, no effect on FF update, no crash window -- but there may be a critical difference in setting.

FF was 66.0.2 (I knew that). Norton SafeWeb was 3.7.0.6 and SafeSearch was 3.1.0.20 -- both last updated several weeks/months ago. I checked and found updates were available for both. Both had update settings set to "Default" -- whatever that means -- of choices Default/On/Off. I did not do any of these updates -- I wanted to see if their being out-of-date might have an effect on an FF crash.

I ran the Firefox update (from HELP/ABOUT) and it ran smoothly, normally, with no sign of the FF crash screen. Norton extensions were unchanged (so the default update is not by the FF update mechanism).

Then I manually ran a Norton update (this gets run every morning anyway after a waking up the Laptop) -- no change to the extensions either. So then I checked for Extension Updates again -- available -- so I installed them. Norton SafeWeb is now 3.7.0.11 and SafeSearch is now 3.7.0.21, both now stamped as installed today.

And back to the Tower: The Norton extensions had already been updated various days ago -- not be me, I have no log of doing either of them -- so both were current when I ran the FF update which gave the crash window.

As it happens, the ADD-ONs page has a setting for installing updates automatically. It was turned ON for the Tower (so it was current), and OFF for the Laptop (so it was a little out-of-date). But of course this also means FF had to try to install updates for ANY extensions and add-ons on the Tower -- inviting a crash -- but not so on the Laptop. Hmmmm...

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(robert.strong.bugs)
Component: Application Update → Widget: Win32
Flags: needinfo?(robert.strong.bugs)
Product: Toolkit → Core
Summary: Firefox crash window appears after update → Firefox crash [@ CLocalEndpointEnumerator::OnMediaNotification ] after update

I've been running FF 66.0.3 and suddenly a few days ago -- without any tangible update or event -- it disabled all the extensions & themes on my Tower (but not on the Laptop).

Yesterday I upgraded to FF 66.0.4 on the Tower and the crash event still happens. The pop-under window activated after the normal "Applying updates..." popup disappeared, a few seconds after I clicked the button to "Restart Now". Other than the pop-under, everything went smoothly, the update was installed successfully, and my extensions were viable again.

About:crashes: "bp-6a590a4e-a9fe-4656-9bb8-5f1af0190506" Submitted "06/05/2019, 9:41 a.m"

And today I put 66.0.4 on the Laptop -- as usual, no crash window. Further to Comment #5, the ADD-ONs page's setting for installing updates automatically was turned ON (checked) in the dropdown for both machines this time, yet the Laptop still did not experience the crash window.

I just updated my Tower to FF 66.0.5 (from recent 66.0.4) and paid very close attention to settings and timing. The setting to install automatic updates was checked (as always), and I ran in full standard mode (no private window this time which is how I often run FF). I used the normal public update Help/About procedure as usual.

The crash window appeared AFTER "Restart FF to update..." button and "Updating..." popup and the opening (relaunch) of the new FF. There was a delay of a few seconds after the new FF window opened before the crash window pop-under appeared in the Windows taskbar -- long enough to think the crash window wouldn't occur this time, but it did.

About:crashes: "bp-bc1094ec-cbfe-456f-b7ed-311d30190508" Submitted "08/05/2019, 10:38 a.m."

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)

Is THIS bug by chance an evolution of my Bug #1312738? I was experiencing updates where the new version did not carry out the updating when re-launch was clicked -- the old simply re-loaded and ran -- had to manually close FF and relaunch manually from the icon. (The previous bug occurred on both my Tower and my Laptop too.)

Appears to have something to do with child process startup. Do you run an A/V product? I see something named IPSEng32.dll in the main thread stack for these crashes. The actual crash happens in a video driver thread we don't create.

Component: Widget: Win32 → DOM: Content Processes
Flags: needinfo?(jmathies)
Priority: -- → P2

I run NORTON SECURITY for my anti-virus/anti-spam -- Version 22.17.1.50, always up to date. There are three copies of this DLL file -- all dated 18 April 2019 3:55pm -- in one of the Norton folders in C:\PROGRAM FILES.

See Comment #4. I'm having on-going issues with Norton Updates failing occasionally over the past almost three years (including right now as I type this) -- but Norton tech support (Level 1 and now Level 2) have removed / cleaned / reinstalled the product several times. The product runs on our Laptop too -- occasionally experiencing the update issues but not nearly as often as in the past.

As for video, etc: I use whatever FF invokes internally for web viewing. My default external video program is VLC Media Player v3.0.6, and of course the standard Microsoft Windows Media Player for music (mainly) & video (occasionally). I use Photoshop 12.0.4 (x32) -- part of their CS Suite 5.0. And I occasionally use Nero v8 (from 2008) for ripping my CDs to MP3.

(I also run Google Chrome, mainly for in-house webpage edits. I only rarely run video with it.)

FYI, the problem still exists on the most recent FF updates on both my tower and laptop. Running Windows 7 / 32-bit on Dell PCs.

AND... it just happened minutes ago when I updated Thunderbird from 68.1.0 to 68.1.1 using TB's standard HELP, ABOUT update procedure. I don't recall ever seeing this on TB before (although long ago I had some updates fail to apply on first attempt).

...And again tonight just now (FF 69.0.1 to 69.0.2) and every FF update previous, and also again on Thunderbird (68.1.1 to 68.1.2).

FYI, it so happens I have a Symantec (Norton AV) diagnostic logger running at the moment, and it was running at the time of my Comment 13. One might suspect it of causing the issue with TB these last two times, but I'd like to I plead coincidence because the same issue has been going on with FF for a long time -- long before the Symentec logger came into the picture.

It is now middle of November 2020 and I thought you'd all like to know that I haven't seen this crash during Firefox updates for quite some time -- I'd say about a year -- on either of my machines.

However, the crash has occurred on EVERY update of Thunderbird on my Tower since first reported on 2019-09-27 in Comment #13, including the just-released TB 78.4.2. (The Laptop runs fine with no evidence of a crash.) I'm guessing that whatever update processes the TB crew borrowed from FF was a little bit faulty and they didn't import the fix.

FYI, I'm now running Bitdefender as my AV, so Norton is out of the picture and obviously not the culprit. I'm still running Firefox and it runs OK now, so I think something changed there. So whatever the disease, Thunderbird caught it and Firefox was cured. Note that the issue is never fatal to the new install, just a PITA seeing and commenting every crash. And just to be clear, I'm using the standard user HELP, ABOUT update procedure.

What are your most recent crash IDs?

Flags: needinfo?(dannyfox)

Here is the lot of them, all Thunderbird crashes during updates (some no longer view):
bp-65eb834b-62dd-4f4a-8994-7df3a0201110 10/11/2020 2:12 a.m.
bp-43e8eb8b-7251-4f44-b541-e09200201107 07/11/2020 9:36 a.m.
bp-a4dd7b34-4e44-4e52-814f-0c5100201023 22/10/2020 8:34 p.m.
bp-d62f982b-a5fd-4fbe-9b87-d75560201020 20/10/2020 11:02 a.m.
bp-e9bf6821-a710-49f6-9103-bf4910201008 07/10/2020 10:23 p.m.
bp-7c91ba18-64f0-4265-9ca2-6506f0201002 02/10/2020 10:33 a.m.
bp-5cfa22ee-2f6e-4ec1-83d9-317ea0200917 17/09/2020 2:07 p.m.
bp-8fbb3186-bdda-4804-ac27-0fd2c0200827 27/08/2020 6:08 p.m.
bp-a862b86a-7c83-4df2-933d-f530f0200730 29/07/2020 10:11 p.m.
bp-f248f0a4-7c88-42e5-88e0-758940200702 02/07/2020 10:43 a.m.
bp-f56a5b4e-3ba7-4024-b097-78e960200611 11/06/2020 5:15 p.m.
bp-2b1232de-f1ee-4f93-8309-6667a0200604 04/06/2020 12:58 p.m.
bp-5af55fe9-6b86-4dae-afd9-d489e0200523 23/05/2020 9:37 a.m.
bp-c1374279-2e75-406a-9ff0-7c3800200508 08/05/2020 11:51 a.m.
bp-9bc0891b-28d7-401c-b290-73fdf0200408 08/04/2020 1:29 p.m.
bp-2c314d70-f042-4840-b296-8a7090200314 13/03/2020 9:43 p.m.
bp-676590b0-b541-4ce9-9f65-87f5b0200212 12/02/2020 4:28 p.m.
bp-33cc596f-6544-4f73-939b-ad5510200131 31/01/2020 10:16 a.m.
bp-4e574bd8-66de-4916-8dc1-6808b0200110 10/01/2020 10:57 a.m.
bp-1340ffe3-bad7-4c1e-b528-de04d0200110 10/01/2020 10:57 a.m.
bp-a4fee210-31bd-48ab-a2b8-3eafa0191205 05/12/2019 9:02 a.m.
bp-274c9edc-6602-4b79-a365-cbcb30191130 30/11/2019 9:43 a.m.
bp-71816417-7085-466d-a9a2-604fd0191109 08/11/2019 9:09 p.m.
bp-7fefbe80-6a25-4f16-a1de-be49e0191108 08/11/2019 11:59 a.m.
bp-1796af8d-b7cf-454f-8e05-d86ce0191105 05/11/2019 12:43 p.m.
bp-4acdc49f-55d5-4866-b1cc-ded040191024 24/10/2019 1:14 p.m.
bp-44a966d0-1aff-41cf-97ea-b63500191012 12/10/2019 1:54 a.m.
bp-dc3a392d-e786-4127-95c7-dc9470190927 27/09/2019 12:03 p.m.

Two not submitted (crashed, but had other issues updating from TB 68.3.1 to 68.4.1) on 10 Jan 2020:
a6bc0c34-24cf-4dfa-97fd-52d49e70fec8 10/01/2020 10:59 a.m.
02935437-7c7c-4abd-93ab-751a0c3fe4d9 10/01/2020 10:58 a.m.

Otherwise latest crash was in January 2017 (totally unrelated to above sequence):
bp-183cc5c0-f8a3-4524-8b08-0b3002170131 31/01/2017 12:43 p.m.

Flags: needinfo?(dannyfox)

Crashed just now updating 78.4.3 to 78.5.0: bp-cfdf02a5-a4c5-4d37-881f-1e9230201118 18/11/2020, 6:20 p.m.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Whiteboard: [tbird crash]

Crashed a few hours ago updating from 78.5.0 to 78.5.1: bp-fdc66bc5-0ba0-46b9-b900-ae5370201205 05/12/2020, 2:26 p.m.
(Crash reporter was buried and report was not submitted until a few minutes ago.)

I sampled all 8 Thunderbird crashes from the past week, bitdefender and avast have two each, two have no non-Windows AV dlls listed, one each CRYPTO-PRO, trend-micro. The long term crash rate trend of the past 6 months is flat.

Crash Signature: [@ @0x0 | CLocalEndpointEnumerator::OnMediaNotification ]

Crashed just now updating 78.7.0 to 78.7.1: bp-aab65c72-d451-498a-bebc-0e5330210207 06 Feb 2021 8:22 pm EST

Also has crashed every update on my tower PC since last reported (78.5.1). Yet it rarely if ever crashed on the PC laptop now.
Both machines running Windows 7/32 Pro.

(clearly this isn't P2, no one has touched it in years)

Still happening with a current version of Firefox or Thunderbird?

Flags: needinfo?(dannyfox)
Priority: P2 → --

The crashes had stopped on our Laptop PC as mentioned in Comment 21.

I have not seen these crashes in Firefox on my Tower PC lately, not for well over a year in fact. Last crash that I logged was 29-Jul-2020 upgrading from FF 78.0.2 to 79.0, and that is also the top of the list of crashes submitted to the Firefox Command Center. Next update was 26-Aug-2020 (from 79.0 to 80.0) for which I specifically noted "no crash this time", followed by update to FF 80.0.1 on 02-Sep-2020, ditto no crash. And none since that I recall.

Meanwhile, similar crashes in Thunderbird continued on every update through to 23-Sep-2021 (78.14.0 to 91.1.1). First crashless update was going from TB 91.1.1 to 91.1.2 on 28-Sep-2021 (not explicitly noted -- just first log entry that didn't say crashed) and I haven't seen a crash since then.

FYI, still running Windows 7/32 Pro (with Aero) on both machines, with Norton Security on the Laptop and Bitdefender on the Tower.
(FF does have mouse-hesitancy issues with BD's Anti-Tracker add-on -- started immediately following upgrade FF 89.0 on 04-Jun-2021 -- but this is likely not related to the crashes.)

Flags: needinfo?(dannyfox)

I'm "Not Authorized" to see Bug 1540883, so I can't comment on any relationship there.

As for crashes, they have never recurred on Firefox since FF 79 in July 2021, and nothing on Thunderbird since TB 91.1.2 in Sept 2021, clean right through to the current TB 91.12.0 on our Tower.

From what I've seen, TB 102 has been OK here with regard to crashes -- haven't seen any on our Laptop (which is running TB 102.1.2) -- but that doesn't mean they won't happen just for spite on the Tower (once I upgrade).

Severity: normal → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year 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: