Hi Barry, As no one seems to be getting to a solution here, and your usage is generating myriads of crash signatures maybe it would help if we try to simplify things.

Because this proposal will stress your System more, it will likely make Firefox even more crashy, so may not be appropriate if you have strong reasons or needs for keeping a continuous Firefox session open as long as possible.

My Suggestion for Troubleshooting: Carry on using Firefox as normal in your existing profile. But create a new profile for test purposes. Run a second separate instance of Firefox as a test simultaneously to your ordinary Firefox activities.

Using the test profile lets see if we can prevent Firefox getting unresponsive. Initially try it as follows

• Use -no-remote to allow use of a second Firefox instance.
• Use Firefox's Safe Mode
• Disable all plugins by setting to never activate
• Browse only one website, (use as many tabs or windows as you wish/need) but some site that does not need FlashPlayer.

With any luck either

• The second test instance will work ok, (other than being affected by a general lack of System resources.)
  • If so the next step could be to try with maybe the NOAA site and FlashPlayer set as click to activate.
  • If the other standard Firefox is affecting this badly it may have to be tried on a day when you do not need to do any normal browsing.
• Or it will become unresponsive and crash but with a more consistent Crash Signature.
  • If in that configuration it heads for 40% cpu becoming unresponsive or uses 1.6GB private there are further steps we can take to investigate what is happening.

I had another occurrence last night/this morning. Last night at 11:15 FF was beginning to become unresponsive when I left the computer to go to bed. This morning at 8:15 FF was unresponsive. It was using lots of CPU, there was no menu bar by which I could do a clean "File-Exit", and Windows told me in the top of a window that FF was "not responding". The Task manager showed that the I/O read and I/O write counts were not increasing, but the I/O other count was slowly increasing. Firefox (which I had upgraded to 47.0.1 yesterday) was still using all the CPU at firefox.exe+0x253b. I have included screen shots of Process Explorer (Performance Graph and Threads tabs) and the Task Manager.

I obviously do not have access to the source code or compilation listings, so I have no idea what is happening at offset 0x253b into the firefox.exe executable. Firefox is using a lot of CPU at that location, with little I/O activity. I just checked the performance graph, and the width of the display is 2' 45". There is no I/O activity in the screen shot.

As for the suggestion to run a test FF - I am not sure I understand what you want. A few weeks ago, I was not at my computer from Friday at 4:00PM until Monday at 9:30PM. Before I left my computer I Exited and then restarted FF. I made sure that the NOAA radar image was running in its loop and updating periodically. FF started with 1,1 Gb of private space, and when I returned to the computer FF was still using 1.1 Gb of private; FF was behaving correctly. This tells me that FF will run properly with my current set of windows and tabs. It is only after I begin using FF does it get into its acting-badly state. So, I assume that a test FF running by itself with no activity from me will run normally "forever" (until the next reboot). I have my machine running all the time, except when I am going to be on vacation for a period of time, at which time I power-off the machine. I see no reason to shutdown any running tasks overnight; I let each task run. I shut down tasks only before a scheduled reboot, or when I know that I no longer need that task,, or if the task manager tells me that I am running high on physical memory usage.

I still do not know if the high CPU usage condition is related to the various crashes. I am awaiting a response to my posting on the Dropbox forum.

--Barry Finkel

Hi again Barry,

As for the suggestion to run a test FF - I am not sure I understand what you want. ... This tells me that FF will run properly with my current set of windows and tabs. It is only after I begin using FF does it get into its acting-badly state. So, I assume that a test FF running by itself with no activity from me will run normally "forever" (until the next reboot).

My suggestion was not that you leave Firefox unattended, but set up as suggested you browse as normal but initially try with only one site. If that goes ok then add other sites one at a time.

If the problem seems to be increasing memory use then that may be studied and reduced with the built in about:memory. Or if it is cache use then look with about:cache, and maybe use the ramback addon (Of course ramback will not be available whilst in safe mode).

• Firefox uses too much memory or CPU resources - How to fix_memory-troubleshooting-tools
  • https://developer.mozilla.org/docs/Mozilla/Performance/about%3Amemory

