Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID : 20170615030208 STR: close nightly (Ctrl-Q, Alt-F4, menu, top-right button, whatever...) AR: Windows displays a crash report for "firefox.exe" ER: no crash ! Since nightly build from June 15th 2017, Windows displays a crash report each time I close Firefox. It is systematic and happens even with a new clean profile without any addons nor plugins. It must be completely silent to Mozilla as there is nothing reported in about:crashes. Moreover, both updates to 20170617 and 20170618 builds hanged requiring to kill "firefox.exe" from the task manager to unlock the situation and see "updater.exe" running. Since this behavior appeared with the same build as the crash I assume it is linked to the same shutdown bug (if it is not them I will file a new bug). Another user from Mozillazine's forum (DJ-Leith) seems to encounter this bug: http://forums.mozillazine.org/viewtopic.php?f=23&t=3031109&sid=f44512dd9bbbb85c3d52be3e8f6fb558 Like him, I launch Firefox using the "-profile -no-remote" command line.

Thanks, Franck (Wip) for reporting. I am adding additional information. Some is to clarify (or correct) what I posted in http://forums.mozillazine.org/viewtopic.php?f=23&t=3031109 Please read that short thread. 1. When doing my 'normal Update' of Nightly, by using Menu, Help, "About Nightly" to see if the 'en-GB' Nightly was available, on 2017-06-16, I DID have difficulty (like "Are You A Wiiizard?" posted at "Post Posted June 16th, 2017, 11:07 am") http://forums.mozillazine.org/viewtopic.php?p=14752413#p14752413 In my case, I used (Windows 7) Task Manager to stop Firefox. Eventually I did manage to update to 2017-06-16 Nightly Name Firefox Version 56.0a1 Build ID 20170616030207 Update Channel nightly User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 OS Windows_NT 6.1 As my usage of Firefox is 'untypical': I have several Extensions that won't work under E10s, and I launch ALL my Profiles, using specific 'Windows shortcuts' with the actual Profile that I wish to use (as documented in the thread at mozillazine), I did not file a bug. 2. Since then, using 2017-06-16 build, I have noticed the following. 2.1 No matter how I stop, or Restart, Nightly, it always is detected by Windows 7 as a 'crash'. A "Nightly has stopped working" modal window. However, there are no 'Firefox crash reports' on any of my Profiles. 2.2 If you Restart an instance, for example by using "about:addons" and updating an Extension that needs a Restart, Nightly will restart AND you also get a 'Windows 7 report' that "Nightly has stopped working". In Task Manager there is an extra "firefox.exe". I can stop this and the Profile I am using will 'keep on being used'. 2.3 On Saturday, while trying to Update Nightly from 2017-06-16 to 2017-06-17, this always failed. Using Task Manager (with "Show processes from all users") I don't see the Maintenance Service starting. Normally, I use Nightly as a 'normal non-admin User' and I do the Updates. Even using a Windows Admin account I could not update Nightly to 2017-06-17. I only allow Admins to update ESR and Release. I have moved all the Users, who I support, to ESR because of the 'legacy Extensions' that we wish to keep on using. I have ESR and Release Profiles on this PC in addition to my Nightly Profiles. Some are in 'non standard places', i.e. NOT in "C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\ ..." for testing. All are still working. I can still, as I have for years, run several Firefox instances at the same time each with their own Profile, set of Extensions, preferences etc. Of course, the shortcuts specify the application (e.g. ESR, Nightly etc) as well as the path to the specific profile. I take care to only have ONE instance of the application running when I attempt an Update. I speculate that 'Nightly is shutting down too fast' and that is why 'Windows 7 thinks it has gone away'. I (and my users) have old hardware and a synchronous Shutdown (or Restart) of Firefox is good for preventing data loss (including updating "prefs.js"). So I see "Nightly has stopped working" <== reported by Windows 7 but no 'Firefox crash report'. DJ-Leith

I can confirm that I am unable to update nightly since the 2017-06-15 build (I am using Windows 10, 64-bit for both Nightly and Windows) . However, in my case it is somewhat different, I didn't have the crashes you mentioned. When I click the update button in the Help about Nightly dialog box, Firefox Nightly just closes, but doesn't restart. When I launch it manually after that, no update is applied . The task manager doesn't show any leftover processes requiring to kill them, as mentioned above, and there are no Windows dialogs about a crash, or crash reports that Firefox tries to send. Also, about:crashes doesn't show any crashes. As a workaround, I downloaded the updated Nightly installation file and updated Firefox manually ...

It seems that the update problem was fixed for now. I updated successfully from the 2017-06-18 to the 2017-06-19 build.

