Closed Bug 1431916 Opened 2 years ago Closed 1 year ago
Nightly doesn't boot after installing update
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180119220144 Steps to reproduce: I opened the about nightly window. An update is available. I close it, close Firefox (not by pressing the update button for restart) I wait, till Firefox is done (watching the task manager) I start Firefox Actual results: I can see that the update is being installed, by watching the task manager and so on. Once the update was installed, the normal firefox.exe started, but nothing happend. 0% cpu usage for 1 or 2 processes and barely any RAM. It stays that way no matter what. I usually force close the process using the task manager then, and start Firefox again by double clicking the Icon. Firefox instantly boots up. I recorded this in a video on YouTube, so you can see what I mean. https://www.youtube.com/watch?v=KMlvBiykEH8 This issue is not new, but has been fixed in the past (months back) and now I'm sad, that it's back. (regression or coincidence?) I'm using the localized German Nightly from: https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/firefox-59.0a1.de.win64.installer.exe I'm very sure, that this is only happening in Nightly and not in the normal (US?) Nightly only in the German one. Other localized variants might be affected, too. I'm using Win 10 64bit Education Edition
I see a couple of interesting things in your video: 1) The updater took a very long time to get itself started. It sat in the background without starting the second (elevated) process for 30 seconds, and then that process took another 30 seconds before it actually started doing anything. Neither of those should happen, and it's very weird that each delay is so close to 30 seconds. To me this strongly suggests interference by something else on the system (or else an extremely slow computer, which you don't seem to have). 2) Something in the background is using a lot of your CPU; I don't know your CPU specs, but usually CPU usage being locked at 13-14% like that means something is using an entire core. I don't see anything running in the foreground that would need that much CPU, so it must be a background task. I think I see an Avast icon in your notification area; is there an Avast process using all that CPU time? If so, that might explain this problem as well; if Avast is that bogged-down, it could be holding up the updater and/or the browser to do some of its resident scanning.
1) I just observed the install of nightly 60: 30 seconds, till the update windows is shown another 30 seconds for the install, then the software updater is closed but Firefox doesn't start correctly. I'm using an i7 6700k and a Samsung 950pro => fast cpu and fast drive 2) that's actually ffmpeg using gdigrab to grab the screen and the qtrle codec for encoding the screen ^^ (1440p pixels with a single-threaded codec), I just removed the first few seconds of the video that showed the command line The 1 minute I just observed the installer in 1) without grabbing the screen, the CPU hovered between 0-8% CPU usage. I could do another recording with a hardware encoder, but I don't think that the issue lies here. I'll try disabling avast from scanning for the next time I'm installing though (just in-case) maybe it interferes somehow (1) I'll install the english nightly now, just to test again, if that makes the issue disappear.
My observations so far: Installing the nightly from https://www.mozilla.org/de/firefox/channel/desktop/ actually gave me the german version, when using the german version of Firefox Installing updates by pressing restart and update sometimes took only 5-10 seconds after that. Then it was slower again. (I didn't change anything) 35 seconds till install window, 30 seconds for installer, then nothing till force close Installing https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-60.0a1.en-US.win64.installer.exe didn't fix it, so I'm returning now to: I don't know what triggers it. Using a fresh profile doesn't change anything. Mmh. I waited a few days to continue observing it a few more times. today (version 2018-02-05) I started the fresh profile, opened about info to download the update. closed that. Closed firefox. then I started Firefox again with the fresh profile (with Antivirus avast on) and it tooks 3-4 seconds including the install of the update for Firefox to boot up (just guessed the amount of seconds, because I didn't expect it to boot up this fast again) Is there a way to tell Firefox and the background updater to generate a verbose log, that I could provide here for analysis?
Would it help, if I upload memory dumps from the following path? "C:\Users\username\AppData\Roaming\Mozilla\Firefox\Crash Reports"
According to process explorer the main thread (I think), is stuck in state WrUserRequest. And the 2nd thread is stuck in WrQueue I attached a log by process monitor that might help. It's filtered by firefox.exe and starts after the updater programm is closed (I cleared everything while it was running) Then I started process explorer at 17:59:xx and then exactly after that both threads got closed (you can see the big time gap of 3 minutes in the log, where both threads do nothing, it's right at the end) If you would like to see a different log, just tell me. I'm ready to provide all the info you need to fix this bug :) What I noticed: Firefox reads data from at least 3 softwares on my computer (because they attached their dll's to firefox, I guess): Avast (virus scanner) Asus (software that came with my mainboard) Nvidia (graphics card)
If I could, then I would debug this with visual studio somehow. I have it installed, I know how to debug and could take a look at which point in the code, it gets into this dead lock. The problem is: Is it even possible to simulate the boot up process after updates with self-compiled builds in visual studio? Probably not, right?
You wouldn't necessarily need to use your own build, if you set up our symbol server (https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server). That way you can debug official releases, and you'll get all the symbols you need. Failing that, I'd certainly be happy to look at your crash dumps. Thanks for all the info, this is awesome. I see that Avast is injecting itself very very early in process initialization, but I imagine that's what it always does. And if the Nvidia overlay and whatever this Asus thing is are doing anything unusual, I can't see it from the Process Monitor log. Something strange is definitely going on though, our process is barely even getting initialized before that hang happens, not very much Firefox code is ever getting to run.
Somehow fixed itself by now. Either Avast, or Windows, or Firefox Nightly got an update that corrected the behavior.
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.