Copy link to clipboard
We have still problems using the flash player. Since version 18.104.22.168 until version 22.214.171.124 flash player crashes while using some web applications in all browsers. Strange but true: the BETA version of flash player 126.96.36.199 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 188.8.131.52 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 184.108.40.206. 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)
[Updated subject to more accurately describe the issue]
Copy link to clipboard
Same issue, IE11 still crashes on Windows 7 x64 Norwegian OS. Confirmed on several computers October 26th. We still have to use 220.127.116.11, 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 (18.104.22.168).
The out of cycle release we shipped for the VMWare vCenter issue was very surgical, and only included the contents of Flash Player 22.214.171.124, plus the one specific change that addressed that crash. Similarly, 126.96.36.199 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 188.8.131.52, 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.
Copy link to clipboard
With Version 184.108.40.206 / 170 Same issue, IE11 still crashes on Windows 7 x64 Crash IE11 when using BMC Remedy.
IE11 Crash also on using games in Facebook
Thank you for reporting the issue; however, there's not sufficient detail to investigate effectively.
Please see the following guide on how to report a crash or error:
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 220.127.116.11 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.
IN IE11 With Flash ver 18.104.22.168 or 170 After 30 sec BMC Remedy Crash also game Stormfall in Facebook same problem.
May be this will help
Erro in IE
Problem Event Name: BEX
Application Name: IEXPLORE.EXE
Application Version: 11.0.9600.18817
Application Timestamp: 59b18749
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00000008
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 4105
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Windows Data Execution Prevention detected an add-on trying to use system memory incorrectly. This can be caused by a malfunction or a malicious add-on.
in.Crash dmp file
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: srv*
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Debug session time: Mon Oct 30 09:20:31.000 2017 (UTC - 4:00)
System Uptime: 2 days 18:06:04.416
Process Uptime: 0 days 0:01:07.000
Loading unloaded module list
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1bfc.b84): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=0421bc30 ecx=0c0beb68 edx=0c74dd18 esi=00000002 edi=00000000
eip=7737016d esp=0421bbe0 ebp=0421bc7c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
7737016d 83c404 add esp,4
Symbols for 74f50000 kernel32.dll -> kernel32.dll
Loading symbols for 5de80000 Flash32_27_0_0_183.ocx -> Flash32_27_0_0_183.ocx
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Flash32_27_0_0_183.ocx -
ChildEBP RetAddr Args to Child
0421bbe0 7525171a 00000002 0421bc30 00000001 ntdll!NtWaitForMultipleObjects+0x15 (FPO: [5,0,0])
0421bc7c 74f619fc 0421bc30 0421bca4 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100 (FPO: [Non-Fpo])
0421bcc4 74f641d8 00000002 7efde000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0 (FPO: [Non-Fpo])
0421bce0 74f880bc 00000002 0421bd14 00000000 kernel32!WaitForMultipleObjects+0x18 (FPO: [Non-Fpo])
0421bd4c 74f87f7b 0421be2c 00000001 00000001 kernel32!WerpReportFaultInternal+0x186 (FPO: [Non-Fpo])
0421bd60 74f87870 0421be2c 00000001 0421bdfc kernel32!WerpReportFault+0x70 (FPO: [Non-Fpo])
0421bd70 74f877ef 0421be2c 00000001 d6431067 kernel32!BasepReportFault+0x20 (FPO: [Non-Fpo])
0421bdfc 773c5b57 00000000 773c5a34 00000000 kernel32!UnhandledExceptionFilter+0x1af (FPO: [Non-Fpo])
0421be04 773c5a34 00000000 0421fc54 7737c620 ntdll!__RtlUserThreadStart+0x62 (FPO: [SEH])
0421be18 773c58d1 00000000 00000000 00000000 ntdll!_EH4_CallFilterFunc+0x12 (FPO: [Uses EBP] [0,0,4])
0421be40 773b34c9 fffffffe 0421fc44 0421bf7c ntdll!_except_handler4+0x8e (FPO: [Non-Fpo])
0421be64 773b349b 0421bf2c 0421fc44 0421bf7c ntdll!ExecuteHandler2+0x26 (FPO: [Uses EBP] [5,3,1])
0421be88 773b343c 0421bf2c 0421fc44 0421bf7c ntdll!ExecuteHandler+0x24 (FPO: [5,0,3])
0421bf14 77360143 0121bf2c 0421bf7c 0421bf2c ntdll!RtlDispatchException+0x127 (FPO: [Non-Fpo])
0421bf14 00000008 0121bf2c 0421bf7c 0421bf2c ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0421bf7c)
0421bf14 00000008 0121bf2c 0421bf7c 0421bf2c ntdll!KiUserExceptionDispatcher+0xf (FPO: [2,0,0]) (CONTEXT @ 0421bf7c)
0421c4b4 5e00360f 00000001 0a6c9000 00000001 Flash32_27_0_0_183+0x19b3ea
0421c600 5e0bd0d1 00000001 00000001 00000000 Flash32_27_0_0_183+0x18360f
0421c650 5e0c47ea 00000401 00000001 0a6c94b0 Flash32_27_0_0_183!DllUnregisterServer+0x1e9b7
0421c764 5e099a5e 00000401 00000001 0a6c94b0 Flash32_27_0_0_183!DllUnregisterServer+0x260d0
00000000 00000000 00000000 00000000 00000000 Flash32_27_0_0_183!DllCanUnloadNow+0xedf
I try to login in the Bugtracker to report and to send the crashdump but cannot get the login screen from the Traker page.
More info: I roolback to flash ver 26 and it work fine. We have the bug on all ours PCs.
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 (22.214.171.124) 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 126.96.36.199.
If the issue is fixed in 188.8.131.52, then those fixed will be included in the next scheduled monthly update. Barring any unforseen catastrophies, it would land on November 14th.
As this thread reads, this has been an issue since the release of 184.108.40.206 on October 10th and carried over into Your Adobe Flash in the out of cycle update 220.127.116.11 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!!!
Thanks for sharing your opinion.
We've been working on a Flash Replacement using HTML5, well this issue has pushed my Beta to live quicker than I would have liked.
Why Adobe keeps pushing bad code for three versions is questionable at best.
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 18.104.22.168 to address the issue with enterprises struggling with large vCenter deployments in 22.214.171.124, it was a single, surgical change, overlaid on the original 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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.
Details are in the admin guide, here: