hi bsfinkel, thank you for reporting with some crash ids - please try if the following step is making a difference: press ctrl+shift+del in firefox to bring up the dialog to clear recent history, select the time range "everything", untick all boxes except "offline website data" and let firefox clear that. does firefox shut down cleanly after that?

I have cleared the offline website data. I will Exit Firefox sometime in the future. I was looking at my recent (April and May) crash dumps, and I am having a hard time coordinating each crash dump with the crashes that I have logged in my manual log. I have the crash time from the detail before I submit the crash report (I have a Python script to convert the timestamp), but the "Install time" + "Install Age" does not match the crash time I have logged.

And, when I looked at about:crashes this morning, I see LOTS of crash dumps that have not been submitted, and I have no idea why. I have manually logged all Firefox crashes, and for only a few have I not submitted the reports.

When I see in a crash report "Crash Reason: EXCEPTION_BREAKPOINT", what does that mean?

Here is an update. I do not want to add more problems to this thread, but I am getting confused. My last report was 05/20/2019 around 09:20 (the last dump I reviewed was sent at 09:15). My manual log shows these FF crashes since that time::

    05/24 09:03  (during an Exit)
    05/24 14:10  (during an Exit) 

But when I look at "about:crashes" I see 13 crash dumps that have been sent since 05/20 09:15. I see these Install times:

   1   2019-02-13 15:34:12  65.0.1
   5   2019-03-01 15:59:21  65.0.2
   1   2019-03-24 02:08:05  66.0.1
   1   2019-04-10 19:10:03  66.0.3
   3   2019-05-08 13:49:50  66.0.5
   1   2019-05-21 13:15:38  ??
   1   2019-05-24 14:54:14  67.0

The 05-21 13:15:18 is when I cleared recent history. What I do not understand is why I manually submitted TWO crash dumps, but the FF log shows I have submitted 13, all of which have various install times (and thus various older crash times and versions of Firefox).

One thing I can report (per the previous trouble ticket) is that with the two crashes today, the crash report was very quick. So the history info I cleared did resolve that problem. The two crash IDs from today:

    bp-2f37eee3-6633-419d-8975-0c2e80190524
    bp-bed0b539-ad22-4789-ba10-1b4330190524

Both are EXCEPTION_BREAKPOINT crashes, and sesssionstore.jsonlz4 WAS written successfully.

bsfinkel said

One thing I can report (per the previous trouble ticket) is that with the two crashes today, the crash report was very quick. So the history info I cleared did resolve that problem. The two crash IDs from today: bp-2f37eee3-6633-419d-8975-0c2e80190524 bp-bed0b539-ad22-4789-ba10-1b4330190524 Both are EXCEPTION_BREAKPOINT crashes, and sesssionstore.jsonlz4 WAS written successfully.

The first is Firefox 67.0 and has the signature @ OOM | small and seems to indicate that Firefox requested 168 bytes of contiguous memory from Windows and was declined. That seems too small to be true, so there's probably more to the story, or it might help to restart Windows.

The second is Firefox 66.0.5 and has the signature @ shutdownhang | js::GCParallelTask::join. If my "date math" is correct, this occurred several hours earlier, so apparently there was an update in between.

Note that installTime items in the crash report folder have nothing to do with crashes, but are added when Firefox is updated (you posted the Firefox version that was about) See also the "Show update history" button on the "Help -> Troubleshooting Information" (about:support) page.

Signatures:

• Firefox 67.0 Crash Report [@ OOM | small ]
• Firefox 66.0.5 Crash Report [@ shutdownhang | js::GCParallelTask::join ]

The first report from Firefox 67 is about OOM (out-of-memory) where not enough contiguous free memory is available. Are you using the recommended size for the Windows pagefile?

See the Firefox Task Manager (about:performance) page. https://support.mozilla.org/en-US/kb/task-manager-tabs-or-extensions-are-slowing-firefox

Total Virtual Memory : 2,147,352,576 bytes (2.15 GB)
Available Virtual Memory : 228,270,080 bytes (228.27 MB)
Available Page File : 8,933,023,744 bytes (8.93 GB)
Available Physical Memory : 459,722,752 bytes (459.72 MB)
System Memory Use Percentage : 86
OOM Allocation Size : 168 bytes

Today (05/24) at 09:15 I rebooted after uninstalling Dropbox (for another problem) . I Exited FF at 09:00, and FF crashed at 09:03. Before the reboot I saw that FF had an update to install.

