We have still problems using the flash player. Since version 27.0.0.159 until version 27.0.0.183 flash player crashes while using some web applications in all browsers. Strange but true: the BETA version of flash player 27.0.0.180 works fine in all browsers with all applications we use. So we have to use the BETA version for most of our employees to provide crashing the browser all 10 seconds. Please publish a new stable version asap, as the BETA version 27.0.0.180 is. I don't know why Adobe offers such unstable versions to the public while they have stable BETA versions. I have to administrate a lot of devices and we have a lot of work because of this unstable flash player since version 27.0.0.159. Before this version we never ever had problems at all with flash player, so I wonder why this happen now and won't be fixed. We use Windows 7 SP1 and Internet Explorer 11 with the latest patchlevel and the newest Firefox version (56.0 (64-bit or 32-bit)

Same issue, IE11 still crashes on Windows 7 x64 Norwegian OS. Confirmed on several computers October 26th. We still have to use 27.0.0.130, we're not rolling out beta software. We don't have vSphere. Just regular computers with regular OS setups.

Thanks for the update. It sounds like the crash you're experiencing is distinct from the one that we fixed with the out of cycle update we just released (27.0.0.183).

The out of cycle release we shipped for the VMWare vCenter issue was very surgical, and only included the contents of Flash Player 27.0.0.170, plus the one specific change that addressed that crash. Similarly, 27.0.0.170 was also an out of cycle release, and contained only the single surgical fix to address a security issue in the wild. In contrast, the beta builds contain everything that was commited to the branch since 27.0.0.159, so it sounds like your crash is fixed, and will ship with the next regularly scheduled update.

We're not planning another out of cycle release, and are currently wrapping up the end-game for the next regularly scheduled monthly release, which you've indicated contains the fix that you're looking for.

I've updated to 183 and IE is still crashing my video player, works fine in Chrome, Safari and Firefox. We have this issue at multiple sites around the world on computers managed by various organizations.

I can't publish the link publicly, but if you contact me I will give you the link to test.

I have submitted a bug issue earlier today with my link. I just found a older computer that is running IE11.0.38 and Flash 24.0.0.194 and my video played as it should, no more crashes. Adobe please correct your software.

Thanks for the details. I took a look and was able to identify the offending change. Given the timing, it will be challenging to get anything in for this release, and this is in an area of code that has a high-risk for side effects. This is actually fallout from another fix-for-a-fix, and is specific to some IE quirkiness.

As a workaround, if you can eliminate the HTTP redirects in that content and point directly to the resources being used, that would probably stop the crashes in the meantime.

What's the bug number for the bug you filed? I'll go back and link it with the one I opened internally.

I need the actual .dmp file in order to resolve the symbols. The memory offsets don't tell me much. A link to a hosting service is the best way to do it, adobe send, google drive, dropbox, etc.

Anyway, have you tried the latest beta (27.0.0.180) at http://www.adobe.com/go/flashplayerbeta? There's a good chance that the fix is already in the beta. It includes a bunch of changes that aren't in 27.0.0.183.

As this thread reads, this has been an issue since the release of 27.0.0.170 on October 10th and carried over into Your Adobe Flash in the out of cycle update 27.0.0.183 that was released on October 16th. I know these dates well because we have been dealing with the headaches of this since then and due to many software items only being qualified for use with Internet Explorer, its a constant headache!

I'm sure Many more organizations and people in general are affected by this than you are hearing, its takes a tremendous amount of sleuthing to find details on this such as this thread because they don't filter up in just normal Googling the issue.

It's Only my opinion (and yes I know what the old saying goes about you know what an opinion is like ) BUT I think its ABSURD that Adobe will NOT release another out of cycle version contain the fixes that are within the BETA 180 and make users wait until November 14th!!! By goodness IT needed to be said and I don't have a problem saying it!!! That will mean this issue remained in place for Over a Month before being resolved!

If I Have Offended Anyone...Dilly Dilly...To the Pit of Misery For You!!!

As you've observed, when we rush changes out the door, our ability to test is limited, and we can't simulate every possible scenario. We try really hard, but the math on the possible things you can do in the language across all platforms and under every conceivable network scenario put "test absolutely every possible condition" on a timescale closer to before the heat death of the universe than before next patch tuesday. Like every QA organization, we employ a variety of strategies, quality control measures and tools to increase our chances of finding every problem before it ships, but bugs are a hard reality.

When dealing with a security issue being exploited in the wild, our approach is to shut the exploit down and get people protected. While we try not to break things under those circumstances, securing the attack surface is the priority. Functional issues are a secondary consideration under those circumstances. It's not reasonable to wait for weeks to fix security issues in the wild, but that necessarily means that we're going to use an abbreviated testing approach, and there's no opportunity for public betas.

It's also worth pointing out that in the instance of the particular issue you're experiencing, only a small subset of the population is affected, the issue was discoverable in public betas before it shipped, and it wasn't introduced by the single, surgical security change that we made and later amended.

When talking about out of band changes, they're necessarily surgical. Isolating out of cycle builds to a single, surgical change clears an optimized path for testing and release by both our industry partners, like Google and Microsoft, and for the community of Enterprise administrators, many of which would otherwise be required to perform certification testing prior to releasing the build to their administrated populations. If we were to try to include ancillary stuff, our partners would push back, enterprise administrators are blocked from releasing, and we increase the chance that there are unforseen side-effects.This guides our approach.Similarly, when we amended the security fix in 27.0.0.170 to address the issue with enterprises struggling with large vCenter deployments in 27.0.0.183, it was a single, surgical change, overlaid on the original 27.0.0.159 build.

We do not, as policy, ship out of cycle releases for functional issues. All changes have a risk of side-effects, and functional issues don't meet the bar for waiving all of the testing at Adobe and various partner organizations, or the evaluation conducted by the millions of active beta users. Flash Player 27.0.0.183 was a rare exception, and it required an extensive amount of research and justification to even be considered.

We conduct extensive certification tests (we have about 30k tests (discounting unit and programmatically generated tests), that we run on multiple machines across dozens of browser/os/language combinations, using a small army of people,We do that on every regularly scheduled release.Despite all of that, when you're talking about ~2.5 billion installs, there are going to be edge cases that we can't catch. To shore that up, we make beta builds available so that developers and administrators can identify issues and ask for corrections before we ship. In that vein, each out of cycle releases also requires testing.Testing consumes finite resources.The out of cycle testing eats into the capacity that we have to do the regular certification testing, which feeds a vicious cycle.There's also a finite number of patches that administrators and end-users are willing to take.

At the end of the day, we have to walk a fine line of choosing the least bad of manifold bad options, balancing the needs of a massive user population with practical engineering and logistical realities. This isn't a website where we can just continuously push in real-time. We're talking about patching 2.5 billion clients, including tens of thousands of enterprise organizations. That's not to mention the logistics involved in pushing ~50 petabytes of data in 24 hours.

We understand that this is causing you pain, and we're not happy about it either.We also don't want to put you in this position again, so we hope that you'll actively take advantage of the availability of our beta releases for proactive testing and bug reporting. I realize that answer is probably not satisfactory for you, but the reality is that this doesn't meet our rubric for an out of band release. We're doing this right, taking the time required, and are on track to land a fix in the next scheduled public release. Hopefully you find the context useful, or at least interesting.

after the first tests of today's official version 27.0.0.187 the bug really seems to be fixed. The vcenter web client works fine with this version. Thank you for your work. But one thing I wonder: Why can't you officially release a well-functioning BETA version asap to help thousands of users? We have some relevant web applications in the company that have stopped working and now a lot of work to remove the BETA version from the devices as a direct update with the official version is not possible.

Deploying beta builds is one of a number of administrative options you have at your disposal in the event that you're impacted by a functional issue.

We would highly recommend that you test future beta builds against your critical applications and offer feedback about problems as early as possible. While we have extensive in-house testing, we can't test everything, and sophisticated enterprise applications are characterized by the fact that they're inherently not accessible to us. Feedback is extremely helpful, especially for enterprise organizations. We want to head those problems off *before* they hit the market. Once the build has shipped, you're generally stuck with it until the next monthly update.

It's also important to note that we don't control the distribution pipeline for IE and Edge on Windows 8 and higher. The only way to install updates on those platforms is to ship the update via Windows Update. Each out of cycle release has to be negotiated with our partners. Unless we're specifically addressing a security issue being exploited in the wild, our partners are under no obligation to distribute those updates. This weighs heavily into our decision-making process. Unless the issue is both widespread (at the scale of billions of deployed clients) and severe, it's unlikely to meet the rubric. This issue did not meet that criteria.

That said, if you're administratively managing the deployment of Flash Player, you can run the uninstaller silently before performing the update. This should remove the beta and pave the way for the installation of the release build, and can be performed automatically in a managed environment.