Closed Bug 1628452 Opened 2 years ago Closed 2 years ago

Upgrade on 8 April 2020 failed to find The procedure entry point ??0MutexImpl@detail@mozilla@@QEAA@XZ could not be located in the dynamic link library C:\Program Files\Firefox\xul.dll.


(Toolkit :: Application Update, defect, P3)

75 Branch





(Reporter: v+mozbug, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

I generally start several copies of Firefox using different profiles when my computer boots up in the morning. So I turned on my computer.

Actual results:

This morning, there was a firefox update available. Two of the profiles were successful in starting the old version, no doubt they both started updating, and must have gotten far enough fast enough to cause problems for all the others. When I came back to look at the computer after turning it on, I found those two, running, but About Help indicated I should restart to update. The others had all crashed with a dialog stating:

The procedure entry point ??0MutexImpl@detail@mozilla@@QEAA@XZ could not be located in the dynamic link library C:\Program Files\Firefox\xul.dll.

I closed all those dialogs (which produced another dialog "Couldn't load XPCOM", closed it too), and then there was no sign of those instances of firefox.

I clicked restart on the two instances that were running, and ready to update, and they each then crashed in the same manner.

After all firefox instances were crashed and gone, as above, I started one of them manually (instead of the batch file that usually does it), and it crashed in the same manner. I tried several times with no change in behavior.

I have DevEd and Nightly both installed, they each started fine, noticed the update, I clicked restart, and they restarted fine with the new version. But this one one copy of each, done sequentially.

It would seem that the interlock between different instances of firefox updating concurrently has broken, or else the new release today is simply broken.

Expected results:

They should have all started up, with the old or new version of firefox without crashing. Generally in the past when updates occurred, I would find one copy ready to restart for the update, sometimes one or more copies would report that firefox was being updated by another instance, and sometimes one ore more copies would be running the new version (not often).

I marked this bug as 75 branch, because I'm writing the bug report with 76 branch (DevEd).

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Application Update
Product: Firefox → Toolkit

Turned on a different computer that only loads one copy of Firefox. The upgrade process went fine, as did the restart afterwards. So it does seem that this problem only affects upgrades when other copies of Firefox are running or trying to start.

we had a few users on sumo reporting the same problem as well - apparently a reinstall did solve the issue for them:

A reinstall solved my crashing issue also, but doesn't solve the bug in the upgrade process, of course.

There is indeed a race condition when starting multiple instances at the same time while there's an update waiting to be applied; we don't really make any effort to synchronize those instances or to make sure that only one tries to apply the same update. So that does seem like the most likely cause of this problem.

It wasn't prompted by exactly the same scenario, but I think bug 1553982 would also be able to address this, so I'm calling this bug a duplicate of that one.

Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1553982
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.