I followed your link to report a bug and I filled out all lines/attached all files in last submitted crash report to the best of my ability but when I get to the bottom, the submit bug will not let me submit..get no error message or any indication of what is wrong or missing from my report
Feel free to just put that information in this thread. I'll be happy to file it on your behalf. I really just need the crash dumps, or the links to the Mozilla crash reports...
I think I did it finally..do you need the number?
I could not find a file ending in .dmp so I attached all..hope you go what you need..I did my best..let me know if you need anything else
Yeah, please take a look at that guide on filing an actionable crash report. I can't do anything without a crash dump or a link to a Firefox crash report. I left a more details comment in the bug.
Also, if you haven't rebooted since you started experiencing crashes, that's step one. If the problem goes away, the machine is just in a bad state. If the problem persists after a reboot, then crash dumps are a necessary next step.
I do not see any instructions on an actionable crash report..only to enter about:crashes and save the last submitted report which I did and copied all the files in that folder on the bug report. I guess I am not savie enough to help you help me. Sorry. I have rebooted several times and issue continues. I guess I will just have to keep just closing windows and reopening Firefox to play my games that use flash and hope others have this issue and you can resolve it generally that will help me. Thank you for your time.
I don't see any attachments or links in the bug. Feel free to just put them here.
I tried again and it said I added a couple of files..hope it is the one you need
Here's a direct link to the crash report for posterity:
https://crash-stats.mozilla.org/signature/?product=Firefox&signature=hang%20%7C%20NtUserMs gWaitForMultipleObjectsEx%20%7C%20mozilla%3A%3Awidget%3A%3AWinUtils%3A%3AWaitForMessage%20 %7C%20base%3A%3AMessagePumpForUI%3A%3ADoRunLoop&date=%3E%3D2018-10-03T12%3A50%3A52.000Z&da te=%3C2018-10-10T12%3A50%3A52.000Z&_columns=date&_columns=product&_columns=version&_column s=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort= -install_time&_sort=-date&page=3
It's technically a hang, not a crash in the true sense. Interestingly, Flash Player isn't visibly involved when this happens.
The heart of the issue is that Firefox and Flash are exchanging messages and one side either fails to deliver a response, or it's getting dropped or sent out of order in a way that causes the conversation to fall apart. Execution then gets stuck until Firefox's hang protection kicks in, at which point it kills the Flash process and you see the crashed plugin message.
It's low-volume. There are 179 reports. All of those reporters are using Windows 10 and AMD processors, but I see a bunch of unique reporters – it's not all the same machine. It's probably a problem that only happens with very specific timing, which is why you see this 100% correlation to this very small audience with the same set of very specific hardware.
On the bright side, you probably wouldn't run into this on any other browser. That's probably your best workaround – just play Farmville in a different browser.
This issue is interesting, but it's some really subtle misfire in an interaction that happens at the intersection of two distinct software products. It's not going to be a thing that gets fixed quickly. It's very likely that it's an issue on the Firefox side of things.
Because this is hardware specific, it's unlikely that we're going to be able to reproduce this, and Mozilla's policies don't allow them to share the raw crash dumps (.dmp files) with us. In this particular instance, it would be really helpful to get some actual minidumps that we can look at, but there's not necessarily a guarantee that they'll be actionable. (See that crash reporting link for details on how to grab the actual minidumps – but you'll probably need to reproduce the crash again before you can follow them).
I am impressed..thank you for all your patience with me. Would it help
if I forwarded your comments to firefox??
No, we work closely with those guys (and there are a lot of Flash alumni over there). At the point that we have a real technical analysis (which we really need a .dmp file for), we'll either fix it, or file a bug with a detailed analysis so that they're able to deal with it with minimal hassle.
ok..I will work or trying to get you those mini dump files if I can. FYI, I have an intel processor and if I use Edge as the browser it also "crashes" and I get the exclamation point and that is why I changed to Firefox.
I did find a crash dump file in Window C>Users>Me>AppData>Local>Crash Data but there is nothing after 9/16/2018. so I bet I am in the wrong place. I just cant follow the instructions to see how I can create and locate these "Mini" dump files on Firefox. . All I know i I left Internet Explorer and Edge years ago because Flash would not work properly there and went to Firefox and it has been faithfully accurate and flawless for me for over 1.5 years. All this started with the last Flash update so in my novice mind it must have something to do with flash or communication as you expressed..I am just so confused and frustrated. What in the heck am I missing?
In the meantime, On Firefox, if am playing a flash Zynga game, if I go to my Home page and let it fully load I can then go to another flash game without a problem so I guess that is what I will have to do until this issue can be fixed (if it can)..
The exclamation point is the "Out of Memory" icon. We occasionally use it as a shortcut to bail out when we see something really low-level that we think is sketchy from a security perspective, but those are conditions that you should really never run into with legitimate content. If you're hitting it on a game, you're probably running out of memory. If you think it's suspect and want us to look at it, just give me instructions on how to reproduce it.
When you submit crash dumps to Firefox, those files get deleted. You'll need to wait until you run into the crash again, and then grab the files before you submit them.
will they apear in the link i mentioned above? How do I save them as there are a few older crash dump files there and there is no option to save or save as.
I browsed at that crash report link you sent before and it truly is way above my computer Knowledge. I did however see something that peaked my interest and a comment you made that my issue was mostly with AMD processors. One of the tabs said I had (or just the issue had and now me) Architecture of AMD, This laptop has a label that says I have intel Core i5 7th generation processor. I thought a processor was either Intel i5 or some type of AMD. Why did the crash report say I had (or it referenced) AMD? I am just curious to learn. If you have time to explain I would appreciate it..I am 73 yrs old but still like to learn. Thank You
That's a really good question for Firefox. They're definitely logging the architecture as amd64. They use a Google library called CrashPad for the actual crash logging, and their own project called Soccoro for analysis and aggregation. That stuff is pretty mature. It's hard to know whether it's a problem with the actual crash data or in how it's getting stored or displayed. They'd have to dig into it, but it's interesting.
If it's an Intel CPU, I'd expect to see it log x64. Seems like a bug on their side, but it also seems super weird and like something that would get noticed pretty quickly.
It gave me a good excuse to say hi to an old colleague, so I shot him a link to your crash report as a head's up.
Thx So how do I send all this to Firefox?
Sent from my iPhone
Is there any way you can just submit it to them snd reference our conversation?
Sent from my iPhone
Cool. I stand by the assertion that it's timing-related, but it's important that the instrumentation we're depending on for post-mortem analysis is accurate. I'm curious to see what's going on there, but I expect it to be pretty limited in scope.
Ok I will await your next post. Again thank you !
Sent from my iPhone
Cool. To be clear, because this is a low-volume issue that isn't easily reproducible, it's not going to be a high-priority thing. You can probably work around this by using a different browser (e.g. Chrome).
I understand..I actually found the folder of the .dmp files from Mozilla that you wanted to see. There are lots of them. I went back to the beginning of this chat and found the bug report link and added a few dump files from Firefox..if you need more let me know.
I am not sure if our problems are related. But I thought I'd post my issue for comment just to be suret
I manage about 4500 Windows endpoints for a public school district in Upstate New York. We have been dealing with difficult issue ever since we deployed FlashPlayer v31.0.0.x to our Windows 10 1803 x64 clients running Firefox ESR v60.2.2 x64 (back in late September of 2018.) We have Firefox configured to launch to our district's homepage of pittsfordschools.org. It is hosted by Blackboard.com.
In the past, we had successfully deployed and used FlashPlayer v27 -> v30 in this configuration without issue. When we upgraded to v31, we got widespread reports of Firefox hanging/locking up to the point that it had to be forcibly terminated by the end-user. We have done considerable internal testing on the issue, and when we found that it only seemed to happen when browsing to our website, we opened a case at blackboard.com. They have not been able to identify a cause stating they do not offer flash support via their hosting.
Here is what we have observed:
1) This issue has only happened on FlashPlayer v126.96.36.199 and v188.8.131.52
2) It appears to happen with all versions of Firefox and Firefox ESR v60 or higher. (w/Flashplayer v31.x)
3) Interestingly enough...the issue does not consistently always occur on every hardware platform. Systems with Intel Mobile processors manufactured in the last 3 years will produce the issue 9 of 10 times. Systems with Intel 1st, 2nd, and 3rd generation desktop processors may have the issue 1 out of 20 times.
4) Uninstalling Flashplayer or rolling back to v30 or lower CORRECTS the issue every time.
5) This issue has been observed on other Blackboard hosted sites
6) homedepot.com ---> The issue also happens when using the SEARCH function on homedepot.com
7) Naturally, This does not happen with Microsoft Edge and the Flash plugin supplied via Windows update
I have gone over the Flash administrator's guide with a fine-toothed-comb, looking for anything that was somewhat unique to Flash v31. I attempted to modify the local mmc.cfg file using each/all of the following settings, but none helped correct the issue.
We have taken computers off-site to eliminate our internal network configuration / webfiltering. - but the problem persists.
We have attempted clean OS installs (to eliminate Windows Updates) - to no avail
We have attempted driver updates/rollbacks - no dice
We have attempted BIOS updates on the most affected hardware platforms - no luck
This issue is frustratingly difficult to replicate, but on the proper hardware platform, we can make it break most of the time. This may be what there have been limited reports of this issue so far. We feel the issue is likely tied to FlashPlayer, but we also lightly suspect that this might have ties to how Firefox Quantum handles processor threads and hardware acceleration. But that's a bit of a longshot.
So here I am.
I NEVER post on forums, but this issue is severely impacting or District and I need to find an answer other than uninstalling Flashplayer.
Many Thanks to All
I'm on sabbatical for a few weeks, so I'm not going to be around to follow up, but I was checking mail for another reason and saw this come in and felt compelled to respond.
A couple things off the top of my head:
- Adobe doesn't provide direct support for free products, so the forums are your best bet. The engineering team (including me) watches them pretty closely, so you can't really ask for better access to expertise.
- Start a new thread. It's easier to give you personalized advice that way, and it doesn't spam all of the other people on this thread.
- Last time I checked, Home Depot didn't use Flash for search.
- I'm also not hearing about widespread stability issues with the Firefox ESR. We work closely with those guys (and have a lot of old colleagues working there), and they're usually very quick to reach out.
- I believe it's happening, but it's something nuanced and probably specific to your environment.
- Provide some crash dumps and/or hang reports if you can
- Actual .dmp files are super helpful, as Mozilla's EULA prevents them from sharing dumps on your behalf
- Firefox crash reports are also good (see about:crashes), particularly if it's truly a hang (this might not generate a dump)
- Report a Flash Player crash or error <---- here's a good guide
Yeah. I am aware that both Blackboard and HomeDepot do not use flash. Its a brain-scratcher, no-doubt. But the observations I have included have been solidly vetted. I was just hoping one of them might have rung a bell for the experts who shepherd this forum.
I definitely agree our environment was a potential player. That is why we conducted a clean OS install off-site and retested - but we got the same results.
I will go back to collecting relevant data in hopes of finding the bugger.
Thanks for the suggestions.
Crash and hang dumps should tell us what's up (even if it's not us). If you can just grab a few from about:crashes on a representative machine, that's the best thing you could do to move this forward...
I've had similar problems over the last few months on several different machines (Win 10 home and professional). They key to all of mine was that in task manager there would always be a "plugin container" sub-process running under the FF process. Once that is killed the browser session freed up and I was able to go on.
The solution for me was to uninstall 64-bit Firefox and replace it with 32-bit Firefox.
Hope that helps.
For 64-bit Firefox, Mozilla created a native NPAPI sandbox. This is actually the way it should be. For historical reasons, we tacked our own sandbox on to the wrong side of the NPAPI interface for 32-bit sandbox, because an NPAPI sandbox didn't exist in Firefox at the time, and we saw an urgent need for it when looking at a rapidly evolving threat landscape targeting in-process plugins.
The thing is, having a 64-bit memory address space makes it way harder to conduct memory-based attacks, because the address space is sparse. You typically don't have things bumping up against each other in the same way that you would in 32-bit address space, which makes security issues related to small out of bounds memory accesses much less reliable.
If it were me, I'd prefer the 64-bit Firefox ESR, or I'd use another 64-bit browser that works well, particularly if I was doing anything sensitive during that browsing session.