Closed Bug 1346620 Opened 3 years ago Closed 2 years ago

Netflix has never worked on Firefox: "The WidevineCdm plugin has crashed."

Categories

(Core :: Audio/Video: GMP, defect, critical)

51 Branch
defect
Not set
critical
25

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
platform-rel --- +
firefox-esr52 55+ verified
firefox54 - wontfix
firefox55 + verified

People

(Reporter: solin.nick, Assigned: cpearce)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [platform-rel-Netflix])

Crash Data

Attachments

(5 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

1. Log into Netflix.
2. Open a Netflix video.
3. Video will not load.




Actual results:

It displays this message:

"The WideviewCdm plugin has crashed. Learn more..."

The "Learn more..." link goes here:

https://support.mozilla.org/t5/Troubleshooting/Plugin-crash-reports/ta-p/17952

There are two buttons, "Reload Page" and "Submit Crash Report". Reloading the page does not fix the video. "Submit Crash Report" seems to do nothing.


Expected results:

It should have loaded the Netflix video.
Summary: Netflix has never worked on Firefox: "The WideviewCdm plugin has crashed." → Netflix has never worked on Firefox: "The WidevineCdm plugin has crashed."
I typed the error message wrong. It is in fact:

"The WidevineCdm plugin has crashed. Learn more..."
Please post the crash id (bp-) from about:crashes. Before copying, click on it to make sure it is submitted (as bp-).
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
Severity: normal → critical
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Flags: needinfo?(solin.nick)
I've got four submitted crashes in %APPDATA%\Mozilla\Firefox\Crash Reports\submitted:

Crash ID: bp-bf4be7c0-8d74-429f-bfb0-067db2170312
Crash ID: bp-81f6b8d7-0f70-4356-85cf-bc6a22170312
Crash ID: bp-3d6c0021-d4eb-4481-a868-8da092170312
Crash ID: bp-7c5b8a4e-3f8c-40c5-9056-22fb52170312

I can't even find the dmp file I uploaded in the pending directory so I'll probably just delete it.
Flags: needinfo?(solin.nick)
(In reply to Nicholas Solin from comment #5)
> I've got four submitted crashes in %APPDATA%\Mozilla\Firefox\Crash
> Reports\submitted:
> 
> Crash ID: bp-bf4be7c0-8d74-429f-bfb0-067db2170312
> Crash ID: bp-81f6b8d7-0f70-4356-85cf-bc6a22170312
> Crash ID: bp-3d6c0021-d4eb-4481-a868-8da092170312
> Crash ID: bp-7c5b8a4e-3f8c-40c5-9056-22fb52170312
> 
> I can't even find the dmp file I uploaded in the pending directory so I'll
> probably just delete it.

The submitted dmp files will be automatically deleted.
Crash Signature: [@ mozilla::gmp::GMPChild::ProcessingError ]
Component: Audio/Video: Playback → Audio/Video: GMP
Keywords: crash
I've had the same problem several versions back.
Firefox x64, Windows 10, originally a Firefox x86 profile.

Crash ID: bp-a2e6bb14-f11b-4c9d-a7ee-0aa722170313
(In reply to rishel.nick from comment #7)
> I've had the same problem several versions back.
> Firefox x64, Windows 10, originally a Firefox x86 profile.
> 
> Crash ID: bp-a2e6bb14-f11b-4c9d-a7ee-0aa722170313

Quick clarification, I've had the same problem several versions back into the current version of Firefox (52.0 x64).
gerald/cpearce - while this may subsume other bugs, you should follow the signature link.

Also: this may be a dup (just a guess)
Status: UNCONFIRMED → NEW
Rank: 25
Ever confirmed: true
Flags: needinfo?(gsquelart)
Flags: needinfo?(cpearce)
Priority: -- → P2
rishel.nick, Nicholas Solin: Can you test something for us in order to help us fix this problem? Could you try setting the environment variable MOZ_DISABLE_GMP_SANDBOX to "1", restart Firefox, and see if you still get the same problem?

To set environment variables, open the Windows 10 Start menu, search for "Edit the system environment variables", and on the "Advanced" tab of the "System Properties" window that pops up click "Environment variables". Under "User variables for ..." click "New". Enter "Variable name" as MOZ_DISABLE_GMP_SANDBOX, with "Variable value" as "1" (without the quotes).

Often these failures are caused by a security feature called the "sandbox", and setting this environment variable turns off the sandbox. If setting this environment variable doesn't help, I recommend you remove the new environment variable.

Thanks!
From the uploaded crash report I can see that the GMPChild::ProcessingError has aReason = "(msgtype=0x76000C,name=PGMP::Msg_StartPlugin) Processing error: message was deserialized, but the handler returned false (indicating failure)"

In the past these have usually been caused by the sandbox blocking the load.

rishel.nick, Nicholas Solin: are you running any anti-virus or other security software? Are you on an enterprise version of Windows, or a machine managed by someone else?
Bob Owen: Any ideas as to how we can find out more information as to whether/why the sandbox could be blocking the Widevine CDM loading here?
Flags: needinfo?(cpearce) → needinfo?(bobowencode)
We should be able to use logging settings similar to those in bug 1273372 comment 33, to see what the sandbox is blocking.

Nicholas - if you could update to the latest version of Firefox (52) and this time run with the following environment variables set before you start Firefox:

NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
MOZ_WIN_SANDBOX_LOGGING=1

It should create that log file and ones like this: bug1346620sb.txt.child-* in the temp directory.

Please would you attach bug1346620sb.txt to the bug (if it is not empty).
Please also attach any of the child ones that mention the loading of widevinecdm.dll

You should remove those environment variables when you are finished, thanks.
Flags: needinfo?(bobowencode) → needinfo?(solin.nick)
platform-rel: --- → ?
Whiteboard: [platform-rel-Netflix]
(In reply to Chris Pearce (:cpearce) from comment #10)
> rishel.nick, Nicholas Solin: Can you test something for us in order to help
> us fix this problem? Could you try setting the environment variable
> MOZ_DISABLE_GMP_SANDBOX to "1", restart Firefox, and see if you still get
> the same problem?

This "fixed" the issue.

(In reply to Chris Pearce (:cpearce) from comment #11)
> rishel.nick, Nicholas Solin: are you running any anti-virus or other
> security software? Are you on an enterprise version of Windows, or a machine
> managed by someone else?

Only running Windows Defender, on a self-managed Windows 10 Pro desktop. In case it's relevant I use symlinks to store my profile off of the C: drive.

(In reply to Bob Owen (:bobowen) from comment #13)
> Nicholas - if you could update to the latest version of Firefox (52) and
> this time run with the following environment variables set before you start
> Firefox:
> 
> NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> MOZ_WIN_SANDBOX_LOGGING=1
> 
> It should create that log file and ones like this: bug1346620sb.txt.child-*
> in the temp directory.

I removed the MOZ_DISABLE_GMP_SANDBOX and added the above environment variables sans quotes/equal sign and couldn't find bug1346620sb.txt in the %TEMP% directory. When you said the latest version of Firefox, did you mean 52 nightly or stable 52.0.1? Crash report when I tried to produce the log file - https://crash-stats.mozilla.com/report/index/7ad02ccc-a2d6-4bc4-a7c0-9d5582170322
(In reply to rishel.nick from comment #14)
> (In reply to Chris Pearce (:cpearce) from comment #10)

> Only running Windows Defender, on a self-managed Windows 10 Pro desktop. In
> case it's relevant I use symlinks to store my profile off of the C: drive.

It's almost certainly the symlinks that are causing the problem.
We have to add a rule to the sandbox to allow the DLL to load, but those rules don't support symlinks or junction points.
We resolve the special case of people creating a junction point for their Users directory to another location.

I'm guessing that you have done something a little different to that.
 
> (In reply to Bob Owen (:bobowen) from comment #13)
> > Nicholas - if you could update to the latest version of Firefox (52) and
> > this time run with the following environment variables set before you start
> > Firefox:
> > 
> > NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> > NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> > MOZ_WIN_SANDBOX_LOGGING=1
> > 
> > It should create that log file and ones like this: bug1346620sb.txt.child-*
> > in the temp directory.
> 
> I removed the MOZ_DISABLE_GMP_SANDBOX and added the above environment
> variables sans quotes/equal sign and couldn't find bug1346620sb.txt in the
> %TEMP% directory. When you said the latest version of Firefox, did you mean
> 52 nightly or stable 52.0.1? 

I meant the latest release/stable version. The latest version of Nightly is 55.

I tend to use those settings from a different shell, I'd forgotten it's slightly different from the command prompt, where you don't specify the quotes. From a windows command line this works for me (assuming c: as the system drive and 32-bit firefox):

  set NSPR_LOG_MODULES=SandboxBroker:5,SandboxTarget:5,sync
  set NSPR_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_WIN_SANDBOX_LOGGING=1
  "c:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-remote -P

The "-no-remote -P" opens the profile manager so you can create a separate one for testing and also allows you to run more than one instance.

If it is your windows profile that contains symlinks it's possible that the logging from the child won't work, but the log from the parent process (bug1346620sb.txt) should contain an error for attempting to add an invalid rule for the sandbox.
I see 15 occurrences of this crash signature in Linux Nightly 20170331102157, making it the #4 topcrash.
(In reply to Nicholas Nethercote [:njn] from comment #16)
> I see 15 occurrences of this crash signature in Linux Nightly
> 20170331102157, making it the #4 topcrash.

Oh, but they were all from a single installation.
platform-rel: ? → +
The symlink is ~\AppData\Roaming\Mozilla\Firefox created via "mklink /d ..." (so a directory symlink and not a directory junctions though I'm uncertain the importance of the distinction).

When creating the new profile, warning at top says "Firefox is installing components needed to play the audio or video of this page. Please try again later.", after refreshing, "The WidevineCdm plugin has crashed." https://crash-stats.mozilla.com/report/index/3667d3de-a09e-4577-8692-55c9a1170423

There were 14 bug1346620sb.txt.child-# files also generated, there doesn't seem to be batch file uploads but I can attach those if useful too.
Just confirmed that the issue does not seem to appear on Linux with an equivalent symlink setup.

Another peculiarity of my setup is that Linux and Windows share the same profile directory for Firefox. I cycled the "Enable DRM Content" as per the instructions here - https://help.netflix.com/en/node/40835 - with no luck.
Bob/Chris - what needs to happen to fix this issue?
Flags: needinfo?(cpearce)
Flags: needinfo?(bobowencode)
(In reply to rishel.nick from comment #18)
> Created attachment 8860762 [details]
> Requested error logging file for sandbox + symlink(?) issues.

Thanks for this, sorry that I missed your comments.

It confirms that the rule added by GMP code is being rejected by the sandbox.
It will be because of the symlink in that path.
No need to add any other logs.

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #21)
> Bob/Chris - what needs to happen to fix this issue?

Looks like we need a new version of WinUtils::ResolveMovedUsersFolder to resolve the path completely, symlinks and all junction points. The junction points are more of a pain I think, as you have to test and resolve each directory. As far as I'm aware there isn't a windows API that will do this for you, but maybe I was constrained by still supporting XP/Vista before. For the symlinks I think you can use GetFinalPathNameByHandle to resolve fully.
I guess the best plan will be to resolve symlinks first and then junction points, but I haven't tried anything, so there could be problems with that approach.

I'm going to probably need to do something similar for the content process soon, when I land settings to remove read access, but if someone wants to work on this for GMP for uplift that would be great. :-)

[1] https://hg.mozilla.org/mozilla-central/file/d8762cb96742/widget/windows/WinUtils.cpp#l1838
Flags: needinfo?(bobowencode)
Flags: needinfo?(cpearce)
Might this be a duplicate of bug 1359108?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #23)
> Might this be a duplicate of bug 1359108?

This bug is that the sandbox prohibits loading the CDM if it is stored in a path which contains a symlink on Windows. Whereas bug 1359108 is that the sandbox prohibits loading the CDM if it is stored on a network drive. They're similar, but not the same case.
(In reply to Bob Owen (:bobowen) from comment #13)
> Nicholas - if you could update to the latest version of Firefox (52) and
> this time run with the following environment variables set before you start
> Firefox:
> 
> NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> MOZ_WIN_SANDBOX_LOGGING=1
> 
> It should create that log file and ones like this: bug1346620sb.txt.child-*
> in the temp directory.

I tried both MOZ_DISABLE_GMP_SANDBOX=1 and the three environment variables above, but neither was a solution to getting my Netflix to work on Firefox. The set of environment variables did create C:\Windows\Tempbug1346620sb.txt, but the file is completely empty. I do not see any bug1346620sb.txt.child-* files either.

For reference, my link creation command is:

MKLINK /J "C:\Users\Nicholas\AppData\Roaming\Mozilla" "D:\Users\Nicholas\AppData\Roaming\Mozilla

I don't know if this is different from Nicholas N.'s MKLINK syntax, the usage of /D instead of /J, or the fact that I'm symlinking the entire Mozilla folder for Thunderbird and Sunbird (yes, I still use Sunbird).
Flags: needinfo?(solin.nick)
Depends on: 1370772
(In reply to Bob Owen (:bobowen) from comment #22)
> (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #21)
> > Bob/Chris - what needs to happen to fix this issue?
> 
> Looks like we need a new version of WinUtils::ResolveMovedUsersFolder to
> resolve the path completely, symlinks and all junction points. 
[...]
> I'm going to probably need to do something similar for the content process
> soon, when I land settings to remove read access, but if someone wants to
> work on this for GMP for uplift that would be great. :-)

I've uploaded a patch that resolves junctions and symlinks, at least on my Win10 machine. I've not tested loading the CDM from a network drive yet. I was considering all the consequences of storing the GMP in ProgramData, and figured it would be quicker to fix the resolving symblinks/junctions issue first. Given that we'll need this change for the content process anyway, and possibly even for some crazy people who move their ProgramData to be behind a junction, I figured we can do this anyway now to get the bug fixed.
Assignee: nobody → cpearce
Priority: P2 → --
Flags: needinfo?(gsquelart)
I'm going to have to create a function to resolve these things for bug 1369670.

So GMP could potentially use that, although it looks like bug 1370772 is going to load from under ProgramData anyway.
As I've said I think that is a good plan anyway, but we could also use the function once we've got it, just in case.

(In reply to Nicholas Solin from comment #25)
> (In reply to Bob Owen (:bobowen) from comment #13)
...
> I tried both MOZ_DISABLE_GMP_SANDBOX=1 and the three environment variables
> above, but neither was a solution to getting my Netflix to work on Firefox.
> The set of environment variables did create C:\Windows\Tempbug1346620sb.txt,
> but the file is completely empty. I do not see any bug1346620sb.txt.child-*
> files either.

Sorry, I must have missed your reply.

Looks like your issue isn't the sandbox then, we could really do with getting some logging in that case.
I think the env var setting I gave you was slightly off, if you're running them from a Windows command prompt (I usual do it from bash).
Could you try these instead (this should include GMP logging):

  set NSPR_LOG_MODULES=SandboxBroker:5,SandboxTarget:5,GMP:5,sync
  set NSPR_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_WIN_SANDBOX_LOGGING=1

Also if you're testing in Firefox version 54 or later then these should be:

  set MOZ_LOG=SandboxBroker:5,SandboxTarget:5,GMP:5,sync
  set MOZ_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_SANDBOX_LOGGING=1
Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

https://reviewboard.mozilla.org/r/147060/#review151210

::: widget/windows/WinUtils.h:467
(Diff revision 1)
>    */
>    static uint32_t GetMaxTouchPoints();
>  
>    /**
> -   * Detect if path is within the Users folder and Users is actually a junction
> -   * point to another folder.
> +   * Fully resolves a path to its final path name. So if path contains
> +   * junction points or symlinks to another folders, we'll resolve the path

s/another/other/

::: widget/windows/WinUtils.cpp:1923
(Diff revision 1)
> +
> +  if (handle == INVALID_HANDLE_VALUE) {
> +    return false;
> +  }
> +
> +  DWORD pathLen = GetFinalPathNameByHandle(

nit: we should explicitly use GetFinalPathNameByHandleW I think.

::: widget/windows/WinUtils.cpp:1932
(Diff revision 1)
> +  }
> +  aPath = path;
> +
> +  // GetFinalPathNameByHandle sticks a "\\?\" in front of the path,
> +  // but that confuses some APIs so strip it off.
> +  auto i = aPath.find_first_not_of(L"\\\\?\\", 0);

This is a character search.
As it happens because the next character should be a drive letter then it should work (although you could just have L"\\\\?").
Maybe just use compare and erase so we don't create a new string:

if (aPath.compare(0, 4, L"\\\\\\\\?\\\\") == 0) \{
  aPath.erase(0, 4);
\}

Anyway, scratch all that, with the discovery over GetFinalPathNameByHandle (below) we should just convert the second \\ to a ? (so \\??\\ not \\\\?\\) this gives us the NT naming convention which is what the sandbox wants.
This will work for symlinks to network drives as well and we can remove that code that currently checks for this after the call to ResolveMovedUsersFolder.

Not sure if the library loading will work with the NT path though, so we might have to trim it off before passing it down to the child.

In that case, for the network drive case we would have to convert:
\\??\\UNC\\SERVER\\Share\\path
to
\\\\SERVER\\Share\\path

I guess we could get this code to do that and return two paths.

::: widget/windows/WinUtils.cpp:1965
(Diff revision 1)
> +  for (auto token : tokens) {
> +    p += token;
> +    p += L"\\";

I think we'd have to go backwards to get this to work and we'd lose the start of the path, but I noticed that this function wasn't modifying aPath anyway.
So, I tried GetFinalPathNameByHandle and it resolves junction points as well, so this is much easier than I thought.
We can just rename ResolveSymbolicLinks to ResolveJunctionPointsAndSymLinks

It wasn't available on WinXP, which must be why I didn't use it before.
Attachment #8875637 - Flags: review?(bobowencode)
I've updated the patch, but it doesn't work for network shares, even though the paths have the '\??\'. I'm not sure how to make the network shares work. It works fine with junction points and sym links.
Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

https://reviewboard.mozilla.org/r/147060/#review151688

Given that network drives don't seem to be working now, I'll look into that in a follow-up.

::: dom/media/gmp/GMPProcessParent.cpp:57
(Diff revision 2)
>    // symbolic links or junction points. Sometimes the Users folder has been
>    // moved to another drive using a junction point, so allow for this specific
>    // case. See bug 1236680 for details.
> -  if (!widget::WinUtils::ResolveMovedUsersFolder(wGMPPath)) {
> -    NS_WARNING("ResolveMovedUsersFolder failed for GMP path.");
> +  if (!widget::WinUtils::ResolveJunctionPointsAndSymLinks(wGMPPath)) {
> +    GMP_LOG("ResolveJunctionPointsAndSymLinks failed for GMP path=%s",
> +            WideToUTF8(wGMPPath).c_str());

nit: Can we use %S  (uppercase) for the logging and not convert the string?
Attachment #8875637 - Flags: review?(bobowencode) → review+
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/552aa9d9f4f9
Resolve symlinks and junction points in path to GMP dir when loading GMP process. r=bobowen
https://hg.mozilla.org/mozilla-central/rev/552aa9d9f4f9
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Not sure if this is worth considering for an Fx54 dot release ride-along candidate, but it'd probably be worth uplifting to ESR52 at least?
Flags: needinfo?(cpearce)
I feel like this should bake this a bit before we uplift it. Yes, uplifting to 52 ESR seems reasonable, after a bit of baking.
Flags: needinfo?(cpearce)
Nicholas Solin: would you be able to test our to see whether our fix works for you? The fix is in Firefox Nightly builds, which you can download from https://www.mozilla.org/en-US/firefox/channel/desktop/ . You will need to close other running Firefox instances before running the Nightly build. Thanks!
Flags: needinfo?(solin.nick)
Fix works on my end.
As 54 was released, we won't take this in 54 if we have 54 dot release.
Think we're ready to request ESR52 approval on this?
Flags: needinfo?(cpearce)
Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Without this patch, some Windows users who have stored their Firefox profile in a non-standard location, inside a folder behind a symlink or "junction" point, will not be able to start the CDM process. This means that sites trying to play DRM protected video like Netflix won't work for these people. We still get a significant number of these failures on ESR52, so I think this will help.
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): This patch should be low risk; it's baked in Nightly and Beta for a few weeks now.
String or UUID changes made by this patch: None.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Flags: needinfo?(cpearce)
Attachment #8875637 - Flags: approval-mozilla-esr52?
Hi :cpearce,
May I know have you verified this in local ESR52 or can you help create a try build based on ESR52 and we can have QE to help verify this issue?
Flags: needinfo?(cpearce)
(In reply to Chris Pearce (:cpearce) from comment #38)
> Nicholas Solin: would you be able to test our to see whether our fix works
> for you? The fix is in Firefox Nightly builds, which you can download from
> https://www.mozilla.org/en-US/firefox/channel/desktop/ . You will need to
> close other running Firefox instances before running the Nightly build.
> Thanks!

Don't worry, I use "-P encrypted -no-remote" so that I can have my encrypted profile open at the same time as my general browsing profile.

And... it works!!! Thank you very much for your work and thank you everyone for your contributions to this bug report.
Flags: needinfo?(solin.nick)
Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

Given we still have lots of users on ESR52, let's uplift it to ESR52.3.
Attachment #8875637 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
This needs a rebased patch for ESR52.
Flags: needinfo?(cpearce)
Flags: needinfo?(cpearce)
For the record, this was landed on esr25:
https://hg.mozilla.org/releases/mozilla-esr52/rev/688c9284fb12

And then backed out:
https://hg.mozilla.org/releases/mozilla-esr52/rev/8e0ad123ef5e

The build failed on because this patch adds the use of the GetFinalPathNameByHandle() API, and that is only available on Windows Vista and later, and ESR52 is built with Windows XP code gen. So I'll need to rewrite the patch to load GetFinalPathNameByHandle from kernel32.dll manually, and preserve the existing fallback path on XP.
(In reply to Chris Pearce (:cpearce) from comment #47)
> The build failed on because this patch adds the use of the
> GetFinalPathNameByHandle() API, and that is only available on Windows Vista
> and later, and ESR52 is built with Windows XP code gen. So I'll need to
> rewrite the patch to load GetFinalPathNameByHandle from kernel32.dll
> manually, and preserve the existing fallback path on XP.

The (existing) fallback path isn't run on XP anyway, so we don't need to preserve the previous code path for XP anyway.
Here's a try push of the patch rebased on ESR52:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=db6f3c2e8492b6309cb3207fd0ddf71849955e5d&selectedJob=119786938

I have tested this build locally and verified that it fixes the bug in ESR; the CDM works as expected if the Firefox profile is inside a path which contains a Windows junction point, and in the current ESR52 build which doesn't have this fix the CDM crashes.
MozReview-Commit-ID: CLdzAzsAUVP
Attachment #8892263 - Attachment description: Reland 6f93b270d1e3 → ESR52 Rebase - Reland 6f93b270d1e3
Flags: needinfo?(cpearce)
Patch rebased, required minor edits to make the code build with WinXP compatibility.
Flags: needinfo?(ryanvm)
Hi Florin, can we have some QA's help to verify this on ESR52.3 once the build is ready?
Flags: qe-verify+
Flags: needinfo?(florin.mezei)
Moving over to Andrei so they have this in their verification list.
Flags: needinfo?(florin.mezei) → needinfo?(andrei.vaida)
Managed to reproduce the initial issue on 55.0a1 (2017-03-12). I can confirm the bug is verified fixed on 55.0 build3 (20170803103124) and on 52.3.0esr (20170802111520) using Windows10 x64, Ubuntu 16.04 x64 and Mac OS X 10.11.6.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(andrei.vaida)
You need to log in before you can comment on or make changes to this bug.