Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Learn More

Why is Firefox not re-writing recovery.jsonlz4 file?

  • 23 trả lời
  • 1 gặp vấn đề này
  • 2 lượt xem
  • Trả lời mới nhất được viết bởi bsfinkel

more options

I am running Firefox 65.0.2 in Windows 7 Professional 32-bit. It is 8:16PM on 03/18/2019. The recovery files have timestamps:

    03/05/2019  03:09 PM         2,049,220 previous.jsonlz4
    03/14/2019  09:36 AM         2,124,762 recovery.baklz4
    03/14/2019  09:37 AM         2,124,716 recovery.jsonlz4

Why is Firefox not writing a new file when I open or close a tab? Is there anything I can do right now do get diagnostics on this problem? I believe that tomorrow I may be installing Windows patches and have to reboot, and restarting Firefox will lose all diagnostic data. Thanks.

I am running Firefox 65.0.2 in Windows 7 Professional 32-bit. It is 8:16PM on 03/18/2019. The recovery files have timestamps: 03/05/2019 03:09 PM 2,049,220 previous.jsonlz4 03/14/2019 09:36 AM 2,124,762 recovery.baklz4 03/14/2019 09:37 AM 2,124,716 recovery.jsonlz4 Why is Firefox not writing a new file when I open or close a tab? Is there anything I can do right now do get diagnostics on this problem? I believe that tomorrow I may be installing Windows patches and have to reboot, and restarting Firefox will lose all diagnostic data. Thanks.

Tất cả các câu trả lời (20)

more options

You may have corrupt sessionstore [v56] sessionstore.jsonlz4 file(s). Delete all sessionstore* files and the sessionstore-backups folder.

Type about:support<enter> in the address bar.

Under the page logo on the left side, you will see Application Basics. Under this find Profile Folder. To its right press the button Show Folder. This will open your file browser to the current Firefox profile. Now Close Firefox.

Windows: Show Folder; Linux: Open Directory; Mac: Show in Finder

Linux: Under the page logo on the left side, you will see Application Basics. Under this find Profile Directory. To its right press the button Open Directory.

Locate the above file. Then rename or delete it. Restart Firefox.


Don't delete the files if you need to rescue any data from them, just move them out of the profile folder to some location where Firefox doesn't look for them. You can try to read out their contents using this tool: https://www.jeffersonscher.com/res/scrounger.html

more options

First I have a question. When FF is re-writing the recovery.jsonlz4 file after a tab is closed, a new tab is opened, or an existing tab is changed, does FF read the existing file and modify it, or does FF create a new file from the window and tab data is has in memory? If the latter, then I can not see how a corrupt file would cause any problems in this area.

Now to the diagnostic techniques in your reply - I opened the scrounger.html web page and selected the recovery.jsonlz4 file. I had previously copied the three recovery files to new files with a .yymmdd suffix. During the open process on that recovery.jsonlz4 file, FF crashed - bp-c3ecf420-0fa6-4e1a-ad7f-671b90190319 - and in doing so it lost all diagnostics as to what was happening inside FF. FF came back up with the common message that it could not recover my session, so I clicked "recover session", and FF came back up with the configuration from March 14. I do not know enough about the internals of FF and Windows 7 to be able to determine what caused FF to crash. I still have the saved copy of the recovery.jsonlz4 file if you want it to test the scrounger.html utility.

more options

Product Firefox Release Channel release Version 65.0.2 Build ID 20190225143501 (2019-02-25) OS Windows 7 OS Version 6.1.7601 Service Pack 1

bp-c3ecf420-0fa6-4e1a-ad7f-671b90190319 Signature: OOM | large | xul.dll | do_main

Crash Reason EXCEPTION_BREAKPOINT

Total Virtual Memory 2,147,352,576 bytes (2.15 GB) Available Virtual Memory 351,690,752 bytes (351.69 MB) Available Page File 2,924,630,016 bytes (2.92 GB) Available Physical Memory 107,003,904 bytes (107 MB) System Memory Use Percentage 96

DropboxExt.27.0.dll = Dropbox

xul.dll = Firefox

more options
more options

Sorry to hear about the crash. "Out of memory" could be caused by a build-up of Firefox memory usage from the Scrounger and other tabs until it reaches a breaking point. Probably won't happen again, but just in case, you could run the Scrounger in Google Chrome (I don't think it runs on IE).

As for the other questions, some thoughts:

(A) Please make backups of the session history files somewhere safe in case you ultimate decide to remove them from your profile folder and let Firefox start new ones.

(B) If you haven't shut down and restarted Windows since this problem began, you could try that. It is useful for releasing file locks.

(C) If you are using private tabs, then those won't be added to your session history files.

They also won't be in history, so that would be a way to cross-check.

(D) Firefox rewrites the recovery.jsonlz4 file in its entirety when your tabs change, so it needs constant read/write access to the file.

This occurs as often as every 15 seconds, although you can modify your preferences in about:config to extend the interval if it becomes a drag on performance or you are one of the people who fears wearing out your SSD drive.

To check your session history preferences:

(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 sessionstore and pause while the list is filtered

(3) Any customized preferences should be bold and marked as modified; any preferences that indicate locked would be a red flag.

For example:

  • browser.sessionstore.interval => default value of 15000 milliseconds indicates that Firefox will update your recovery.jsonlz4 file as often as every 15 seconds if your tabs have changed; depending on how much session history you are willing to lose, you could increase this to 30000 (30 seconds) or 60000 (60 seconds) to reduce disk activity.
  • browser.sessionstore.max_tabs_undo => default value of 10 means that Firefox's "Recently Closed Tabs" list will allow you to restore up to 10 tabs you've closed in that window.
  • browser.sessionstore.max_windows_undo => default value of 3 means that Firefox's "Recently Closed Windows" list will allow you to restore up to 3 windows you've closed.

Some preferences contain automatically generated data, such as browser.sessionstore.upgradeBackup.latestBuildID. You can ignore that one.

more options

1) I uninstalled and re-installed Dropbox. IObit Uninstaller said that 68.4.102 was uninstalled and then re-installed. Maybe the re-install cleaned up some things. I have no way of knowing.

2) I ran the scrounger.html file in Chrome on a copy of the restore.jsonlz4 file, and it took a while (and CPU) before it ran to completion. I assume this means that that restore file is not corrupt.

3) As I wrote before, if the restore.jsonlz4 file is re-written after each tab change, then a corrupt restore.jsonlz4 could NOT cause the problem I experienced.

4) I need to reboot sometime, but I am waiting until AskWoody says that it is OK to install the patches released on Patch Tuesday.

5) What I really would like to know is this - if my Firefox gets into this state again, is there any set of diagnostics that I can run to diagnose what is happening? I do not know if a TaskManager or ProcessExplorer dump of Firefox would have the information. Someone would have to be able to read the dump, and I am not sure which of the six Firefox processes I would need to dump.

more options

As for the "Crash Reason EXCEPTION_BREAKPOINT" -- I assume that I hit a spot in the Firefox code that was not expected., and Firefox code produces this diagnostic trace information. Is there something that needs to be fixed in the code?

more options

bsfinkel said

5) What I really would like to know is this - if my Firefox gets into this state again, is there any set of diagnostics that I can run to diagnose what is happening? I do not know if a TaskManager or ProcessExplorer dump of Firefox would have the information. Someone would have to be able to read the dump, and I am not sure which of the six Firefox processes I would need to dump.

You could check Firefox's Browser Console for any error messages related to the session store saving function. As for which process is relevant, it would be the "main" firefox.exe process. If you add the Command Line to your Windows 7 Task Manager Processes Tab, it's the one that doesn't have a childID on the command line. But would it do any good to know that? I'm not sure. If the problem persisted after a Firefox crash/restart, it seems more likely that Firefox is somehow being prevented from writing to the file by a file lock or permission issue.

If you want to save your current tabs to an alternate form of storage since Firefox isn't saving them, you could look at:

more options

How do I access the Browser Console? I did a cntl-shift-k, and I did not see anything there that would aid in debugging this problem. My Windows 7 system is running very slowly, FF is using lots of memory, and nothing will clear up until I Exit Firefoc (which, I assume will crash during the termination process, as it has done frequently). It is now 14:41, and the recovery.jsonlz4 file is dated 10:58. So, I cannot wait for a reply before I Exit FF.

more options

Another update - Firefox terminated without crashing, but it did NOT write a sesssionstore.jsonlz4 file in the parent directory. I assume this is for the same reason that the recovery.jsonlz4 file was not written in the sessionstore-backups directory.

more options

Ctrl+Shift+K opens the Web Console. You need to open the Browser Console and that console has the Ctrl+Shift+J keyboard shortcut.

The Web Console shows messages about the current tab, the Browser Console shows global messages and includes internal browser messages.

more options

I had another occurrence today/yesterday. This morning I saw that the recovery.jsonlz4 file was dated 01:52PM yesterday. FF was running slowly and not responding. I opened a browser console (cntl-Shift-K), but I did not see anything. Would the console contain error messages from 1:52 yesterday? If not, then what can I do to get documentation the next time this problem recurs?

As there was no way I could get good documentation as to what was happening, I did an Exit to restart FF. FF crashed during the termination process AFTER writing a good sessionstore.jsonlz4 restore file (which contained all of my tab updates since 1:52PM yesterday). The crash report I submitted is bp-31e7d5cf-11b6-4aba-9711-9320c0190719 . (And in another thread I am still wondering why FF is crashing after writing the sessionstore.jsonlz4 file.)