After the reboot, FF auto-updated from 66.0.5 .to 67.0. Then, since I had not opened many additional applications and I had not seen an EventID 55 NTFS error (which causes an unnecessary 12-minute "chkdsk c:" at the next reboot), I decided to install new MS Patch KB4505050. I did an Exit in FF at 14:08 prior to the patch install and required reboot, and FF crashed at 14:10. So, I have rebooted twice today.

"Note that installTime items in the crash report folder have nothing to do with crashes...". I know that. I keep a manual log of FF crashes, and I need to take the install time and add to it the uptime (I need to figure out how to do that automatically) to get the crash time. I keep a copy of the crash details I manually submit, and I am trying to determine which crash report corresponds with which crash detail I have manually submitted after a FF crash. As I wrote in an earlier post, I suggest that the crash time be included in the crash report I see via "about:crashes" so that I do not have to do the addition manually.

The crash time is in the crash report.

2f37eee3-6633-419d-8975-0c2e80190524 => CrashTime : Fri, 24 May 2019 19:10:09 GMT

When I look at this specific crash via "about:crashes" I see in the "Details" tab these line headings in grey:

    Signature 
    UUID 	2f37eee3-6633-419d-8975-0c2e80190524
    Date Processed 
    Uptime 
    Last Crash 
    Install Age 
    Install Time 
    Product 
    Release Channel 
    Version 
    Build ID 
    OS 
    OS Version 
    Build Architecture 
    CPU Info 
    CPU Count 
    Adapter Vendor ID 
    Adapter Device ID 
    Startup Crash 
    False
    MOZ_CRASH Reason (Sanitized) 
    MOZ_CRASH()
    Crash Reason 
    Crash Address 
    Total Virtual Memory 
    Available Virtual Memory 
    Available Page File 
    Available Physical Memory 
    System Memory Use Percentage 
    OOM Allocation Size 
    EMCheckCompatibility 
    App Notes 
    Processor Notes 

I do not see "Crash Time". I am running 67.0; are you running a beta version where "Crash time" has been added?

I do see in the "Metadata" tab: CrashTime 1558725009 and I can use my Python script to convert that to GMT -

D:\computer>ff 1558725009

D:\computer>rem Convert a Firefox CrashTime integer to a timestamp.

D:\computer>rem 23Sep13 0847PM Barry Finkel

D:\computer>rem 05Dec13 0841AM Changed to use \temp (either C: or D:)

D:\computer>echo 1558725009 1>\temp\ffcrshtm.in

D:\computer>rem type \temp\ffcrshtm.in

D:\computer>python d:\python\ffcrshtm.py 0<\temp\ffcrshtm.in Please input the timestamp. 2019-05-24 19:10:09

D:\computer>

I have had more occurrences of this problem. At each occurrence, I tell the crash reporter window to submit the report and restart Firefox. But when I went to "about:crashes" a few minutes ago, I saw that the last three occurrences had NOT been submitted. Each one had the "Date Submitted" timestamp that agreed with the date and time that I clicked "Restart Firefox". Here are the IDs of these three crashes:

bp-755453dd-0ce8-41b9-8040-bdc940190617 bp-cf087d93-a626-4c87-9ca5-8760e0190613 bp-2e3fa550-fe12-4115-8d08-40dc70190606

I still want to know why Firefox is crashing after writing the sessionstore.js configuration file. Thanks.

Here is another reply, I have had two further occurrences:

bp-4e59f369-af10-4f17-9e6c-c56ad0190625 bp-ebc51d2a-140c-47eb-be1f-63b210190620

A "shutdown hang" crash is recorded when shutdown hits the maximum time limit. I can't tell what Firefox was doing before the "shutdown hang" occurred, so I don't know whether it is related to sessionstore.jsonlz4, recovery.jsonlz4, or some other file(s).

Is this max time limit a value that I can change? I would prefer Firefox to take a bit longer during termination rather than to crash and then me having to log and process the crash dump. Thanks.

I can't test this myself, but you could experiment:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste crash_ and pause while the list is filtered

(3) By default, the toolkit.asyncshutdown.crash_timeout preference has a value of 60000 milliseconds (60 seconds). You could double-click that and change it to 90000 (90 seconds) to see whether it actually is the relevant value (i.e., you get the dialog 90 seconds after shutdown instead of 60 seconds after shutdown).

I made the change, and I will wait for the next time I have to restart Firefox. Thanks.