Having similar/same issue. Closing Nightly normally, i.e. not force quitting, causes Windows to report that Nightly has crashed. Occasionally Nightly will actually close properly, but most of the time the UI process will go away but all the processes running the web content will stay and have to be terminated manually before Nightly can be launched again. I have this issue with or without using a clean profile. Something of note is that on my work computer I run the same addons and settings for Nightly but do not have this issue. Really the only major difference I can think of is my work computer runs Windows Server and not the consumer version of Windows. Cheers, Meinert ---Windows Error Report--- Version=1 EventType=BEX64 EventTime=131424687123076856 ReportType=2 Consent=1 ReportIdentifier=bc55d398-5601-11e7-9a4e-dc85de25fabe IntegratorReportIdentifier=bc55d397-5601-11e7-9a4e-dc85de25fabe Response.type=4 Sig[0].Name=Application Name Sig[0].Value=firefox.exe Sig[1].Name=Application Version Sig[1].Value=56.0.0.6380 Sig[2].Name=Application Timestamp Sig[2].Value=59490313 Sig[3].Name=Fault Module Name Sig[3].Value=StackHash_1dc2 Sig[4].Name=Fault Module Version Sig[4].Value=0.0.0.0 Sig[5].Name=Fault Module Timestamp Sig[5].Value=00000000 Sig[6].Name=Exception Offset Sig[6].Value=0000000000000000 Sig[7].Name=Exception Code Sig[7].Value=c0000005 Sig[8].Name=Exception Data Sig[8].Value=0000000000000008 DynamicSig[1].Name=OS Version DynamicSig[1].Value=6.1.7601.2.1.0.256.48 DynamicSig[2].Name=Locale ID DynamicSig[2].Value=1033 DynamicSig[22].Name=Additional Information 1 DynamicSig[22].Value=1dc2 DynamicSig[23].Name=Additional Information 2 DynamicSig[23].Value=1dc22fb1de37d348f27e54dbb5278e7d DynamicSig[24].Name=Additional Information 3 DynamicSig[24].Value=eae3 DynamicSig[25].Name=Additional Information 4 DynamicSig[25].Value=eae36a4b5ffb27c9d33117f4125a75c2 UI[2]=C:\Program Files\Nightly\firefox.exe UI[3]=Nightly has stopped working UI[4]=Windows can check online for a solution to the problem. UI[5]=Check online for a solution and close the program UI[6]=Check online for a solution later and close the program UI[7]=Close the program LoadedModule[0]=C:\Program Files\Nightly\firefox.exe LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll LoadedModule[2]=C:\Program Files\AVAST Software\Avast\x64\aswhooka.dll LoadedModule[3]=C:\Program Files\AVAST Software\Avast\snxhk64.dll LoadedModule[4]=C:\Windows\system32\KERNEL32.dll LoadedModule[5]=C:\Windows\system32\KERNELBASE.dll LoadedModule[6]=C:\Program Files\Nightly\mozglue.dll LoadedModule[7]=C:\Windows\system32\dbghelp.dll LoadedModule[8]=C:\Windows\system32\msvcrt.dll LoadedModule[9]=C:\Windows\system32\VERSION.dll LoadedModule[10]=C:\Program Files\Nightly\MSVCP140.dll LoadedModule[11]=C:\Program Files\Nightly\VCRUNTIME140.dll LoadedModule[12]=C:\Program Files\Nightly\api-ms-win-crt-runtime-l1-1-0.dll LoadedModule[13]=C:\Program Files\Nightly\ucrtbase.DLL LoadedModule[14]=C:\Program Files\Nightly\api-ms-win-core-timezone-l1-1-0.dll LoadedModule[15]=C:\Program Files\Nightly\api-ms-win-core-file-l2-1-0.dll LoadedModule[16]=C:\Program Files\Nightly\api-ms-win-core-localization-l1-2-0.dll LoadedModule[17]=C:\Program Files\Nightly\api-ms-win-core-synch-l1-2-0.dll LoadedModule[18]=C:\Program Files\Nightly\api-ms-win-core-processthreads-l1-1-1.dll LoadedModule[19]=C:\Program Files\Nightly\api-ms-win-core-file-l1-2-0.dll LoadedModule[20]=C:\Program Files\Nightly\api-ms-win-crt-string-l1-1-0.dll LoadedModule[21]=C:\Program Files\Nightly\api-ms-win-crt-heap-l1-1-0.dll LoadedModule[22]=C:\Program Files\Nightly\api-ms-win-crt-stdio-l1-1-0.dll LoadedModule[23]=C:\Program Files\Nightly\api-ms-win-crt-convert-l1-1-0.dll LoadedModule[24]=C:\Program Files\Nightly\api-ms-win-crt-locale-l1-1-0.dll LoadedModule[25]=C:\Program Files\Nightly\api-ms-win-crt-math-l1-1-0.dll LoadedModule[26]=C:\Program Files\Nightly\api-ms-win-crt-multibyte-l1-1-0.dll LoadedModule[27]=C:\Program Files\Nightly\api-ms-win-crt-time-l1-1-0.dll LoadedModule[28]=C:\Program Files\Nightly\api-ms-win-crt-filesystem-l1-1-0.dll LoadedModule[29]=C:\Program Files\Nightly\api-ms-win-crt-environment-l1-1-0.dll LoadedModule[30]=C:\Program Files\Nightly\api-ms-win-crt-utility-l1-1-0.dll LoadedModule[31]=C:\Windows\system32\ADVAPI32.dll LoadedModule[32]=C:\Windows\SYSTEM32\sechost.dll LoadedModule[33]=C:\Windows\system32\RPCRT4.dll LoadedModule[34]=C:\Program Files\Nightly\nss3.dll LoadedModule[35]=C:\Windows\system32\WINMM.dll LoadedModule[36]=C:\Windows\system32\USER32.dll LoadedModule[37]=C:\Windows\system32\GDI32.dll LoadedModule[38]=C:\Windows\system32\LPK.dll LoadedModule[39]=C:\Windows\system32\USP10.dll LoadedModule[40]=C:\Windows\system32\WSOCK32.dll LoadedModule[41]=C:\Windows\system32\WS2_32.dll LoadedModule[42]=C:\Windows\system32\NSI.dll LoadedModule[43]=C:\Windows\system32\IMM32.DLL LoadedModule[44]=C:\Windows\system32\MSCTF.dll LoadedModule[45]=C:\Program Files\Nightly\lgpllibs.dll LoadedModule[46]=C:\Program Files\Nightly\xul.dll LoadedModule[47]=C:\Windows\system32\SHELL32.dll LoadedModule[48]=C:\Windows\system32\SHLWAPI.dll LoadedModule[49]=C:\Windows\system32\AVRT.dll LoadedModule[50]=C:\Windows\system32\ole32.dll LoadedModule[51]=C:\Windows\system32\MSIMG32.dll LoadedModule[52]=C:\Windows\system32\IPHLPAPI.DLL LoadedModule[53]=C:\Windows\system32\WINNSI.DLL LoadedModule[54]=C:\Windows\system32\CRYPT32.dll LoadedModule[55]=C:\Windows\system32\MSASN1.dll LoadedModule[56]=C:\Windows\system32\dwmapi.dll LoadedModule[57]=C:\Windows\system32\UxTheme.dll LoadedModule[58]=C:\Windows\system32\SETUPAPI.dll LoadedModule[59]=C:\Windows\system32\CFGMGR32.dll LoadedModule[60]=C:\Windows\system32\OLEAUT32.dll LoadedModule[61]=C:\Windows\system32\DEVOBJ.dll LoadedModule[62]=C:\Windows\system32\WINTRUST.dll LoadedModule[63]=C:\Windows\system32\WTSAPI32.dll LoadedModule[64]=C:\Windows\system32\ntmarta.dll LoadedModule[65]=C:\Windows\system32\WLDAP32.dll LoadedModule[66]=C:\Windows\system32\CRYPTBASE.dll LoadedModule[67]=C:\Windows\system32\dwrite.dll LoadedModule[68]=C:\Windows\system32\CLBCatQ.DLL LoadedModule[69]=C:\Windows\system32\Dnsapi.dll LoadedModule[70]=C:\Windows\system32\NLAapi.dll LoadedModule[71]=C:\Windows\system32\napinsp.dll LoadedModule[72]=C:\Windows\system32\pnrpnsp.dll LoadedModule[73]=C:\Windows\System32\mswsock.dll LoadedModule[74]=C:\Windows\System32\winrnr.dll LoadedModule[75]=C:\Windows\system32\wshbth.dll LoadedModule[76]=C:\Program Files\Bonjour\mdnsNSP.dll LoadedModule[77]=C:\Windows\System32\wshtcpip.dll LoadedModule[78]=C:\Windows\system32\dhcpcsvc.DLL LoadedModule[79]=C:\Windows\system32\wbem\wbemprox.dll LoadedModule[80]=C:\Windows\system32\wbemcomn.dll LoadedModule[81]=C:\Windows\system32\CRYPTSP.dll LoadedModule[82]=C:\Windows\system32\rsaenh.dll LoadedModule[83]=C:\Windows\system32\RpcRtRemote.dll LoadedModule[84]=C:\Windows\system32\wbem\wbemsvc.dll LoadedModule[85]=C:\Windows\system32\wbem\fastprox.dll LoadedModule[86]=C:\Windows\system32\NTDSAPI.dll LoadedModule[87]=C:\Windows\system32\profapi.dll LoadedModule[88]=C:\Windows\System32\Wpc.dll LoadedModule[89]=C:\Windows\System32\USERENV.dll LoadedModule[90]=C:\Windows\System32\wevtapi.dll LoadedModule[91]=C:\Windows\system32\samcli.dll LoadedModule[92]=C:\Windows\system32\SAMLIB.dll LoadedModule[93]=C:\Windows\system32\netutils.dll LoadedModule[94]=C:\Windows\system32\WINSTA.dll LoadedModule[95]=C:\Windows\system32\dxgi.dll LoadedModule[96]=C:\Windows\system32\d2d1.dll LoadedModule[97]=C:\Windows\system32\XmlLite.dll LoadedModule[98]=C:\Windows\system32\mscms.dll LoadedModule[99]=C:\Windows\system32\apphelp.dll LoadedModule[100]=C:\Windows\System32\MMDevApi.dll LoadedModule[101]=C:\Windows\System32\PROPSYS.dll LoadedModule[102]=C:\Windows\system32\AUDIOSES.DLL LoadedModule[103]=C:\Program Files\Nightly\freebl3.dll LoadedModule[104]=C:\Program Files (x86)\DisplayFusion\Hooks\AppHookWIN6064_87DEA607-431A-48D2-A932-98C5464BFCC5.dll LoadedModule[105]=C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\COMCTL32.dll LoadedModule[106]=C:\Windows\system32\PSAPI.DLL LoadedModule[107]=C:\Windows\system32\explorerframe.dll LoadedModule[108]=C:\Windows\system32\DUser.dll LoadedModule[109]=C:\Windows\system32\DUI70.dll LoadedModule[110]=C:\Windows\system32\WININET.dll LoadedModule[111]=C:\Windows\system32\urlmon.dll LoadedModule[112]=C:\Windows\system32\iertutil.dll LoadedModule[113]=C:\Windows\system32\SspiCli.dll LoadedModule[114]=C:\Windows\system32\RASAPI32.dll LoadedModule[115]=C:\Windows\system32\rasman.dll LoadedModule[116]=C:\Windows\system32\rtutils.dll LoadedModule[117]=C:\Windows\system32\sensapi.dll LoadedModule[118]=C:\Windows\System32\wship6.dll LoadedModule[119]=C:\Windows\system32\rasadhlp.dll LoadedModule[120]=C:\Windows\System32\fwpuclnt.dll LoadedModule[121]=C:\Windows\system32\LINKINFO.dll LoadedModule[122]=C:\Windows\system32\ntshrui.dll LoadedModule[123]=C:\Windows\system32\srvcli.dll LoadedModule[124]=C:\Windows\system32\cscapi.dll LoadedModule[125]=C:\Windows\system32\slc.dll LoadedModule[126]=C:\Program Files\Nightly\mozavutil.dll LoadedModule[127]=C:\Program Files\Nightly\mozavcodec.dll LoadedModule[128]=C:\Windows\system32\mfplat.dll LoadedModule[129]=C:\Windows\system32\mf.dll LoadedModule[130]=C:\Windows\system32\ATL.DLL LoadedModule[131]=C:\Windows\system32\ksuser.dll LoadedModule[132]=C:\Windows\system32\dxva2.dll LoadedModule[133]=C:\Windows\system32\evr.dll LoadedModule[134]=C:\Windows\system32\POWRPROF.dll LoadedModule[135]=C:\Windows\System32\msmpeg2adec.dll LoadedModule[136]=C:\Windows\System32\msmpeg2vdec.dll LoadedModule[137]=C:\Windows\System32\bcrypt.dll LoadedModule[138]=C:\Windows\system32\DEVRTL.dll FriendlyEventName=Stopped working ConsentKey=BEX64 AppName=Nightly AppPath=C:\Program Files\Nightly\firefox.exe