more options

You may have corrupt sessionstore [v56] sessionstore.jsonlz4 file(s). Delete all sessionstore* files and the sessionstore-backups folder.

Type about:support<enter> in the address bar.

Under the page logo on the left side, you will see Application Basics. Under this find Profile Folder. To its right press the button Show Folder. This will open your file browser to the current Firefox profile. Now Close Firefox.

Windows: Show Folder; Linux: Open Directory; Mac: Show in Finder

Linux: Under the page logo on the left side, you will see Application Basics. Under this find Profile Directory. To its right press the button Open Directory.

Locate the above file. Then rename or delete it. Restart Firefox.


Don't delete the files if you need to rescue any data from them, just move them out of the profile folder to some location where Firefox doesn't look for them. You can try to read out their contents using this tool: https://www.jeffersonscher.com/res/scrounger.html

more options

bp-31e7d5cf-11b6-4aba-9711-9320c0190719 Signature: AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize on shutdown

Crash Reason EXCEPTION_BREAKPOINT

DropboxExt.27.0.dll = Dropbox

This is for Sumo's Related Bugs 1524200 RESOLVED FIXED Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize on shutdown

1507171 RESOLVED FIXED Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize on shutdown

1426941 REOPENED --- Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize on shutdown

1404105 RESOLVED FIXED Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize,sanitize.js: Sanitize on shutdown

more options

When Firefox closes, do you have it clear any data?

more options

"You may have corrupt sessionstore [v56] sessionstore.jsonlz4 file(s)."

Why would a corrupt sessionstore.jsonlz4 file cause FF to have problems writing a new recovery.jsonlz4 file? And when FF is running, there is no sessionstore.jsonlz4 file. That file is read upon startup and then deleted; it is re-written on Exit. And I still have complaints about the startup message about not being able to resote my previous session, but that is not part of this thread.


"1404105 RESOLVED FIXED Crash in AsyncShutdownTimeout | Places Clients shutdown | sanitize.js: Sanitize,sanitize.js: Sanitize on shutdown"

You do not say what is the disposition of this bug. I am running 68.0 and, IIRC, I saw a pop-up about an update this morning. I forgot to refresh FF to install the update. Is the fix for 1404105 included in this new update?


"When Firefox closes, do you have it clear any data?"

I am not sure. I think that I do not, but I am not sure. From another thread (closed) it was suggested that I clear saved data, data that are used if FF is running without an Internet connection. At that time I did clear these saved data, and the process took some time (so I know that something was being done). I did this once. Two questions that still have not been answered:

1) Do I have to do this periodically in order for FF to create a crash window immediately instead of up to five minutes after the crash occurs?

2) If the answer to 1) is yes, then is there a sewtting I can change so that FF does not save these data?

Thanks.

more options

bsfinkel said

"You may have corrupt sessionstore [v56] sessionstore.jsonlz4 file(s)."

. . . . That file is read upon startup and then deleted; it is re-written on Exit

Not correct. The file is read if needed. After, the browser updates the file each time you open/close any window/tab.

If Firefox should crash, the file is used to recover the last session. As well as restoring the last session on user request.

more options

FredMcD said

bsfinkel said
"You may have corrupt sessionstore [v56] sessionstore.jsonlz4 file(s)."

. . . . That file is read upon startup and then deleted; it is re-written on Exit

Not correct. The file is read if needed. After, the browser updates the file each time you open/close any window/tab.

If Firefox should crash, the file is used to recover the last session. As well as restoring the last session on user request.

In Firefox 56+, during your session, Firefox writes window/tab changes to recovery.jsonlz4 and recovery.baklz4 in the sessionstore-backups folder. The sessionstore.jsonlz4 file doesn't exist during your session.

more options

I looked through the bug discussion thread for 1404105, and I could not tell if that bug has been fixed, and if so, in what release. And I still do not have answers to my questions 1) and 2) above in a previous post.

more options

I am updating this because I need more information. The basic problem is that sometimes something happens within Firefox that causes Firefox not to write the recovery.jsonlz4 file. My basic question is this - When this happens, what can I do to aid in determining what is happening?

JScher2000 wrote, in a reply above. "You could check Firefox's Browser Console for any error messages related to the session store saving function. As for which process is relevant, it would be the "main" firefox.exe process. If you add the Command Line to your Windows 7 Task Manager Processes Tab, it's the one that doesn't have a childID on the command line. But would it do any good to know that? I'm not sure. If the problem persisted after a Firefox crash/restart, it seems more likely that Firefox is somehow being prevented from writing to the file by a file lock or permission issue."

I use cntl-shift-k to open a console, but I have no idea what do do after the console pop-up windows appears. There are a number of tabs in that window. Is there documentation on how I can use this console to determine why the recovery file is not being rewritten? Thanks.

  1. 1
  2. 2