Private Browsing data still in memory while Crash Reporter is open?
Just had a session crash on me, still got the Crash Reporter open. It was a session with a Private Window open, in which I was doing most of my work. Six months, that is, of work and reading. I'm aware of the general irretrievability of private browsing sessions, but it seems a good idea to be very certain and exhaust the possibilities before I unpause my meltdown.
Like I said, the Crash Reporter is still open. Looking at it now. With the language suggesting to me that as long as I leave it open, Firefox hasn't quit or restarted in "full", to my understanding—that the session is still extant in some way. With the checkbox 'Include the address of the page I was on' too... Well, the page I was on was in a Private Window all right. Unless there's a loophole not noted in the Reporter that it can't/doesn't retrieve addresses from private browsing, or that it automatically substitutes the last non-private address, etc.... Then this means the information still exists, doesn't it? Crash be damned? Right now, at least as long as the reporter is open... The implication to me is at least that one bit of information is not completely lost. And if that's not lost, then maybe the other pages in the tab aren't lost yet either. Or all the other tabs in the window. Or the copious notes I'd been maintaining in the address bar's history.
Not that I think there's somehow a quick fix/retrieval possible, but if there's anything at all possible here, I'll try and do it. Regardless if it goes far beyond what can managed through Firefox normally. Private Browsing data is stored in memory, right? So if my surmise that the data has not actually been flushed from memory yet is correct, isn't there something radical I can do to freeze or dump the current state of my memory? Maybe the entire state of my system even, such that the data can be analyzed/retrieved at a later time? Whether it requires a technical touch and mastery leaps and bounds above my current literacy, or if it would need to undergo some drawn-out, folding@home-esque process to be decompiled and analyzable... Literally, if something is possible in this situation where I at least think the data still exists and is calling back or accessible to the Firefox application in some form, I need to consider it.
I'm running Windows 10 and Firefox 74 (again, tells you how long it's been since I restared Firefox). Anyone who can potentially assist or help guide me through this little Armageddon, you have no idea how much your help would be appreciated. Conversely, if you know for a fact that the tiny shred of hope I'm clinging to per my conjecture about the Crash Reporter and the current state of my Firefox is wrong... Then fire away, it's a bullet I guess I'll be biting.
השתנתה ב־ על־ידי OMT
כל התגובות (6)
Bump. Still got the Crash Reporter hanging out here. Again, I might've made it difficult given the direness of the situation, but don't be afraid to give me the bad news if that's what I've got coming my way; it's just important said news be 100% accurate before I take my definitely irrevocable pick of "Quit" or "Restart". And I realize this is potentially as much of a Windows/PC troubleshooting question as it is a Firefox one, but what Firefox is still holding in my memory now is the key here. Thanks.
I believe the Mozilla Crash Reporter is a separate program from Firefox, although when I have seen it, it seemed to have access to the URL I crashed on (I think it asked permission to share that).
If you check the Windows Task Manager (Ctrl+Shift+Esc), Details tab, is firefox.exe still using any memory on your system? Of course, even if Firefox still is holding on to some memory, I don't know how you would access it in a usable manner...
the crash reporter will create a dump file at %appdata%\Mozilla\Firefox\Crash Reports\pending which *may* contain *some* information that was in the memory of the crashing process. i don't have any insight in how to analyse that or extract further information from this but it might be worth copying the .dmp file there from the ongoing crash at least.
jscher2000: Right, I had just the idea to check that in the hours after, and it would of course do a lot for my peace of mind to see that Firefox is there, taking up real estate in memory. Unfortunately, that is not the case -- only the Crash Reporter itself is showing under running processes. But as I've mentioned, there is language in the Crash Reporter window such as "Your crash report will be submitted before you quit or restart." that is giving me pause before I do anything further.
philipp: Whether or not this pans out, this could be a fantastic lead, which I thank you wholeheartedly for. Among the many DMP, GZ and EXTRA files in this folder, there are actually several which overlap with the timeline of the crashed session, in spite of just the one crash, e.g. there are files dated from March, April and June in addition to the files that seem to be an exact match for the crash (8/28)...which are also much larger than the others. Very curious to me; think I should copy all of them? And as best you know, are you sure I should be disregarding the .extra files that pair off with the .dmp ones? Again, thank you so much.
the .extra files will contain some human-readable metadata to a particular crash reports when you open them in a text editor, but no information about open tabs (except the one that was active at the time of the crash).
I see. Couldn't hurt, so I suppose I'll just copy them both along with the mysterious (to me anyway) DMP files with no apparent corresponding crash.
Guess the only thing I have left to ask here is if there are any recommendations as to where I should head with questions about possibly, eventually frankensteining something out of these DMP files or even my system memory. Knowing full well this is probably a lost cause, but... Yeah, it'd be a help if someone could point me to any resources or communities that are particularly helpful/relevant/active before I commence this wild goose chase. Thanks again guys.