Google Chrome - Could not load Shockwave Flash

[cbsc]

We are experiencing issues on our network with Google Chrome and Shockwave Flash.

 

Google Chrome is deployed to all PCs on our network, and we are using the latest ADM files to push out the necessary settings. All PCs are Windows 7 64-bit (RM CC4), and we also push out Adobe Flash Player as an MSI.

 

All has been working well until last week when users have randomly been getting the error message:

 

Could not load Shockwave Flash

 

I have found two potential workarounds, which involve either deleting/renaming the \User Data\PepperFlash\11.9.900.117 folder OR browsing to chrome://plugins and disabling the "PPAPI (out-of-process)" plugin that's pointing to the same location (the top one depicted in the image below).

 

 

However we need a permanent solution to the problem, as the folder appears to be getting recreated. Has anyone else experienced a similar issue? Is it possible to disable a specific plugin through GPO - without completing disabling Adobe Flash Player? We currently have the following ADM settings applied that might be relevant:

 

Set user data directory:

 

${roaming_app_data}\Google\Chrome\User Data

 

Set disk cache directory:

 

${local_app_data}\Google\Chrome\User Data\Default

 

Allow running plug-ins that are outdated:

 

Disabled

 

Always runs plug-ins that require authorisation:

 

Disabled

 

Specify a list of disabled plug-ins:

 

*

 

Specify a list of enabled plug-ins:

 

Enabled...

 

Adobe Flash Player

Adobe Shockwave Player

Java™

Native Client

 

There are many other settings, but I'm not sure if they're relevant. I have tried disabling the last two settings ("specify a list of disabled plug-ins" and "specify a list of enabled plug-ins") but that doesn't appear to help - other than allowing the user to manually disable the specific ploblematic plugin.

 

Your help would be greatly appreciated!

[jpaterson]

We have an almost identical set up with Chrome, with an identical problem.

 

I've been working on this all day. So far, working locally, disabling the Pepperflash dll via chrome:\\plugins seems to survive log off and restarts and is the most consistent workaround. However, there does not appear to be a way to disable individual plug in components via the ADM extensions for Chrome.

 

The closest implementation to a widespread solution I have found thus far will still involve GP, but in a different way.

 

As you have your chrome user data directory set via GP, Chrome will save it's user prefs in a subdirectory of that called "default", in a file named "preferences". This is a human readable file without a file extension and can safely be opened in notepad. Assuming to you have the plugin based flash player from adobe installed on an affected machine, when the pepperflash dll is disabled in chrome://plugins, it saves that state in the preferences file, here is what the entry looks like....

 

    "plugins_list": [ {
        "enabled": false,
        "name": "Shockwave Flash",
        "path": "N:\\AppData\\Roaming\\Chrome\\Profile\\PepperFlash\\11.9.900.117\\pepflashplayer.dll",
        "version": "11.9.900.117"
     }, {

 

Notice how the state is changed 'false'? Again, assuming you have the adobe plugin-based version of flash installed on an affected machine, Chrome will default to this is the pepperflash component is disabled. OK, so with this "preferences" file, it would simply be a cased of putting it in a publicly accessible, read only share (perhaps netlogon) and using GP prefs to REPLACE the file in the same directory for any given user at the next logon.

 

At the moment I am still testing this, but assuming many of the preferences for chrome are enforced by GP, and that any unique data can be stripped from the file without screwing Chrome, I believe that this could be an effective solution until Google (hopefully) realise this is a problem and rectify in the next update.

 

Thoughts anyone?

[jpaterson]

OK,

 

So I've had a look at the preferences file in greater detail. My proposed solution using GPP would really be a short term fix. This is because the preference file is more dynamic that first thought. It contains information relating to blacklists and auto-update information, which would stay static, probably resulting Chrome not auto updating, and maybe leaving some security holes.

 

if only there was some way to merge and overwrite that snippet of code above in to an existing preferences file. Any scripters or devmins got any ideas?

[jpaterson]

On second thoughts, I suppose using GPP to update or replace the file once (using the "Apply Once and do not reapply" setting) , and once only might do the trick. As all that has to be done is set the file with the snippet above. Once that's done, it should stick and the file can be continued to be updated elsewhere by Chrome.

 

More testing needed.

[X-13]

If you delete everything under "N:\AppData\Roaming\Chrome\Profile\PepperFlash\" and set it as read only, the problem fixes.

 

The PPAPI flash reverts to C:\[something] and works again.

 

 

Le EDIT: I've just noticed it made the folder again... Even though the PepperFlash folder was read only, which it isn't anymore.

 

Le [sECOND] EDIT: "C:\Program Files (x86)\Google\Chrome\Application\30.0.1599.69\PepperFlash\pepflashplayer.dll" is the one that works.

Edited October 16, 2013 by X-13

[Spence_101]

Another update for Chrome appears to have been released today, so it should start updating on each machine and begin working again.

[cbsc]

Thank you all for your input.

 

It does indeed appear that Google have 'fixed' the issue with update 30.0.1599.101.

 

What I don't understand is why the Adobe Flash Player plugin is now picking up the DLL file from:

 

C:\Program Files (x86)\Google\Chrome\Application\30.0.1599.101\PepperFlash\

 

...and not:

 

N:\My Settings\Application Data\Google\Chrome\User Data\PepperFlash\

 

How does Google decide whether it's going to use the %PROGRAMFILES(X86)%, %WINDIR% or {roaming_app_data} location to pick up the plugin DLL from?

 

Just to confirm, we now only have one Adobe Flash Player plugin listed as depicted in the screenshot....

 

 

I presume this is a result of Google moving over to PPAPI, and phasing out NPAPI as mentioned in the following article?

 

Google Chrome to block and banish plugins built using popular NPAPI architecture | PCWorld

 

Thanks again!

[localzuk]

I thought Chrome was supposed to install things in the C:\Program Files location if it was installed by MSI, and the AppData route if its installed using the 'per user' installer?

[cbsc]

We pushed out the GoogleChromeStandaloneEnterprise.msi on our Windows 7 64-bit clients, and it installed to C:\Program Files (x86)\Google\Chrome.

 

However we have set user data directory variable to ${roaming_app_data}\Google\Chrome\User Data and disk cache directory variable to ${local_app_data}\Google\Chrome\User Data\Default through group policy.

 

If we hadn't used the group policy settings the data directory and disk cache directories would have resided locally on the PC in %LOCALAPPDATA%.

 

However Google still seems to use both program files and the local app data locations to install plugins. Just wondering how it decides which one it's going to use?

[X-13]

Just wondering how it decides which one it's going to use?

 

From what I can see, it uses the C:\ version if [and only if] the ${roaming_app_data} one doesn't exist.

[Spence_101]

Anyone else getting this error when users try to update chrome by clicking 'About Google Chrome'? Oddly Chrome has updated fine on many computers, it seems to be very random with this error message.

 

 

Edit: Users have full permissions to the Program Files\Google\Chrome folder.

[X-13]

Mine just sits there with a spinny wheel.

 

[i think I'm running a newer version though: 30.0.1599.101 m]

[Spence_101]

Mine just sits there with a spinny wheel.

 

[i think I'm running a newer version though: 30.0.1599.101 m]

 

That's the latest one, flash should work fine on that.

[X-13]

That's the latest one, flash should work fine on that.

 

I guesses as much, I haven't had a problem with it. [Apart from the infinite UserData folder...]