Ryan/Sylvestre/Matt, can one of you forward this to the right nightly/update/crash diagnostics folks?

I don't think this is updater related; it seems to be happening on every shutdown whether it's a restart for an update or not.

data dump from about:support

(In reply to nivtwig from comment #3) > It seems that the update problem was fixed for now. > I updated successfully from the 2017-06-18 to the 2017-06-19 build. Contrary to what I said on comment #3, the update problem was NOT fixed. On another computer I manually installed Nightly 2017-06-21, but I can't get it to update to 2017-06-22. When clicking to update, nightly just exits, but doesn't restart, and when I restart manually it doesn't install the update. My update settings are: not using a background service to install updates . "Check for updates but let you choose to install them" client and OS: 56.0a1 (2017-06-21) (64-bit) Windows 10 64-bit

As far as I can tell, the BEX64 exception is DEP-related, which probably explains why our own crash reporter isn't able to catch these crashes. Per IRC discussion with froydnj and tjr, this might be a dupe of bug 1374038. Given that this is going to be a pain to debug with only Windows Error Reporting catching the crash, I think we should see if the patch there fixes this. Otherwise, we'll probably need to try to get a dump from Windows for further analysis. https://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx has info on that.

I think the UNCONFIRMED status should be updated to NEW considering the reports here

I have been away and so I have not had time to update this bug. (In reply to Matt Howell [:mhowell] from comment #6) > I don't think this is updater related; it seems to be happening on every shutdown > whether it's a restart for an update or not. I think this is the key point. If Nightly is not 'stopping properly', and Windows is detecting this as a Crash, then we might *also* have 'Updating issues'. Remember, in my case, I am using Windows 7 64 bit OS (others are using Windows 10 64 bit). In order to find the approximate regression I decided to download some recent ZIP builds for Windows (both 32 bit and 64 bit). Remember in http://forums.mozillazine.org/viewtopic.php?f=23&t=3031109 from Comment #1 "Aris" said (Posted June 16th, 2017, 11:14 am): > 64bit Nightly crashes on exit even with a clean empty profile. Can someone confirm? > Win7 x64 / Nightly x64 > > 32bit Nightly seems not to be affected. Link to his Post http://forums.mozillazine.org/viewtopic.php?p=14752415#p14752415 I intend to put them in a non-standard place (so the Windows Registry does not 'know about it') and then see if I can close Nightly. Method: A. I created a Windows User with Admin privileges. B. I created this "user.js" file (which I have attached) to stop the 'recent Nightly' from updating before I ask it to. ====== # Mozilla User Preferences /* Do not edit this file. * * If you make changes to this file while the application is running, * the changes will be overwritten when the application exits. * * To make a manual change to preferences, you can visit the URL about:config */ user_pref("app.update.auto", false); user_pref("app.update.enabled", false); user_pref("app.update.service.enabled", false); ====== C. I created a series of directories for the Programs: C:\Mozilla-Temp-Program-Files\Start-2016-06-14_32bit\ C:\Mozilla-Temp-Program-Files\Start-2016-06-14_64bit\ C:\Mozilla-Temp-Program-Files\Start-2016-06-15_32bit\ C:\Mozilla-Temp-Program-Files\Start-2016-06-15_64bit\ C:\Mozilla-Temp-Program-Files\Start-2016-06-16_32bit\ C:\Mozilla-Temp-Program-Files\Start-2016-06-16_64bit\ etc The date is the Build Date (I might update some of these later - hence "Start" as part of the path). I want to go back to 'before this issue was reported' 2017-06-16, and work forward. D. I created a series of directories for the Profiles: C:\Mozilla-Temp-Profiles\Start-2016-06-14_32bit\ C:\Mozilla-Temp-Profiles\Start-2016-06-14_64bit\ C:\Mozilla-Temp-Profiles\Start-2016-06-15_32bit\ C:\Mozilla-Temp-Profiles\Start-2016-06-15_64bit\ C:\Mozilla-Temp-Profiles\Start-2016-06-16_32bit\ C:\Mozilla-Temp-Profiles\Start-2016-06-16_64bit\ etc In each, I placed a copy of the user.js file. So, these Profiles are empty and should do a 'first run' etc. I am attempting to reproduce a normal 'exit from Nightly', to see if 'Windows thinks it stopped normally'. E. I created a series of 'Windows shortcuts' that have the following Properties (here are two examples): Name: Nightly-Test-Start-2016-06-14_32bit-NR Target: C:\Mozilla-Temp-Program-Files\Start-2016-06-14_32bit\firefox\firefox.exe -profile "C:\Mozilla-Temp-Profiles\Start-2016-06-14_32bit" -no-remote Start in: C:\Mozilla-Temp-Program-Files\Start-2016-06-14_32bit\firefox Name: Nightly-Test-Start-2016-06-14_64bit-NR Target: C:\Mozilla-Temp-Program-Files\Start-2016-06-14_64bit\firefox\firefox.exe -profile "C:\Mozilla-Temp-Profiles\Start-2016-06-14_64bit" -no-remote Start in: C:\Mozilla-Temp-Program-Files\Start-2016-06-14_64bit\firefox When I UnZip each 'Zip build' to e.g. C:\Mozilla-Temp-Program-Files\Start-2016-06-14_32bit\ the "firefox" sub-directory is created, along with all of the Nightly program Files. F. I also had Windows "Task Manager" running, with "Show processes from all users", (so that I could monitor). continued ...

"UAC-to-start-Nightly.png" Using "Nightly-Test-Start-2016-06-14_32bit-NR" to start the 32 bit, 2016-06-14 Build, into its own Profile (see above) I get the following: As I expected, a UAC prompt "Security Warning" (attached) asking me to confirm that I do indeed want to start C:\Mozilla-Temp-Program-Files\Start-2016-06-14_32bit\firefox\firefox.exe I get a 'normal first run', once I have chosen "Run" in the UAC. continued ...

As expected, I have 6 'Nightly Firefox.exe' (I was not sure how many I would see) and one Firefox ESR [52.2.0] because I am also running an instance of ESR (where I have Extensions that can not run under e10s – I expect ONE instance of "firefox.exe" for ESR). So, as expected, Nightly 2017-06-14 32 bit has e10s. See Attached "Task-Manager-2017-06-14_32bit-Build.png". Before I closed Nightly, I enabled the "Menu bar". I also checked "about:config" for the three settings from the "user.js": app.update.auto "false", app.update.enabled "false" and app.update.service.enabled "false", as expected, were present. I used Menu, File, Exit to close Nightly. It closed OK. All 6 'Nightly firefox.exe' closed. I have repeated the steps in Comment # 12 and #13 several times because I noticed that despite the "user.js" the build was silently updating from 2017-06-14 to the latest build. At one point I did NOT have "app.update.service.enabled" set to "false" in the "user.js" and this might be able to 'stop the updates that I don't want while I test'. Each time I repeated the launch (comment # 12) I preceded this by deleting all the Program Files and the Profile. Then I UnZiped the build again (comment # 11 - step E), and copied the "user.js" to the empty Profile directory. In the end, to stop the 'automatic update', I disconnected the network cable as soon as I had the "Nightly Start Page" Tab. continued ...

See Attached: "UAC-for-pingsender.png". I speculate that this might be what "Are You A Wiiizard?" noticed > Same, no crashes but my cursor turns to the "busy" cursor for ~3secs after closing, > pretty sure it didn't do that before. http://forums.mozillazine.org/viewtopic.php?p=14752450#p14752450 I have seen, in Bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1360819 I commented, on 2017-04-29, in that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1360819#c2 [I don't send Telemetry on my 'normal profiles' and so I've not witnessed this myself, until I did these tests]. Nightly (32 bit Build 2017-06-14) closed normally. I now wonder, 'has a change to pingsender' caused this 'not closing Nightly properly issue'? continued ...

All of the above (Comment # 11 onwards) was to establish 'what is normal' in these tests. Next, I tested the other builds in sequence. Each time I pulled the Network cable as soon as I had the "Nightly Start Page" Tab on the 'first run'. I kept the PC off the Internet while I did the 2nd and 3rd runs. I only reconnected the network cable just before the 'test of a new build - first run'. I checked that the build was NOT updating using "about:support" to see the Build ID in the 2nd and 3rd runs. Here are the results: Nightly-Test-Start-2016-06-14_32bit-NR Version 56.0a1 (2017-06-14) (32-bit) Build ID 20170614030206 Exit was normal, pingsender 'asked to run'. 6 x Firefox on 1st run, 4 x Firefox on 2nd, 3rd runs. Nightly-Test-Start-2016-06-14_64bit-NR Version 56.0a1 (2017-06-14) (64-bit) Build ID 20170614030206 Exit was normal, pingsender 'asked to run'. 6 x Firefox on 1st run, 4 x Firefox on 2nd, 3rd runs. Nightly-Test-Start-2016-06-15_32bit-NR Version 56.0a1 (2017-06-15) (32-bit) Build ID 20170615030208 Exit was normal, pingsender 'asked to run'. 6 x Firefox on 1st run, 4 x Firefox on 2nd, 3rd runs. Nightly-Test-Start-2016-06-15_64bit-NR Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 First run, 6 x Firefox. Windows detected 'Crash on Exit' i.e. the "Nightly has stopped working" message I did not see a request to run pingsender.exe See "2016-06-15_64bit-01Run-Exit-Part01-crash.png" Which is the Top of the 'problem details' for this Windows crash. So far, I am not surprised. Windows 32 bit 2016-06-15 did not crash and Windows 64 bit 2016-06-15 did crash. --- 2nd run is as expected (4 x Firefox.exe) There was a request for pingsender.exe on the 2nd close. Windows detected 'Crash on Exit' i.e. the "Nightly has stopped working" message It is different on the 2nd close. --- 3rd run is as expected (4 x Firefox.exe) There was a request for pingsender.exe on the 3rd close FOLLOWED BY the crash. There was still ONE 64 bit Nightly running while I had the "Nightly has stopped working" 'Windows crash notice' running. The 3rd crash was slightly different as well. I will now post some screenshots. continued ...

2016-06-15_64bit-01Run-Exit-Part02-crash

2016-06-15_64bit-01Run-Exit-Part03-crash

Nightly-Test-Start-2016-06-15_64bit-NR Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 While the Nightly has stopped working there is still one 64bit Nightly running in Task Manager. If I choose "Close the program" it does close (and is no longer seen in Task Manager).

Nightly-Test-Start-2016-06-15_64bit-NR Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 2nd run is as expected (4 x Firefox.exe) There was a request for pingsender.exe on the 2nd close. Windows detected 'Crash on Exit' i.e. the "Nightly has stopped working" message It is different on the 2nd close. So, I am attaching 3 screenshots (this is 1 of 3).

2016-06-15_64bit-02Run-Exit-Part02-crash.

2016-06-15_64bit-02Run-Exit-Part03-crash.

Task-Manager-ESR-and-2017-06-15_32bit-and-2017-06-15_64bit.png 1 x ESR, 4 x 32 bit and 4 x64 bit. All is OK until I close the 64 bit. When I close the 64bit, while the UAC waits for the permission for pingsender.exe, there are TWO 64 bit Firefoxes (build 2017-06-15). I then got a Nightly Crash! First time I have seen this (all the others are 'Windows crashes') bp-106caa3c-5871-4a8c-9a2a-aac960170626 26/06/2017 21:31 local time Remember the above crash is: Nightly-Test-Start-2016-06-15_64bit-NR Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 I have some more screenshots, but I need to stop. I'll checj this bug again tomorrow (on 2017-06-27 at about 20:00 UCT). DJ-Leith

I have just noticed that I have used "2016" in several places (Path Names, and Windows shortcuts) where I should have said "2017". Some of these paths are visible in the Task Manager screenshots. For consistency I will keep this 'wrong year' in this bug. Remember, the first 'Nightly that has this issue', in these tests is: Nightly-Test-Start-2016-06-15_64bit-NR (sic - wrong Year) Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 (In reply to DJ-Leith from Comment #15 [https://bugzilla.mozilla.org/show_bug.cgi?id=1374043#c15]) > 3rd run is as expected (4 x Firefox.exe) > > There was a request for pingsender.exe on the 3rd close > FOLLOWED BY the crash. > > There was still ONE 64 bit Nightly running while I had the > "Nightly has stopped working" 'Windows crash notice' running. > > The 3rd crash was slightly different as well. I have now looked at the screenshots for the 3rd run. They look to be the SAME as the 1st run i.e. just like "2016-06-15_64bit-01Run-Exit-Part01-crash.png", "2016-06-15_64bit-01Run-Exit-Part02-crash.png" and "2016-06-15_64bit-01Run-Exit-Part03-crash.png". So, I have not attached them. The differences between "2016-06-15_64bit-01Run-Exit-Part01-crash.png" and "2016-06-15_64bit-02Run-Exit-Part01-crash.png" Include: 01Run "Problem Event Name: APPCRASH" 02Run "Problem Event Name: BEX64" 01Run "Exception Offset: 0000 0000 004f 075c" (added spaces to help count "0") 02Run "Exception Offset: 0000 0000 0000 02f7" 02Run also has "Exception Data:" while 01Run does not. More information about other runs of "Version 56.0a1 (2017-06-15) (64-bit)". When I close Nightly (Menu, File, Exit) the number of 'Nightly firefox.exe' drops to 2 (from 4). When I 'answer the question about pingsender', see "UAC-for-pingsender.png", with "Cancel", I THEN see just one 'Nightly firefox.exe' and THEN I get get the 'Windows crash' ("2016-06-15_64bit-01Run-Exit-Part01-crash.png" etc). If I wait a long time, without 'answering the question about pingsender', then I get the 'Firefox crash report'. https://crash-stats.mozilla.com/report/index/106caa3c-5871-4a8c-9a2a-aac960170626 So, I speculate the 'Firefox crash report' is 'just a symptom of the delay at the pingsender stage', and is not the 'Windows crash'. If I select "Close the program" from the "Nightly has stopped working", the 'Windows crash', then the last 'Nightly firefox.exe' stops without a registering a 'Firefox crash' (which is what I reported in Comment #1). > 2.1 No matter how I stop, or Restart, Nightly, it always is detected by > Windows 7 as a 'crash'. A "Nightly has stopped working" modal window. > However, there are no 'Firefox crash reports' on any of my Profiles. Other tests in this series: Nightly-Test-Start-2016-06-16_32bit-NR (sic - wrong Year) Version 56.0a1 (2017-06-16) (32-bit) Build ID 20170616030207 Exit was normal, pingsender 'asked to run'. 6 x Firefox on 1st run, 4 x Firefox on 2nd, 3rd runs. So this confirms what I said in Comment # 11 > Remember in > http://forums.mozillazine.org/viewtopic.php?f=23&t=3031109 > from Comment #1 > > "Aris" said (Posted June 16th, 2017, 11:14 am): > > 64bit Nightly crashes on exit even with a clean empty profile. Can someone confirm? > > Win7 x64 / Nightly x64 > > > > 32bit Nightly seems not to be affected. So, the 32 bit builds don't have this issue. Nightly-Test-Start-2016-06-16_64bit-NR (sic) Version 56.0a1 (2017-06-16) (64-bit) Build ID 20170616030207 6 x Firefox on 1st run, a pingsender 'request / UAC' (with 2 x Nightly still running), a 'Windows crash' on first close (by Menu, File, Exit). This was a "Problem Event Name: BEX64" crash (like the "2016-06-15_64bit-02Run-Exit-Part01-crash.png" - I don't know if this is significant or repeatable [BEX64 vs APPCRASH]) with just one 'Nightly 2017-06-16 64bit' running. I closed this with "Close the program" in the "Nightly has stopped working" 'Windows crash' dialogue. I did see pingsender (the UAC request to run pinsender.exe) on this first run. I can't confirm that I did NOT see pingsender on the first run of other tests. I can confirm that I always saw pingsender on all the 2nd and 3rd runs. 2nd and 3rd runs 4 x Firefox, and pingsender 'asked to run'. Like the 1st run, when I closed Nightly, TWO Firefox instances stopped and two 'kept running'. While I was being offered the 'pingsender UAC' they kept running. When I "Cancel" ed pingsender, one closed, then I got the 'Windows crash'. The last 'Nightly firefox.exe' stopped when I selected "Close the program". Nightly-Test-Start-2016-06-17_32bit-NR (sic) Version 56.0a1 (2017-06-17) (32-bit) Build ID 20170617030206 Exit was normal, pingsender 'asked to run' (on all 3 runs). 6 x Firefox on 1st run, 4 x Firefox on 2nd, 3rd runs. ****** FYI, 125 items when I unzip the build [Version 56.0a1 (2017-06-17) (32-bit)] FYI, 124 items when I unzip the build [Version 56.0a1 (2017-06-17) (64-bit)] Do you expect there to be one file less in the 64bit build for Windows? ****** Nightly-Test-Start-2016-06-17_64bit-NR (sic) Version 56.0a1 (2017-06-17) (64-bit) Build ID 20170617030206 Just like Version 56.0a1 (2017-06-16) (64-bit) 6 x Firefox, on 1st run 4 x Firefox, on 2nd and 3rd runs. All 3 runs 'ask for pingsender', all three have a 'Windows crash'. *** Summary to date *** Tested Windows 32 bit builds (2017-06-14, 15, 16 and 17). All 'close normally'. Tested Windows 64 bit builds (2017-06-14, 15, 16 and 17). Version 56.0a1 (2017-06-14) (64-bit) Build ID 20170614030206 Is like the 32 bit builds, it closes normally. However, Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 (and 2017-06-16 and 2017-06-17) all have the 'Windows Crash' on Close. The Regression is in Version 56.0a1 (2017-06-15) (64-bit) Build ID 20170615030208 but it does not seem to be in the 32bit builds. I noticed, when UnZipping the 2017-06-17 builds that the 32bit version has one more file vs the 64bit version. DJ-Leith

I firmly believe that this bug is contributing to the 'Nightly updating issues', seen since 2017-06-15, on Windows Nightly 64 bit builds. Possible duplicates of this bug include: Bug 1373918 "Nightly is crashing at close" and Bug 1376762 "Firefox Nightly (56) 20170615+ crashes on exit (Windows 7 & 10 64bit)" The latter, is concise - and has a Regression pointing to Bug 1372375 DJ-Leith

Could everyone who is encountering these shutdown problems please share a list of any antivirus/security/utility/etc. software you have installed? In my experience, when a code change like bug 1372375 causes regressions, it's usually due to an unexpected interaction with external software.

Avast + Malwarebytes, both latest version.

(In reply to David Major [:dmajor] from comment #25) In my case Product: "AVG Internet Security" Software version: 17.5.3021 (Last update 2017-06-29) Virus definitions version: 170629-0 The AVG software is also visible in "Task-Manager-ESR-and-2017-06-15_32bit-and-2017-06-15_64bit.png" https://bug1374043.bmoattachments.org/attachment.cgi?id=8881306 (attached at comment # 22). Remember, in my tests above (and Aris' Report in Bug 1376762) it is only the 64 bit Nightly from 2017-06-15 that have a 'Windows crash' when you close Nightly. > The Regression is in > Version 56.0a1 (2017-06-15) (64-bit) > Build ID 20170615030208 The 32bit builds seem to be OK. Also, the ONLY 'Firefox crash' that I have seen is described best in Comment # 23 > I have just noticed that I have used "2016" in several places > (Path Names, and Windows shortcuts) where I should have said "2017". > Some of these paths are visible in the Task Manager screenshots. > For consistency I will keep this 'wrong year' in this bug. > > Remember, the first 'Nightly that has this issue', in these tests is: > > Nightly-Test-Start-2016-06-15_64bit-NR (sic - wrong Year) > Version 56.0a1 (2017-06-15) (64-bit) > Build ID 20170615030208 <snip> > More information about other runs of "Version 56.0a1 (2017-06-15) (64-bit)". > > When I close Nightly (Menu, File, Exit) the number of 'Nightly firefox.exe' > drops to 2 (from 4). > > When I 'answer the question about pingsender', see "UAC-for-pingsender.png", > with "Cancel", I THEN see just one 'Nightly firefox.exe' and THEN I get > get the 'Windows crash' ("2016-06-15_64bit-01Run-Exit-Part01-crash.png" etc). > > If I wait a long time, without 'answering the question about pingsender', > then I get the 'Firefox crash report'. > > https://crash-stats.mozilla.com/report/index/106caa3c-5871-4a8c-9a2a-aac960170626 > > So, I speculate the 'Firefox crash report' is 'just a symptom of the delay > at the pingsender stage', and is not the 'Windows crash'. DJ-Leith

Avast Version: 17.5.2302 (Build 17.4.3482.0) Virus Def version: 170629-0 As an update I have noticed on update restarts after killing all the firefox processes the update will actually happen now and Nightly will relaunch itself.

I have a pretty good idea of what code needs to change, but it will take a bit of time to write the fix. In the meantime, is anyone willing to try temporarily disabling/uninstalling their antivirus to see if it helps?

StackHash_1dc2 StackHash_3c7f With firewall OFF and no AV active, Nightly 56.0a1 hangs up on close & update and crashes with two separate StackHash errors (most of the time, its 3c7f). I can't seem to replicate the 1dc2 but its come up before. Here's the dmp from Windows 7 Ultimate 64bit SP1. If there's some frameworks or something missing that can be causing this it wouldn't surprise me. Don't judge me. I'd just really like to see this issue fixed. https://www.mediafire.com/?vo9td1d82whn9fa

(In reply to David Major [:dmajor] from comment #29) > I have a pretty good idea of what code needs to change, but it will take a > bit of time to write the fix. In the meantime, is anyone willing to try > temporarily disabling/uninstalling their antivirus to see if it helps? We might see the same issue with our Firefox ui update tests. The failure is listed as bug 1293969. Just to note we do not have any AV software running on those boxes.

Hopefully this should be fixed when the base build (the one you're updating from) is 2017-07-06 or later.

Just updated and the issue does appear to be resolved. I am able to close Nightly and windows does not report a crash. Tested on both my everyday profile and a clean profile.

Is there a commit to point to? We have a slew of other similar bugs that may be closed by this same fix.

Oh, is it all stemming from the fix for bug 1378442?

(In reply to David Durst [:ddurst] from comment #35) > Oh, is it all stemming from the fix for bug 1378442? Yes, bug 1378442 ought to fix any issues that were attributed to bug 1372375. If it doesn't, that would mean there's an unrelated bug occurring in parallel.

Marking fixed for 56 based on comment 33 - 36.