CDM not loading on Windows 10 networked appdata folders

We’ve received the following from a user who is trying to upgrade a few machines to use the latest version of our app. It’s based on v7.1.9-wvvmp v7.1.1-wvvmp and trying to load v4.10.1582.2 v4.10.1582.1 of the CDM. The user is running Windows 10 1809, and their logs don’t show anywidevine- events.

I believe the app has a problem because when running as a user without appdata re-directed, all the appdata is stored in c:\users\user\appdata eg \local\BBCiPlayerDownloads \roaming\BBCiPlayerDownloads when the user (even an admin user) has their home folder re-directed, they have split appdata so c:\users\user\appdata\local\BBCiPlayerDownloads and \network_path\user\appdata\BBCiPlayerDownloads app (for roaming) It looks to me maybe that the app doesn’t like this split, as the same computer will run BBCiPlayerDownloads app on a user logged in without folder redirection.

This looks as though it’s in the same area as #50 with the CDM being affected by filesystem virtualisation/redirection. Does this sound reasonable? The difference being that widevine-ready doesn’t fire, and versions of Windows pre-dates the version expected to cause problems.

[simongregory]

I’ve had a response from our user who was having trouble with the installs. They’ve got a test build working by finding a path on C:\ and setting it via --widevine-base-dir. C:\ProgramData\Widevine didn’t work for non-admin users, so they had to setup a directory to sandbox the cdm for non-admin users as their machines are locked down.

Apologies for being inaccurate but previously they were using v7.1.1-wvvmp with 4.10.1582.1, and are now using v7.1.9-wvvmp with v4.10.1582.2.

My plan is to simulate the 2 problems with restricted and aliased folders and see what errors I get, I’m hoping off the back of this I’ll have some more concrete info on the errors raised at which point I can advise users there’s a problem and get some idea of volumes via stats. Will let you know how that goes.

[khwaaj]

With the advent of the Component Updater Service based releases we have even less control over the installation than before, which limits out ability to do much to work around issues like this. At the end of the day this is caused by the restrictions imposed by the Chromium sandbox, and thus any attempts to fix the root cause has security implications.

Since this is not an old issue I’ll close it due to inactivity.