If you have problems with unresponsiveness, then if that is at all predictable you may be able to catch the issue with the built in profiler.

• https://developer.mozilla.org/docs/Tools/Performance

Firefox is open source

I obviously do not have access to the source code 
or compilation listings

If you are interested in the source code or compiling you may do that. (I note MXR is down at the moment. I have not used it for a while and am not sure if that is temporary or whether it is being replaced.) Look at for instance

• https://developer.mozilla.org/docs/Mozilla/Developer_guide
  • https://developer.mozilla.org/docs/Mozilla/Developer_guide/Source_Code
  • https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_the_VM

Dropbox Maybe I overlooked something, but in for instance

bp-394ebe78-dc33-417f-af30-f626e2160626

I do not notice dropbox as being explicitly mentioned in the crashing thread. If you consider dropbox is an important part of the problem just try to reproduce the issue without dropbox. I am guessing, but because of the variety of signatures, I imagine you will still see crashes.

You definitely need to test in a new profile. It may also help to try in Windows own safe mode and it could also be worth trying a clean install of Firefox. I have been looking and note you have posted quite as few questions, but do not seem to have found solutions yet.

I summarised in the other currently open thread as follows:

John99 said in: Firefox Windows "Vanish" & Re-appear on Restart

I thought a bit of cross linking may help here. Your other threads include the following (With my comments)

• Current, Fx47. (Possibly related)
  "Firefox becomes non-responsive, 40% CPU, 1.6 Gb private, then crashes"
  /questions/1122039
  1. Current (I will close) Fx45
     "FIrefox Hangs on Start - No I/O /questions/1124771"
  2. Fx32, Sept 2014.
     "Firefox using much CPU; how to find the offending tab/URL?" /questions/1020162
     (Multiple & duplicated plugins apparently installed. Fx Crashing OOM)