I changed the value to 90000 a few days ago. Today at 14:05 Firefox was slow in responding to Thunderbird e-mail URLs, so I did an Exit in Firefox. Firefox terminated (no firefox.exe listed in Task Manager), so I restarted Firefox. This was around 14:09. Firefox was behaving normally, but at 14:42 I saw a pop-up window about a Firefox crash. The crash info said that the crash occurred at 14:11. I just submitted the crash report bp-ca019780-17f8-4d37-84d3-f10730190627. I am not sure that the text I have entered into the crash report window is present in the submitted report, as I have not "closed" that crash window. (I do not want to quit or restart Firefox now, as it is working fine.)

Was the delay in producing the crash window caused by the "Clear Recent History - Offline Website Data"? I cleared that on 5/21 at 13:54. Do I have to keep clearing it so that the Firefox crash reports are not delayed? If so, is there a setting I can change so that Firefox will NOT save those data?

Thanks.

bsfinkel said

Firefox terminated (no firefox.exe listed in Task Manager), so I restarted Firefox. This was around 14:09. Firefox was behaving normally, but at 14:42 I saw a pop-up window about a Firefox crash. The crash info said that the crash occurred at 14:11. I just submitted the crash report bp-ca019780-17f8-4d37-84d3-f10730190627.

It's an "out of memory" crash, so that's a bit different. I don't know why the crash window came up later. ???

I am not sure that the text I have entered into the crash report window is present in the submitted report, as I have not "closed" that crash window.

Comments are now restricted to certain logged in users; neither you nor we can see them.

Was the delay in producing the crash window caused by the "Clear Recent History - Offline Website Data"? I cleared that on 5/21 at 13:54. Do I have to keep clearing it so that the Firefox crash reports are not delayed? If so, is there a setting I can change so that Firefox will NOT save those data?

What are "those data"? You can set Firefox to clear Offline Website Data when it closes (uncheck the other types of history). Do you have that already?

Look at the attached screenshot. I did a "Clear Offline Website Data" on 5/21, and I just did it again (by accident). From another closed thread, it was determined that these saved Offline Website Data were causing the delayed Firefox crash report. My basic question is this - Do I have to do this periodically, or is there a Firefox setting to tell Firefox not to save these data (the ones that I just deleted (by accident))? As the delete command took about one minute to complete, I assume that there were saved data that were just deleted. Was my delayed crash report today due to Offline Website Data that Firefox had saved after I did the clear operation on 5/31? Thanks.

Another occurance. Crash ID bp-7a639669-4a7e-49ff-99fb-3cf780190710

At 13:35 I restarted FF to upgrade from 67.0.4 to 68.0 . At 13:40 firefox.exe was not running, but sessionstore.jsonlz4 was written at 13:37. I waited about ten minutes, and I did NOT see a crash window. So I started FF, and the update was installed without problem. When I returned to my computer after dinner I saw a crash window; I have no idea when the window was created.

I have the same questions as I posted above - WHY IS THE CRASH REPORT WINDOW DELAYED? And why is FF crashing? In the other thread that has been closed, there was a cause speculated for the delay. At that time I followed the recommended procedures, and the delay vanished. But now it has returned.

Do I have to clear continually the Offline Website Data, or is there a setting I can change so that the OWD are not saved? Also, is it a bug in FF that these saved OWD causes the delayed crash reports? The other thread was closed before I got a chance to ask that question. Not kn owing the internals of FF, on the surface it appears that this IS A BUG in FF.

Another occurrence that requires answers to ,y two questions above. FF was running slowly, so I increased toolkit.asyncshutdown.crash_timeout from 90000 to 120000 to see if I would get a dump on Exit. At 13:42 I did an Exit. A few minutes later all of the FF processes had terminated, so I started FF. Then, at 14:07, I saw a pop-up window about a FF crash at 13:47. I obviously cannot submit that crash report from the crash window with Firefox running. The crash ID is bp-2caa6b7c-e030-4530-b19a-d92e10190726 .

My questions:

1) what caused this FF crash?

2) Why the delayed crash report? What process generates the crash report? If firefrox.exe, how can it generate a window when, according to Task Manager, no firefox.exe processes are running.

3) Do I have to clear OWD again? Do I have to clear it periodically? Is there a setting so that FF does not save OWD?

4) What will happen if I take the crash window , check "Restart FF", and then submit the report? Will FF start a second instance?

Thanks.