New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 572131 link

Starred by 68 users

Issue metadata

Status: Archived
Closed: Dec 13
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocked on:
issue 413889

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Adobe Flash Player cannot load properly after a plugin auto-update when profile is on a network drive

Reported by, Dec 25 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce the problem:
1. Using a non-updated Flash Player version (e.g., and in chrome://plugins I can see the plugin location is at C:\Program Files\Google\Chrome\Application\46.0.2490.80\PepperFlash .
2. Open a page contains Flash Player contents and wait for a while.
3. In chrome://plugins you can see the Flash Player has been updated to but the location is changed and is different than the original (which is at %appdata%\Chrome\PepperFlash).
4. When you open other pages contains Flash Player content, it says you are not install Flash Player.
5. If I delete %appdata%\Chrome\PepperFlash folder, the Flash Player version falls back to and the Flash Player content can be loaded properly.
6. Wait for another while and situation goes to item 3.

What is the expected behavior?
The Flash Player should be loaded properly.

What went wrong?
I think the update should goes to the same location the Flash Player plugin originally was. I tried to update the chrome to the newest version but the flash player is still at an out-dated version ( and the above problem will still exists. The accounts are using folder redirection and the path is ${roaming_app_data}\Chrome\

Did this work before? Yes It should have no problem before chrome version 42 or so...

Chrome version: 46.0.2490.80 m  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 19.0
Showing comments 85 - 184 of 184 Older

Comment 85 by, Jan 15 2016

First start storing the information like 'essentially all Windows applications'. Store all cache and other data consuming files in local application data, and only the bare essentials should be stored in roaming so the roaming profiles don't become humongous.
Thanks for the reply, jschuh.

However, as #c84 and #c85 already pointed out, the reason why we (and presumably a lot of system administrators) do not use roaming profiles for Chrome is that Chrome user profiles tend to become extremely large (over 100 MB). We don't use them because all user information - be it favorites, plugins or the cache - are stored in the 'Roaming' directory in the user profile. Storing user settings and favorites in roaming profiles is fine, that's what roaming profiles are invented for. Disposable or non-essential data - like the cache - should not be stored as roaming data, but they should go into the 'local' directory of a user profile.

Until this system is changed we will continue to store profiles on a network share. Our VDI setup is extremely controlled, all network connections remain within the same datacenter, so latency or unreliable network connections are not an issue for us. Unmanageable large user profiles however are a problem.

Many thanks for the time invested in this issue so far, but please continue to evaluate the user profile system for enterprise use cases.
Using the DiskCacheDir policy you can point the cache to a non-roaming location:

Is that sufficient to reduce the size of the roaming component? If not, then please file a bug requesting a more size efficient split between local and roaming profile data on Windows. That's a reasonable request, and far preferable to weakening the sandbox and supporting an operating mode that's likely to introduce other bugs.

Comment 88 by, Jan 15 2016

We have:

Disk cache directory: ${local_app_data}\Google\Chrome
User data directory: ${roaming_app_data}\Google\Chrome\UserData

The disk cache directory for my current user is: 100 MB (756 files)
The user data directory for my current user is: 185 MB (967 files)

For reference, my entire roaming Profile.V5 directory is 13.8 MB (77 files).

The user data directory currently includes a bunch of stuff that should probably be part of disk cache, like the safe browsing list, downloaded flash plugin update, shader cache, "ChromeDWriteFontCache", Application Cache, etc.  If all of these caches were moved to the "disk cache" directory then we'd probably solve all of these problems.  Since the downloaded flash plugin would be in the localappdata we'd be able to load it off of C:\ and the roaming profile would be small enough we could investigate redirecting it properly.

Note that in many enterprise environments (including ours) the localappdata is purged on user logout.

Comment 89 by, Jan 15 2016

Concur with your last paragraph and sentence kloos...
In comments #9,14,55&60 we are asking as you are for the user data directory to only include user data like bookmarks and history and all the other junk to be left in the c: drive disk cache directory as it should be. 
I think that jschuh understands this now and that we need to create a new bug request for this to happen. Whoever has the time and gets there first, please let us know in this thread. Thanks. 
Has been ANOTHER (!!!) out of band flash update?  Worked for a brief period but seems to have gone again with a flash version of

Comment 91 by, Jan 20 2016

It looks like it. This probably explains why we have had reports today of flash working intermittently - thanks for highlighting this because there has not been an adobe bulletin about it. 
Fresh installer please with new flash integrated!

Comment 93 Deleted

Comment 95 by, Jan 22 2016

This bug is NOT blocked by issue 413889. It has nothing to do with it.

Comment 96 by, Jan 25 2016

As per jschuh instructions ( and our discussion, I have filed a new request to improve local (disk cache directory) and roaming (user data directory) profile data segregation on Windows. 

My request is here:

Thank you.

Comment 97 by, Jan 29 2016

Same issue here. 

It would be really efficient to have only a single folder for PepperFlash.dll even on a home PC makes no sense to have in each user profile a different DLL. 

Stuff like this clogs the internet. :-)
A 16 Mb files gets downloaded million-more times. A waste of internet bandwidth.

Comment 98 by, Mar 14 2016

Hate to bring this up, but it's happening again :/
Just confirming we have this problem too now. 
I guess this is probably just crazy talk but is there any way to get Chrome to use the PPAPI Flash Player that Adobe makes available? And I'll look after making sure it's updated. I promise!

We put a workaround in place that updates the pepperflash in the Program Files directory after every login and deletes the copy in the user profile directory.  This at least allows flash to work in Chrome in a non-persistent VDI session.

Like everyone else, we redirect the user's appdata folder to a network share.  This keeps the roaming profile extremely small which allows for a much better user experience.  Having a 100MB+ roaming profile causes slow logins.

This problem is causing us major issues and we are about to remove Chrome from our environment until this issue is resolved.  Google - This issue needs some immediate attention.

Comment 103 by, Mar 29 2016

Please update to Chrome 49.0.2623.110 - this comes bundled with Flash on the system drive so it should load correctly.
@wfh - While we are in the process of doing that, that doesn't resolve the ultimate issue that plugin is not running when from a network share. 

Comment 105 by, Mar 29 2016

It is being addressed in this report:

Whilst I don't have any content to test with, I should point out that this issue would also effect the Widevine Content Decryption Module plugin, which is why a more general approach to the issue is being taken in the above report.
@wfh, @alan - Yet again, our users are unable to load flash based pages appropriately as there is a new version of the plugin that has been released and automatically downloaded.  

Can there be an immediate push to stop the flash plugin from auto updating via some mechanism (GPO, Config, Interim Manual process), while the broader fix is figured out?
Until Google has a workable solution, we are using the following workaround:

We use the attached Powershell script as a user logon script to remove permissions to the PepperFlash folder.

In addition, we use a Group Policy File Preference to copy the latest version of Pepperflash to "C:\Program Files (x86)\Google\Chrome\Application\{currentversion}\PepperFlash\pepflashplayer.dll" from a network share to make sure that we can keep it up to date.

884 bytes Download
Please note that I am not a Chrome developer - I am with you in the enterprise environment battle. 
I do the same as the above, the only difference being that I use Group Policy File Preferences to delete the pepperflash.dll. This was easier for me than changing permissions.
More details on my own method are in my earlier comment:

Comment 109 by, Apr 8 2016

Component Flash loads fine if the user's appdata\local\google is mounted on a user profile disk (UPD) under RDS. This can be used instead of overriding the user-data-dir for Chrome.

Of course this doesn't help for workstations, just for RDS.

Comment 110 by, Apr 8 2016

 Issue 512035  has been merged into this issue.

Comment 111 by, Apr 8 2016

I have a plan of action here, which is to prefer a "system" install of Flash i.e. the PPAPI installer you can get off the Adobe website here -> if the component update is located on a network drive.

So, the solution here will be for enterprise users to install Adobe's updater on workstations (you can deploy this via GPO) and make sure that keeps Flash up to date. As long as the version of Flash on the system drive is the latest version then everything will work. The only time this might not be true is if Chrome has pushed a new version due to a critical security vulnerability, but Adobe has not yet pushed the version - in this case you probably don't want your users to run a vulnerable version of Flash, so this is failing safe.

The CL is and we'll see if it makes it into Chrome.
When I installed pepper flash from the Adobe website Chrome didn't seem to
use it. It carried on using it's own version.
@bdgreg It won't do at the moment as wfh is working on it.

I admire your proposed solution and testing plan. Thank you for your time on this issue. :)
The reason why we rolled out Chrome in our environment was:
1. Consistent compatibility with websites (we had a mix of Internet Explorer versions and even then the latest IE wouldn't always display websites "correctly").
2. Chrome Auto-updates to the latest version which eliminates any inconsistencies and security issues. This includes the fact that Flash would always be the latest version.
3. It is more secure.

For me and others that have implemented workarounds, the situation right now is that so long as a new version of Chrome is released with the latest Flash bundled with it, all is good. Prior to the new version of Chrome getting onto the workstations, I "patch" Flash manually, as already described, to provide a stopgap. This is working well, *so long as Chrome continues to bundle the latest Flash with each new release of Chrome*.

Are you proposing this as a temporary stopgap until  Issue 581062  ( comes to fruition? 
Because what  Issue 581062  proposes is a permanent fix for the size of the roaming profile and will resolve the plugins not being able to load from network drives. As I mentioned earlier, the Widevine Content Decryption Module plugin is also loading from a network drive.

I have now ditched Adobe Reader and have PDFs opening in Chrome, as this reduces the attack surface. For the same reason, one can also ditch the system Flash. It is all in Chrome and it is automatically kept up-to-date by Chrome. From this point of view, Chrome really is good for enterprise and saves a huge amount of expense (and in Windows 10, Edge is doing the same thing). 
When you read about the latest vulnerability effecting Flash yesterday ( I'd rather not have the system flash installed at all, in order to protect our data and not have something else to maintain (even though it will auto-update at some point).

So when I look at it that way, I personally would prefer to just keep doing what I've been doing so far (as explained in my second paragraph) *provided* that  Issue 581062  isn't years away in coming to fruition.

Forgive me for speaking frankly here, but I believe it is important to be upfront. 
What do you think wfh?
Thank you.

Comment 114 by, Apr 9 2016

Re: #113 thanks for your comment. Glad you have made the move to Chrome.

By the way, Flash is not entirely the same as PDF - the Chrome PDF viewer is supplied by Chrome and updated at the same schedule as Chrome, vs. the Adobe Reader which is a completely different application, completely different codebase.

However, with Flash, you should be aware that the same binaries (pretty much identical) are used between the PPAPI system flash updater from Adobe's website, and the ones we ship with Chrome either Bundled, or as a component update. All versions run in the same sandbox, have the same level of protections and mitigations applied, and given an identical version number, behave identically. The only difference is that they arrive via different means:

The system version of Flash will update at the Adobe patch schedule via their updater that you install (or you can manually update via their website), the "bundled" version of Flash with Chrome arrives each time we do a full Chrome update (e.g. update from 49.0.2623.110 to 49.0.2623.112), the "component update" arrives when Google does a critical security push e.g. for a vulnerable version of Chrome.

Adobe is pretty good at keeping their version of Flash available via their updater and their website up to date, so in the rare case that Google push a component update before Adobe, you normally shouldn't have to wait long before you can download/deploy-via-GPO the system version of Flash across your fleet. In the meantime, since Chrome will have updated the component based Flash already, your users are protected from running an old version of Flash.
@wfh: Re: #114 Thank you for your detailed explanation - that is helpful to know.
Sorry, I didn't explain too well. I should have said that I have started uninstalling Adobe Reader across the fleet and redirecting the opening of PDFs to Chrome, as you have a good alternative PDF viewer. By uninstalling Adobe Reader, it is one less program that is vulnerable and as you say, Chrome PDF Viewer is being kept up to date by Chrome. Win win. (unfortunately this is where I then discovered a 2 year old bug that kind of scuppers this plan a little:
I digress. So what I was trying to say was that by not having a system version of Flash installed at all, exploits can't come that way through Internet Explorer. ie. I am forcing users to use Chrome for flash based media, whereby the version of Flash is auto-updated and it is a safe version to use.
In essence, Chrome can replace the need to have Adobe Reader and Adobe Flash installed on workstations, which means it is less to be installed, updated and exploited.

If you were able to get a GPO option implemented, as you have commented in  Issue 581062 , I feel that it would suit everyone better.

Comment 116 by, Apr 9 2016

re: #115 you don't need to install the ActiveX (Internet Explorer) or the NPAPI (Firefox) version of System Adobe Flash, you just need to install the PPAPI version, you can uninstall the rest. Then Chrome can just use the PPAPI version and Flash won't load in other browsers.
Re #116: Ah yes of course, my mistake. Sorry wfh, I completely forgot that and thank you for pointing that out.
I look forward to seeing what option gets decided upon, but my preference is a GPO option, as it is a set and forget method rather than having to roll out and maintain another component on workstations (It would just need to be mentioned in the description of the "user data directory" GPO to additionally set the "Location of additional Chrome components" GPO so that new adopters do not fall foul).
Thank you so much.

Comment 118 Deleted

Comment 119 by, Apr 14 2016

Can anyone confirm that this is fixed in Version 50.0.2661.75? After I updated to this version today (which includes Pepperflash -- flash works even though I have not deleted the or renamed the pepflashplayer.dll in my profile on the network drive.

I hope this is the case!  

Comment 120 by, Apr 14 2016

The root cause of the problem is not fixed. 
The reason why it is working in version 50.0.2661.75 is because they have packaged the latest version (as of today!) of Pepperflash ( with this new release of Chrome. When Google do a release like this, the component updater has nothing to update, so Chrome happily uses the version in C:\program files. However, when there is an "out of band" flash update (ie. a flash version update which is not released with a new version of Chrome), this will cause the component updater to download an update and then the problem will re-surface.
Project Member

Comment 122 by, Apr 22 2016

The following revision refers to this bug:

commit 73d6faae235add2deebf2a634f0cd0939751a946
Author: wfh <>
Date: Fri Apr 22 03:45:14 2016

Prefer System Flash over non-local component updated Flash.

This avoids attempting to load a Flash DLL off a network drive if doing
so would not result in loading an old version of Flash.

When determining which Flash to load the following algorithm is evaluated:

First, a candidate list of Flash versions is compiled sourced from:

 - System Flash (Adobe updated) - (could be the debug version)
 - Bundled Flash (ships with Chrome)
 - Component updated Flash (updated on user data dir by component updater)*

* Note this really only applies on Linux when the component updated Flash
is already available at Chrome startup.

The highest single version will always win. If so, just use that version.

If there are two or more available version of Flash with the same version
then preference is given in the following order

 - Flash content Debugger
 - Bundled Flash
 - Local-drive Component updated Flash
 - System Flash
 - Network-mounted component updated Flash

Because of the way that the pepperflash component updater injects its
version of Flash later on in Chrome load, the network drive determination
is done in two places, firstly inside ChromeContentClient when building
a candidate list, since Linux could have a component updated flash
ready for use at this point, and secondly when the pepperflash component
comes to inject the new version it will evalulate the order based on
the rule above on whether to inject itself.

TEST=unit_tests --gtest_filter=ChromeContentClientTest.*
BUG= 572131 

Review URL:

Cr-Commit-Position: refs/heads/master@{#389006}


Thanks, wfh, for getting this solution going. I do, however, see a problem with just going for the "highest single version". Right now the current Adobe PPAPI Flash Player is but the version embedded with Chrome is which means, as I understand it, Chrome would currently prefer the component updated version on the network and we're back to square one. Is it not possible to let the user (or admins) choose which plugin to use?

Comment 124 by, Apr 22 2016

Please stop copy pepperflash to the network drive. Broken pepperflash does NOT work on a network drive! Additionally it fills up user drives and therefore server drives with useless data. The admin decides when the update will be installed, not You or Google!

Comment 125 by, Apr 22 2016

Labels: Merge-Request-51 M-51
It's rare that there is a delay between Chrome pushing a new version and Adobe - normally the binaries would be pushed at the same time, and stay in sync. Unfortunately, as you say, right now is one of those times.

In those rare situations, Chrome has considered getting the update out there very important, usually due to a critical security vulnerability.

You should note that latest stable - 50.0.2661.87 contains bundled Flash so you should upgrade your clients to this version.

Comment 126 by, Apr 22 2016

To be clear to your specific concern: "Right now the current Adobe PPAPI Flash Player is but the version embedded with Chrome is which means, as I understand it, Chrome would currently prefer the component updated version on the network and we're back to square one."

Actually, in this case, Chrome would prefer the bundled version which loads from the system drive (same location as Chrome binary) so this would work fine.

The component update would only be pulled if there was a later version of the component available, but since is the latest version that wouldn't happen.

To be clear, the only time that Flash will *not* successfully load after this CL is:

 - Bundled version is version X.
 - Component update version is version Y where Y is higher than X - there is a critical security issues in X, so we are pushing Y.
 - Adobe Flash System version is lower than Y - i.e. Adobe have not yet released their update to whatever the critical issue is that's fixed in Y.

This is failing safe, you would not want your users able to run version X since it likely has critical security vulnerabilities, and you should wait for Adobe to release Y for them to be able to use Flash again.
@wfh, thanks for looking into this bug, I think your general approach in #126 makes sense except that here you are dealing with an enterprise audience that might be relying on Flash, as crappy as it is, for a business critical purpose. In this case, the sysadmin would want to be able to make the call themselves and not have Chrome fail safe for them. If Google is telling us Chrome is enterprise-ready, it needs to give us that fine grained control.
OK, wfh, it seems Chrome is having problems updating itself for some reason. I'm getting a "Update check failed to start (error code 3: 0x800704EC -- system level)." error so my version of Chrome is stuck at 49.0.2623.112 m but Pepperflash is version I checked out network and 3 computers have the most recent version and the rest have the same version I have. When was 50.0.2661.87 released? I've downloaded the latest MSI but I'd really prefer to let Chrome update itself if at all possible.

My concern though is that version numbers are sometimes inconsistent. In my current situation, even if I had the latest Adobe PPAPI dll, it would be superseded by the component version until Chrome is updated. 

Comment 129 by, Apr 22 2016

Re: 127 - Your concerns are understood. This whole issue is still under consideration. It's possible that in the future if an Enterprise is deploying Chrome via MSI then we will also default to always using the MSI version of Flash distributed by Adobe [1], and devolve the whole Flash update process to the sysadmin. Your views on whether that would be an acceptable solution would be appreciated.

Re: 128 - please raise a separate issue if you are having difficulties updating Chrome.

[1] -

Comment 130 Deleted

Comment 131 by, Apr 22 2016

Now that Adobe provides an MSI for PPAPI Flash Player, we are also contemplating the implications of completely removing Flash Player from Chrome's MSI... and potentially adding w/ the ability for Enterprise policy to disable component based Flash Player updates.  This would, in effect, give enterprises complete control over what version of Flash Player ships to their users.
@wfh, @laforge both those possibilities sound great. Hopefully you can get this bumped up higher on the backlog!

Comment 134 by, Apr 22 2016

Just because I deploy Chrome via MSI doesn't mean that I want to be unwittingly agreeing to managing my own Flash updates as well (which I would be doing because I can't use the component updater, due to the "user data directory" - see later remarks). Chrome is deployed via MSI because that best suits our method of deployment, nothing more.

I've said before that the fundamental advantage of Chrome is that it keeps Flash (one of the biggest vulnerabilities) up-to-date and current. That's why we switched to Chrome in our environment.

I'll ask the question to the Enterprise admins; what is the reason for staying on an out of date and vulnerable version of Flash?
The risk for doing so is great - malware delivered via adverts for example. The latest vulnerability that prompted version was a 0 day vulnerability with payloads of ransomware:
This is why Chrome pushed the Flash update via the component updater.

Here's the catch though Chrome devs; we want Flash to always work, whatever happens. I believe that this is what the author in comment 127 was getting at. However, here's the problem; we don't want to be running a vulnerable version of flash! We are going back around again!

Look, it has been mentioned again in comment 124 and plenty others before, the fundamental issue of Chrome for the enterprise is the "user data directory". If this was fixed as per  Issue 581062 , Flash would always be current, always be secure and always work, whatever happens. The "user data directory" would not be bloated, the other fundamental gripe, and there wouldn't be the risk of performance and corruption issues.
It was highlighted long ago that this was the root cause of the problem. As enterprise users, we justified why we had our environments setup in this way. We keep talking about Flash, but it isn't the only plugin effected here. 
Forgive me for being outspoken, but I believe strongly that you need to put your efforts into fixing the bigger problem rather than spending time on trying to workaround the issue - this Flash issue is just one aspect of a larger problem.

Comment 135 by, Apr 23 2016

Labels: -Merge-Request-51 Merge-Approved-51 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M51 (branch: 2704)

Comment 136 Deleted

Comment 137 Deleted

Comment 138 by, Apr 23 2016

Today it is as follows:

1. I install Chrome as MSI (you know this broken installer that is not full fledged MSI)
2. Than a new Flash version is released and Google updates pepperflash.
3. This DLL is downloaded to user data dir on a network drive. 
4. PepperFlash on the network drive does NOT work. This means from this moment forward Flash content is no longer loading!
5. I have disabled automatic updates to prevent Google Chrome from breaking this way.
6. If I download the latest MSI file from google when Google releases new pwpperflash versions it does NOT contain the latest DLL!!!
7. Also 1.5 weeks after the new pepperflash release the MSI is outdated!

I fully agree that security issues like this should be closed ASAP and I'm willingly to deploy the latest MSI once it comes out, but the packaging process is weak. The MSI is packaged 1 week after the security update is released.

Pepper Flash has ~18MB * 10000 users 18GB hard disk on a user volume where is should NEVER copied to. I have disk space issues than! And again - pepperflash does not work if copied there!

Last - again soly I controll when software will be installed, not anyone else. That is why automatic updates are disabled. Leave it to me to close the security issues and when I'm closing them, please. You have no idea what  applications you are breaking every 2 week since several months! And I cannot change the situation as I have no controll over this idiotic no-brainer pepperflash upgrade.

Comment 139 by, Apr 23 2016

Yes, due to the way that the "user data directory" is at present, we have had to increase user's disk quotas. Fortunately, we have the capacity to do so, but I can imagine that others wouldn't.

FYI, automatic updates of Chrome have no impact on the component updater, which runs every few hours and checks and downloads updates to the components, of which Flash is one.
By disabling automatic updates, you are doing yourself a disservice in 2 ways: 1. You won't get the latest security updates. 2. When Google do package the latest pepperflash with a new Chrome release (which as you say, tends to be a few weeks after the update of Flash), it will in effect self-heal itself without you needing to do anything.

You are correct, if Google made a new Chrome release, with the latest bundled flash, much quicker, it would help a lot.

In the interim, please look at my workaround in comment 71 and another very similar workaround in comment 107.
By leaving automatic updates on, I only have to push out a new pepperflash version as a stop gap until a new Chrome release with the latest flash gets released. Otherwise, if Google didn't package the latest version of flash with a new Chrome release at all, it would be an absolute nightmare.

A relevant food for thought snippet on page 1 of this IT Manager's magazine, regarding patching (mentioning Chrome patching):
Another Enterprise Admin here working with non-persistent VDI desktops and the current commit to M51 (Comment 135), while it helps the situation, doesn't resolve the problem where if the Chrome data directory is on a network share and flash updates.  This is a problem and doesn't resolve the issue stated in the title of this bug.  Admins need the ability to disable component update or the components need to update to a non-network drive location that is outside of the existing structure to fully resolve this issue.  Not having chrome bundled in the MSI is also not a good direction.  Comment 134 is spot on.  We deploy chrome via MSI to traditional workstations and this works great, but in the VDI or redirected chrome data directory world, this is very problematic.  Personally, I think that this change should be backed off until a better solution can be developed.  But that is just my 2 cents on this right now.

Thank you to all the devs for all of the work they put into chrome.  This is truly appreciated.

Comment 141 by, Apr 25 2016

I will never ever *enable* automatic updates.

I tell all our users "Chrome is not fully supported as Google has no understanding of Enterprise needs and breaks their software every few weeks."
Project Member

Comment 142 by, Apr 25 2016

Labels: -merge-approved-51 merge-merged-2704
The following revision refers to this bug:

commit ff48a2fef7b3490f9c0c53e4e58c78184e743835
Author: Will Harris <>
Date: Mon Apr 25 23:50:03 2016

Merge M51: Prefer System Flash over non-local component updated Flash.

This avoids attempting to load a Flash DLL off a network drive if doing
so would not result in loading an old version of Flash.

When determining which Flash to load the following algorithm is evaluated:

First, a candidate list of Flash versions is compiled sourced from:

 - System Flash (Adobe updated) - (could be the debug version)
 - Bundled Flash (ships with Chrome)
 - Component updated Flash (updated on user data dir by component updater)*

* Note this really only applies on Linux when the component updated Flash
is already available at Chrome startup.

The highest single version will always win. If so, just use that version.

If there are two or more available version of Flash with the same version
then preference is given in the following order

 - Flash content Debugger
 - Bundled Flash
 - Local-drive Component updated Flash
 - System Flash
 - Network-mounted component updated Flash

Because of the way that the pepperflash component updater injects its
version of Flash later on in Chrome load, the network drive determination
is done in two places, firstly inside ChromeContentClient when building
a candidate list, since Linux could have a component updated flash
ready for use at this point, and secondly when the pepperflash component
comes to inject the new version it will evalulate the order based on
the rule above on whether to inject itself.

TEST=unit_tests --gtest_filter=ChromeContentClientTest.*
BUG= 572131 

Review URL:

Cr-Commit-Position: refs/heads/master@{#389006}
(cherry picked from commit 73d6faae235add2deebf2a634f0cd0939751a946)

Review URL: .

Cr-Commit-Position: refs/branch-heads/2704@{#235}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}


Project Member

Comment 143 by, Apr 26 2016

The following revision refers to this bug:

commit ff34c287f8e4dc409a55222875eb2a59af8a4a11
Author: Will Harris <>
Date: Tue Apr 26 01:55:48 2016

Merge M51: Add base::IsOnNetworkDrive.

BUG= 572131 ,606622

Review URL:

Cr-Commit-Position: refs/heads/master@{#387981}
(cherry picked from commit 2396e07db179be4f5a22ab2acc1503d0cdb1e499)

Review URL: .

Cr-Commit-Position: refs/branch-heads/2704@{#240}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}


Comment 144 by, Apr 27 2016

I'm wondering how this changes are stopping Chrome from downloading latest DLLs in general if Automatic updates are disabled. If an enterprise admin disables automatic updates the software must never download an update. Security issue or not does not matter. I intentionally disabled updates.
Marc brings up a good point related to this issue with PepperFlash...I know this is off topic so if someone points me to the right issue page I will happily discuss it there.

We set the GPO to disable updates and the last few versions do not respect this setting. If I go to Help --> About Google Chrome it will check for updates and begin updating itself.
@145 - for really disabeling the google updates we used a computer config gpo, i`ve attached our settings - hope this helps, we since then had no more google update problems

22.6 KB View Download

Comment 147 by, Sep 16 2016

Issue is still active with 53.0.2785.116 m (64-bit) as of today.
The ability to disable binary component updates is coming in Chrome 54,
Current workaround for VDI: install the PPAPI Flash plugin separately. Set --disable-bundled-ppapi-flash as startup parameter with Chrome. Optionally deny write access to the Pepperflash folder of the Chrome profile (on the network drive). 

Comment 150 by, Sep 27 2016

The MSI is not updated yet. Nobody can use Flash.
Had the same problem. My workaround was to make a file screen in FSRM to block the creation of pepflashplayer.dll 

Had to search for & delete all current PepperFlash folders, but seems to be working and haven't seen any adverse effects so far. 
I apologize if I am outlining/asking for repeat information, but just so I feel I understand this issue.

1. Pepperflash/Flash updates being pushed to a network drive is the root of the issue here, so for those of us who do that, we are seeing the cannot load plugin issue.

2. The current msi for Chrome does not include the current flash version, so if we are in a non-persistent vdi environment we cannot just update the image with the new Chrome msi and move on yet.

3. Installing the newest ppapi flash manually from their site will also not work due to #1 above.  Unless you use the startup parm --disable-bundled-ppapi-flash which comment 149 reported as successful for VDIs.

4. We are waiting on what exactly to happen to remedy this moving forward?  If I am understanding this correctly the Chrome candidate list in comment 142 is the problem? In the meantime we are waiting for the updated chrome msi for 54.x.x to include the newest flash as a bandaid?

Again, sorry for the repeats/silly questions,  but we have been dealing with this for a few months and I am trying to get my head around on how to proceed.
 Issue 651376  has been merged into this issue.
1: correct. 2: correct.

3: As of yesterday, if you have an up-to-date separately-installed system Flash (e.g. from, that should be sufficient and Flash is expected to work correctly - no flag is needed. However, if your system installation of Flash is out of date, passing --disable-bundled-ppapi-flash will allow the out of date system Flash to load. (Unless it is very out of date.) Alternatively, going forward you can use the group policies mentioned in #148 instead of the flag.

4: Not sure.
Can anyone confirm comment 154?

I am on Chrome 54.0.2840.59 m, I just followed the link in comment 154 Item 3, installed PPAPI, restarted.  I tried 3 sites with Flash, all "couldn't load plugin".  This was even on a non VDI, but the pepperflash would be stored on a network drive.

Any suggestions one way or another?

Thanks so much.
I don't agree with #154, Chrome doesn't use external flash. Not sure about
the -disable-bundled-ppapi-flash option for VDI. I run VDI and am tempted
to try it.

Keith Nowosielski

Systems Administrator of Information Technology and Services

Information Services Division

Spartan Shops, Inc.

San Jose State University
Keith, the --disable-bundled-ppapi-flash option is not reserved for VDI. It's helpful to disabled the bundled Pepperflash player which doesn't run from a network drive anyway. When a system-installed PPAPI Flash is installed, that one will be used instead - but only if you pass this parameter.

I haven't found a GPO preference for this parameter yet.
Re: #155; what do you see as the location and version for Flash if you navigate to chrome://plugins? Assuming it is still your network-drive'd user-data-dir/PepperFlash/, what happens if you delete the folder and restart Chrome? Does it pick up the system install then (at version Assuming it does, then we probably have a bug.
San, I didn't think it was limited to VDI. I read others saying that so I thought maybe there might be a reason its only used for VDI setups; such as the case that it may only be logical to use it for VDI because its easily deployed from the master image. 

Sadly GPO's Chrome aren't very comprehensive. Even the ones for disabling updates don't seem to work properly. If they did this issue might be technically resolved.  

Comment 160 by, Oct 13 2016

re: 155 can you check the versions of system flash and component flash? I'm surprised you are getting this behavior.

Component flash can be checked by going to chrome://components and looking at the version of "Adobe Flash Player". System flash version can be checked by going to C:\Windows\System32\Macromed\Flash and checking the version in the manifest.json file.

System PPAPI Flash can be downloaded from:

"FP 23 for Opera and Chromium - PPAPI"

Comment 161 by, Oct 14 2016

I haven't tested the GPO, but according to this:

The GPO setting is "Component Updates". Looking at a freshly downloaded version of the GPO templates, the Component Updates setting is present.
Re: #158; This is actually exactly what I see.  Version: is the version, the location is network drive user data, and when I delete it Flash will work for a time.

Re: #160; Both locations point to Version
We have end-users on VDI in which we redirect their Chrome to a network location.

- Running Chrome 52.0.2743.116m based off snapshot

- Chrome set to allow updates using the Administrative Template, applied using VMware UEM.

- Chrome:Plugins shows pepflashplayer.dll in network profile location and flash does NOT work

- Renaming \\profile-path\Chrome\PepperFlash\\ fixes chrome temporarily

- Chrome updates to 54.0.2840.59m since auto update is allowed

- Now Renaming or deleting the folder does nothing. It gets recreated in the network share once you visit a site requiring flash

- All VDI users now have an issue, since Chrome was patched

Is this being addressed in a future relrease in Chome? 

Is the current work around to get the latest Chrome Admin Templates and disable "component updates"?
Installing Flash from changes the Adobe Flash Player Plugin Path to c:\windows\system32\Macromed\Flash\pepflashplayer64_23_0_0_185.dll

Will this remain stable moving forward?

Comment 165 by, Oct 17 2016

Re: 163 Disabling component updates using and then installing system flash player should resolve this issue, as the system flash player will be used in this case.
#164 alone worked for us

VDI with appdata stored in a network location.
Comment 165 did the trick for me, after ensuring the new registry key was being applied via group policy I deleted the folder containing the pepperflash.dll file listed under the pepper flash plugin found in chrome://plugins. Reboot the PC and chrome is no longer using the built in pepper flash, instead it uses the system installed version of flash. If you try and update the pepper flash component it doesn't update or even show a version number. Chrome should always now use the system flash files (hopefully). Been trying to fix this issue on enterprise network for ages.
Anyone have a workaround that works on version 57?

It seems it does not use pepperflash from programfiles at all anymore and I had no luck forcing it to use the systems installed flash. 
#149 still works..
I ended up changing my Group Policy to have the Chrome profile write to the
user's roaming profile instead of their redirected folder.  That fixed the
issues for me.


Comment 172 by, Apr 10 2017

That's how Google intended it to be setup for stability Brian, but unfortunately, it is not an option for mandatory users (which is one of the primary issues as to why this bug started).

I have pepperflash working from program files in version 57.0.2987.110. I haven't tried it yet in version 57.0.2987.133.
It may appear that Chrome does not use Pepperflash from program files anymore, and this is true because it is no longer bundled with Pepperflash, but if you put Pepperflash there, then it will use it. From what I recall, this is by design.
So my GPP is set to place the Pepperflash dlls etc. (I use a wildcard on the source directory, to take all of the contents of the pepperflash folder that would otherwise be in the user's profile) in C:\Program Files\Google\Chrome\Application\57.0.2987.110\PepperFlash\ and it creates the folder.
Re #171
This what we had before putting the profile on a network drive and using the Pepperflash workaround from #149. We had problems with Chrome profiles in roaming profiles. The roaming broke the Chrome profile. Extensions were not fully synced so they got broken, e.g. LastPass. And extensions that have been enabled with policies cannot be uninstalled/reinstalled by users. YMMV.
Re #172
Thank you, the workaround to copy dll in C:\Program Files\Google\Chrome\Application\57.0.2987.133\PepperFlash\ works for us (Chrome 57.0.2987.133). Be carefull to use the proper 32/64bits version.

We're still waiting for native working solution for enterprise deployment (RDS, VDI) where Chrome data dir has to be on network share.

For some reason #149 stopped working here as of Chrome 58. I now removed the --disable-bundled-ppapi-flash parameter because Flash had stopped working completely. After removing the parameter, Flash worked again.
Component updates are still disabled, hence it looks like the plugin as described in #164 is still in use. This cannot be checked in chrome://plugins because that page is not available anymore.
You can now check which version of Flash Player you are using in chrome://version (i.e. in 58 we added the directory path).

As for --disable-bundled-ppapi-flash not working, could you file that as a separate bug?
Re #176
 Issue 715431  has been opened. 
Flash is shown as disabled on chrome://version when the --disable-bundled-ppapi-flash flag is used. Removing the flag shows the system player is used.
I have a question about a case where we are seeing Chrome is favor an out-dated version of system flash. 

For new profiles of Chrome on Windows 7, the Adobe Flash component version number under chrome://components is 

Chrome defaults to using the outdated version of system flash instead of loading in PepperFlash.

Users then get a banner, and are blocked from loading in flash content. If and when a user triggers a component update for Adobe, Chrome loads in the correct version of flash and stops using the outdated version. 

However, it takes a manual user generated trigger to prompt this. This feels like a bug . Thoughts? 

I've attached screenshots below.. this is for Chrome v58+ and Windows 7. 

Screen Shot 2017-06-06 at 1.16.50 PM.png
24.0 KB View Download
Screen Shot 2017-06-06 at 1.17.00 PM.png
63.2 KB View Download
Screen Shot 2017-06-06 at 1.17.10 PM.png
107 KB View Download
I can see it both ways:
A • If system Flash is installed, the user/administrator probably intends to use it over component Flash - so the browser should inform the user that it is out of date and can't be used.
B • On the other hand if we know we're not going to load system flash, we could at least do the just-in-time component Flash update and try to use that to unblock the user.

(Of course, either way it's probably a good idea for the user/admin to either keep system Flash up-to-date or remove it from the system altogether.)

I find A• unconvincing (if A• was a convincing argument, then it's not clear why A• shouldn't still apply even if we do have an up-to-date component Flash, which will usually happen ~6 minutes later), so I agree with you that this feels like a bug.
@waff thanks so much for the quick response. It certainly feels like a bug for us as well! 

To be clear -- we have only been able to reproduce this bug when:
A)New Windows user profile and first time launch of Chrome

B) The PepperFlash component version is still because it’s been less than 6 minutes since Chrome launched for the first time. (For first time launches, the flash plugin component isn't loaded until after 6 minutes, or JIT if flash content is being accessed in the browser before the 6 minutes is up.)

C) An out-date system flash version is already installed in the machine ( in this case)

Expected vs Actual behavior:
Dynamically load and use PepperFlash since is not the latest version, but it loads in the outdated version of system flash, and users are blocked from accessing flash content.

Two known Work-arounds (besides allowing to run an outdated plugin):
1) Uninstall the outdated version of system flash. 
2) Go to chrome://componnets, Check for Updates for the Adobe flash. It goes from, to the latest PepperFlash version.

I think it’s a gap/bug in the algorithm which is not considering this case. Thoughts?
Also, looks like after the initial 6 minute window the problem fixes itself. So we are only in this blocked state for 6-7 minutes, because it then switches to PepperFlash and stops using the out-dated version of system flash. 

I've filed a new bug here
 any feedback is welcome and appreciated. 

Comment 182 by, Aug 28 2017

I just wanted to tie up loose ends in regards to this bug. 

There are now new roaming profile GPO settings available. Please see comment 26, in my spin off bug report, regarding roaming profile usage:

I haven't tested any of the new settings, so I don't know how it impacts on Pepperflash etc. If anyone does get around to implementing the new roaming profile GPO settings, I (and I'm sure others!) would be interested in their feedback.
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!
Status: Archived (was: Assigned)
Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.
Showing comments 85 - 184 of 184 Older

Sign in to add a comment