• Duplicates of this
  1. Fx38, June 2015 /questions/1067958
     (From helpdesk comment /questions/1067958#answer-813831 I wonder if part of the issue may be attempts to use back for more than the number configured ?)
  2. Fx34, Dec 2014 /questions/1037358
     (Similar to above, but includes mention of OOM Fx crashes and repeated BSODs .
     Maybe the OS is not stable ? )

First - I do not like that fact that one of my open trouble tickets was closed - "FF hangs on start-up with no I/O". That problem is NOT RELATED to this problem. The last occurrence was 16 days ago, but since I have done nothing in an attempt to correct the problem, I assume that the problem will arise again. One might think that \the two were related because someone asked for a list of my crash dumps (which I also posted for this trouble ticket). But the closed trouble ticket is associated with FF start-up; it is NOT associated with any FF crash.

Now for a reply to this trouble ticket. I am VERY DISMAYED that the staff who are monitoring this forum and responding to posting DOES NOT HAVE ACCESS TO SOURCE CODE OR COMPILATION LISTINGS. I spent 25 years of my systems programming career working with IBM mainframes. In my job, I was tasked with reviewing all operating system dumps. When I saw a dump that referred to module YYY+ 0xabcde, I would look at the dump,l find the maintenance level of module YYY, pull out the IBM-supplied microfiche, look at the code at offset 0xabcde, and see what the code is doing. I would not have been able to get much information from a dump without access to the source code and compilation listings. When I see that Process Explorer shows that all of the CPU usage is at firefox.exe+0x253b, my first thought is to look at the compiled listing to see what is happening at that place in the code. The fact that the FF support staff does not have access to the compilation listinsg is a MAJOR fault, in my opinion. I will have to go to the MXR site, when it becomes available, to see what I need to get the source, compile it, and link it so that I have the exact same executable as I am currently running.

As for Dropbox - here are the summaries of red-highlighted DLL files in my crash reports, including the one this morning:

06/30/2016 11:32 AM DropboxExt.34.dll 06/28/2016 02:40 PM DropboxExt.34.dll 06/28/2016 10:23 AM DropboxExt.34.dll 06/26/2016 07:46 AM DropboxExt.34.dll 06/26/2016 11:32 PM NPSWF_32_22_0_0_192.dll SHELL32.dll xul.dll icudt56.dll 06/12/2016 11:24 PM DropboxExt.34.dll 06/22/2016 10:48 AM msmpeg2vdec.dll 06/22/2016 09:41 AM DropboxExt.34.dll 06/19/2014 10:24 AM DropboxExt.34.dll mspeg2vdec.dll 06/18/2016 11:01 PM DropboxExt.34.dll 06/17/2016 9:29 AM DropboxExt.34.dll 06/17/2016 12:26 AM DropboxExt.34.dll 06/16/2016 8:26 AM WRusr.dll DropboxExt.34.dll mswsock.dll ws2_32.dll mspeg2vdec.dll 06/15/2016 9:12 AM WRusr.dll DropboxExt.34.dll 06/14/2016 1:22 PM WRusr.dll DropboxExt.34.dll 06/09/2016 3:04 PM WRusr.dll DropboxExt.34.dll 06/09/2016 3:01 PM nil 06/07/2016 8:03 PM nil

Note that many of these reports point to DropboxEWxt.34.dll, but some do not. As I have no idea how the about:crashes utility determines which DLL files to highlight in red, I have no idea how these DLL files might be implicated in the crashes. Note that I am still awaiting a response from my posting on a Dropbox online forum. And I have no idea how Dropbox is associated with FF. I do use Dropbox, and I currently have synching disabled. But when I have a file that I need to put on Dropbox, I need to re-enable Dropbox synching.

It seems to me that what I need to do now is to wait for the MXR site to become available, compile the source, and then determine what is happening in the code at the offset where FF seems to be looping. Unless I can find a web site that has current compilation listings.

As for starting a new FF session - I can do that. But then I would have to access the history to get older tabs into my new session. I know of no way to take a piece of the ,saved .js files and place it into a current .js file. The .js files seem to be files without <cr> nor <lf> characters; so I can not use an editor to edit the files.. I have one window with about 170 tabs. This is for a project that is currently dormant, but which will become re-activated soon. I would like to be able to insert that window into a new FF session without having to open a new window and manually open all 170 tabs.

--Barry Finkel

First - I do not like that fact that one of my open trouble tickets was closed - "FF hangs on start-up with no I/O". That problem is NOT RELATED to this problem. The last occurrence was 16 days ago, but since I have done nothing in an attempt to correct the problem, I assume that the problem will arise again. One might think that \the two were related because someone asked for a list of my crash dumps (which I also posted for this trouble ticket). But the closed trouble ticket is associated with FF start-up; it is NOT associated with any FF crash.

I am trying to help here. You have multiple unresolved issues.

Often i would suggest keeping issues separate. However in your case i think it is better if people trying to help are aware of all the problems, and suggestions made, and that will not happen if you have say 4 open threads that are not in any way linked.

Crashes and startup can be related. After a crash the Firefox profile needs to be sorted out. Firefox may need to attempt to take actions on startup that would have been otherwise completed on an orderly closedown.

Now for a reply to this trouble ticket. I am VERY DISMAYED that the staff who are monitoring this forum and responding to posting DOES NOT HAVE ACCESS TO SOURCE CODE OR COMPILATION LISTINGS.

Well I did see one short comment from a staff member but all the rest are as far as I know from volunteers giving their time freely, to help an open source project that supplies free software.

The red highlighting may not be too significant. I am not sure exactly what it means, a lack of debugging symbols for that module I think. What is in the crashing thread of the report is often the most salient information. (Or even better a directly relevant and solved or active bug report.)

As for starting a new FF session - I can do that. But then I would have to access the history to get older tabs into my new session.

Do what you want with the original session and profile. It is quite easy to run multiple instances of Firefox simultaneously, however in light of your OOM crashes that is probably not something to do at the moment. It's probably safer to only open one Firefox session at a time. Remember you are using a 32 bit version of Firefox and have memory constraints. (64 bit version for Windows is now available, but you seem to be on a 32 bit machine)

I know of no way to take a piece of the ,saved .js files and place it into a current .js file. The .js files seem to be files without <cr> nor <lf> characters; so I can not use an editor to edit the files.. I have one window with about 170 tabs.

That will still be there (with any luck - or hopefully be recoverable) in the original profile. Tip: Syncing Firefox may cause its own issues but is probably a quick and easy method of opening up your 170 tabs. (Personally I do not like sync and rarely use it - Sync syncs bookmarks but sometimes really messes them up - I just make manual backups as needed)

This is for a project that is currently dormant, but which will become re-activated soon. I would like to be able to insert that window into a new FF session without having to open a new window and manually open all 170 tabs.

It is easy enough to transfer that between profiles, manually, then close all the other unused Windows to leave your 170 tabs, it only takes seconds or minutes.

It may have been a good idea to use a profile per project. Until recently open tabs were notoriously fragile. Firefox now is much better at keeping session (Now with multiple potential backups!) History, but it may still be sensible to use bookmarks for such pages. Even if the session state is important at least you are sure of getting back the original webpage page location.

If you are keeping dormant projects as 170 tab windows !! and have multiple windows?? maybe that is a major part of your problem with the restores, startups and OOM crashes.

One of the most important steps you can try is creating a new additional profile for test purposes. It may also be a good idea to try to segregate future individual projects in to their own profiles.

Here is an update to this problem. I have spent a lot of time researching my "vanishing windows" problem, so I have not updated or worked on this one. The problem still occurs, even when I have stopped Dropbox and WRSA. As I have no idea how the crash report viewer determines that a DLL needs to be highlighted in red, I cannot rely on the red highlighting. The crash reports show different reasons, and I assume that when I send the crash reports, someone involved in maintaining the code reviews them. I have renamed the Dropbox DLL, but I have not yet had a need to use Dropbox. I cannot run with WRSA permanently disabled, as WRSA has recently found some items that it has quarantined.

Here are the crash reports for July: Report ID Date Submitted bp-3733be58-34d7-47a2-a8b6-d48702160728 07/27/2016 11:12 PM bp-57b68847-3c8b-43cd-bcdc-15fee2160726 07/26/2016 11:33 AM bp-5360afff-f7fd-4a50-bea7-88f252160724 07/24/2016 02:06 PM bp-fb909e8b-eca0-4bfa-8cd1-c917e2160724 07/24/2016 01:33 PM bp-dee50634-43d7-48c3-93fe-dab3f2160724 07/23/2016 11:13 PM bp-fe4679dc-a225-4241-9fa5-96b5f2160721 07/21/2016 04:34 PM bp-9979bf1e-4e8a-43c2-a6cc-acff02160722 07/21/2016 10:01 AM bp-3f97e4ff-c74b-4978-8552-9aff22160720 07/19/2016 08:13 PM bp-28562c3a-64de-48c0-be21-aea902160719 07/19/2016 08:24 AM bp-f99b81a8-4944-44e5-b2da-9f22f2160717 07/17/2016 04:29 PM bp-fecaeac0-d252-4fd1-9100-273b52160716 07/15/2016 08:45 AM bp-a0625c5a-b3b3-4bb1-bce3-165272160714 07/14/2016 03:22 PM bp-0ca2565d-425f-4c70-b6d6-42ad92160714 07/14/2016 03:22 PM bp-afa4f005-4a59-4a76-b554-0c3e02160714 07/14/2016 02:14 PM bp-89a57495-9fa0-4352-9b3a-d79b02160711 07/11/2016 04:24 PM bp-2fa53ee1-469f-45a8-87df-1c41f2160711 07/11/2016 07:53 AM bp-4007cf51-fa7e-4d06-9c72-0e7d32160708 07/07/2016 08;48 PM bp-102fe479-aa00-4d73-ae83-3d7b42160707 07/07/2016 01:05 AM bp-f9af8845-6ddc-4ee4-b5cd-147e72160705 07/05/2016 02:23 PM bp-84a18a6e-7d55-4d01-9981-779e32160705 07/05/2016 02:18 PM bp-fb91500d-a143-4f1c-87d7-6b9762160705 07/05/2016 08:53 AM bp-ed477ff9-aad8-4349-a40f-059062160701 07/01/2016 04:41 PM

One thing I have noticed - When FF is in its "using lots of CPU" state and I click "Exit" for an orderly shutdown, FF sometimes takes too long to terminate; this causes a crash.

I have to decide what to do next. I really do not want to start with a new profile, as I will be needing soon some of my less-used windows. Last week, on July22 , I installed KB3125574, the Windows 7 maintenance "convenience roll-up" to see if it might contain some patches that would positively affect my problem. But it appears that that maintenance roll-up had no effect on my problem.

--Barry Finkel

Hi Barry, I think there is too much history here (and what is WRSA?) for me to jump in on the technical aspects. However, regarding --

bsfinkel said

I really do not want to start with a new profile, as I will be needing soon some of my less-used windows.

-- if you mean windows and tabs you have open from session to session, you can copy/paste your session history file to a new profile after you create it to work around that concern.

jscher2000 said

Hi Barry, I think there is too much history here (and what is WRSA?) for me to jump in on the technical aspects. However, regarding -- bsfinkel said

I really do not want to start with a new profile, as I will be needing soon some of my less-used windows.

-- if you mean windows and tabs you have open from session to session, you can copy/paste your session history file to a new profile after you create it to work around that concern.

bsfinkel said

Here is an update to this problem. ... As I have no idea how the crash report viewer determines that a DLL needs to be highlighted in red, I cannot rely on the red highlighting. The crash reports show different reasons, and I assume that when I send the crash reports, someone involved in maintaining the code reviews them. ...

Hi again Barry,

Sorry I know this is going to sound unhelpful.

Crash reports are not even all processed. Ones where there is any investigation potentially active will have a bug number listed and linked which shows what is being looked at. Only a very small minority - the most critical or frequent Crash Report signatures get any direct attention. It is still worth submitting Crash Reports because it adds to the data. For similar reasons you could also turn on the telemetry

• Share data with Mozilla to help improve Firefox

I will reiterate prior advice You may create more than one profile. You may also backup the session history folder separately. That allows you to go back in time by inserting old session history in to a different profile. (You would probably do that in a new - or at least a different profile - so as not to destroy the current working profile's session history) You may find it useful and reduces problems if you use separate profiles for each project. Rather than having multiple projects, say (#answer-892939} 170 tabs per Window hanging around as sets of closed Windows that you anticipate will need restoring at a future date.

As I said before {#answer-892980) RED highlights could be suspicious, but as far as I know it only indicates a lack of debugging symbols for that module. it is more important to look at the crashing thread, does that mention the module ? (The Crash report raw data tab lists whether a module has debugging symbols loaded)

Unfortunately I doubt anyone will be able to help you with disappearing Windows issues unless you are able to reproduce the issue in a much more controlled and simpler method as may for instance be possible in a new profile with only one or two websites involved.

You may have more than one issue, but they may all be related in that they involve using a profile with large session history, large numbers of open tabs and requiring a fairly significant amount of RAM.

Summary Unfortunately your usual browsing habits make it way too complicated to try to successfully investigate your problems using ONLY your standard day-to-day working profile.

Here is a problem update. This morning FF went into one of its "using 40% CPU and non-responding" states. So I decided to run MS systeminternals ProcessMonitor. I ran it for three minutes, and it generated a 22,600 line .csv file. During this three minute period I was doing nothing with FF (it would not let me do anything), and the only tabs that I believe would have had any activity were 1) a window where I read a mailbox via the web, and 20 my NOAA radar window, where a new radar image is being loaded every few minutes.

I seem to be unable to attach that 4.1 Mb file to this problem record, and I seem not to be able to use pastebin.

I processed that .csv file, and here are the record counts:

4743 "ReadFile" 3026 for Reader\plug_ins\Accessibility.api 4674 "RegOpenKey" 2514 "RegQueryKey" 2092 "RegCloseKey" 1458 "CreateFile" 1385 "RegQueryValue" 1108 "CloseFile"

795 "TCP Receive"
581 "TCP Send"
555 "RegEnumKey"
425 "QueryStandardInformationFile"
399 "WriteFile"
370 "CreateFileMapping"
292 "QuerySizeInformationVolume"
116 "QueryBasicInformationFile"
116 "RegCreateKey"
110 "FileSystemControl"
 99 "SetAllocationInformationFile"
 99 "SetEndOfFileInformationFile"
 88 "QueryDirectory"
 86 "QueryNetworkOpenInformationFile"
 75 "QueryAttributeTagFile"
 74 "UnlockFileSingle"
 74 "LockFile"
 69 "SetDispositionInformationFile"
 40 "QueryInformationVolume"
 40 "QuerySecurityFile"
 28 "QueryNameInformationFile"
 20 "QueryAllInformationFile"
 20 "QueryObjectIdInformationVolume"
 19 "TCP Connect"
 10 "SetRenameInformationFile"
  8 "Thread Create"
  6 "SetSecurityFile"
  5 "Thread Exit"
  4 "QueryAttributeInformationVolume"
  2 "QueryStreamInformationFile"
  2 "SetBasicInformationFile"
  1 "TCP Accept"

I noticed that there were 3026 ReadFIle requests for the file:

C:\Program Files\Adobe\Acrobat Reader DC\Reader\plug_ins\Accessibility.api

I have no idea why FF would be repeatedly reading this PDF reader API file, as I believe that FF was not downloading any PDF file. I also noticed for this Adobe file these counts:

    183 CreateFile
    183 CloseFile
    366 QueryStandardInformationFile
    366 CreateFileMapping

I do not understand the 183 CreateFile requests, as this file appears to be an Adobe-supplied file. Maybe CreateFile does an automatic Open if the file already exsts?

Is there a way to upload the .csv file from ProcessMonitor?

My main task now is to determine what FF is doing when it is using all of the CPU.

Thanks.

--Barry Finkel

Here is a problem update. In recent weeks FF has been crashing about twice a day, not always preceded by large CPU usage. So I decide4d to run a controlled test.

08/31 15:48 Exit FF. No sessionstore.js file produced. Save 2 recovery files.

09/01 08:30 Start NOAA radar image loop; go to JGSI mail page, start CTA bus tracker map.

09/01 20:11 Read some JGSI mail. check for Faqcebook mail.

09/02 08:15 FF is still behaving normally. Open a new tab to read a death notice online. FF hung and was unresponsive until 08:52, when it crashed. I looked at the crash dump. and when I was finished, I saw another unsent crash dump in the list. From where did this come?

Here are my recent crash dumps; I see no pattern.

bp-65bba045-38cc-4347-88f3-d1b522160902 09/02/2016 09:16 AM bp-47b7d1e1-3ef8-4052-8943-2f6052160902 09/02/2016 08:56 AM bp-503486d6-51a6-4450-b633-2413c2160831 08/31/2016 02:04 PM bp-8f93a2a5-91ac-4965-81b4-ceebc2160831 08/31/2016 09:46 AM bp-21e506b8-da77-41a3-a966-e46802160831 08/31/2016 08:46 AM bp-b4028aa7-f08c-40ff-b82a-d46b12160831 08/30/2016 09:46 PM bp-a5561fb1-308a-4848-a6dc-be9042160830 08/30/2016 03:09 PM bp-3ec9085c-238f-40ad-afbd-6e4572160830 08/30/2016 08:05 AM bp-8501db15-f15c-486f-a5a8-269d62160829 08/29/2016 02:50 PM bp-2a5cbc28-78a2-47e8-84a2-83e4f2160831 08/29/2016 09:02 AM bp-b97c107f-b081-4d2c-a3e5-110442160829 08/29/2016 08:49 AM bp-5df0c235-3c1a-45ec-ab2c-9a7d82160829 08/28/2016 08:24 PM bp-da6d21be-da15-4939-b3d5-053c22160828 08/27/2016 10:56 PM bp-e28bd29f-03ca-4007-8c7c-dea8c2160826 08/26/2016 08:59 AM bp-fcacd7b9-f6f1-40c3-bb6f-32e122160826 08/25/2016 08:53 PM bp-bc225fce-0e44-4ed9-911a-fbab02160824 08/24/2016 04:42 PM bp-643fce3c-1174-4601-aa45-8fe232160823 08/23/2016 12:53 PM bp-fa7acbee-68e8-43cf-b5be-a49df2160823 08/23/2016 12:53 PM bp-be741c38-2c1a-42ca-9b7e-04c912160823 08/23/2016 12:43 PM bp-b62b393e-0b6d-41d8-b3e5-b49c42160823 08/23/2016 09:28 AM

Also, I haven no idea why FF would be reading the Adobe acrobat reader accesssibility.api file, when I am not accessing any PDF files via URLs.

--Barry Finkel

Sorry Barry, others may take this up; but I honestly don't think I stand any chance of helping, unless you try troubleshooting bottom up: i.e. start with testing from a minimal configurations then add something back one at a time.

Here is a reply. We seem to have a basic disagreement that we cannot resolve. I can run with one window and then manually add tabs and windows as I need them. This is a manual process, and it does nothing to determine what may be happening. I am not sure that if I follow your suggestion, and eventually I get to a spot where FF is crashing that I will be able to conclude that the last tab I opened is causing the problem. I have run some controlled tests, and I have no idea what is causing my problems. I have a few questions about what I am seeing:

1) What does "EXCEPTION_BREAKPOINT" signify in a dump? From the name and from my coding experience it appears that I hit a place in the code where one is not supposed to have gone, and there is a breakpoint set to dump at that point. Is this correct?

2) What does "EXCEPTION_ACCESS_VIOLATION_READ" signify? I did some Google searches, and all I found were instances where other users had dumps with this string. Nowhere did I find an explanation as to what this signifies,

3) I have run MS sysinternals Process Monitor 10 times - 7 when FF was using lots of CPU and 3 when it was running normally. In all of the "lots of CPU" traces and in one of the "behaving normally" traces there are many reads of the Adobe Acrobat Reader accessibility.api file. I have not determined when FF would read this file. As far as I know I have no active tabs that are downloading a PDF file. When causes FF to read this file?

Thanks.

--Barry Finkel

Barry you mentioned a while back that you thought the sessionstore status and files may be an issue and I agree that is highly likely.

Note that for a while now (Fx 30 something) Firefox has had an improved method of handling and making multiple sessionstore backups. Once you have a profile backed up and have a clean profile for testing purposes you are able to try out Firefox with no prior sessinostore file or any one of the backups.

I am not suggesting you try Firefox in a clean profile and manually & individually add hundreds of tabs. Instead use sessionstore files. Or if you are more interested in a clean tab use bookmarks. (It is easy to open windows with many tabs from a bookmark folder - creating a folder from a window is easy, taking only a few seconds but is best done in a new profile as it moves existing bookmarks).

BTW The database file holding Bookmarks and History may be involved in hangs or startup/closedown problems and again that is something that is taken out of the equation in a clean profile. Also lets not forget you seem to have a History of multiple issues with Firefox so again using these longrunning sessions does not help with troubleshooting.

Not sure if you ever tried Firefox's safe mode. Please not that is not exactly the same as browsing without History. Further please also note that in some recent Firefox versions the use of clearing History has caused problems, and all of those may not yet have been solved.

You are asking about Reads related to Adobe Acrobat. Again if you try Firefox in its safe mode and with all plugins disabled that would be unlikely to happen. It would be another factor you would not need to worry about causing slowdowns.

The crash signature names should be meaningfull and indicate something about what is happening, but to some extent the names get modified and tuned to help either combine or separate certain signatures, but it is not something I have significant knowledge about.

I can not remember if we ever asked do you use Firefox Sync at all ?

Here is a status update. I did open a bug report - 1308593 - for the repeated crashes in 48.0, and with my sessionstore.js the problem is reproducible. About the session restore files, I am currently looking at the source (47.0.1) to see what the code is supposed to do. I do have problems:

    1) After some (as yet unknown) event, FF does not update the recovery.js file when I open a new tab, open a new URL, or close a tab.

   2) Sometimes, an Exit in FF produces a "clean" termination (i.e., no dump), but it fails to write a sessionstore.js file.

I have a feeling (without knowing the code) that if I make two config changes too close in succession, then FF sets a flag so that the second creation of recovery.js is not done because an existing write is in progress; maybe that flag is not reset.

I have not yet determined if 1) happens and then causes 2). If I find anything (I have to determine where in the code the call is made to start the recovery file write is made), I will open a new trouble ticket. This ticket is concerned with the large CPU usage and subsequent crashes.

I do not use FF sync, as I do not use two devices that I need to synchronize.

--Barry Finkel