I have managed to reproduce the errors mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1564546#c1

STR:

1. Install Firefox release.
2. Install Skype for Business from the Windows Store.
3. Run Firefox. Go to the address bar, type lync15://foo, and press enter
4. Firefox will display a window asking you to confirm the handler application. Select Skype for Business and click Open link.

Expected:
Skype for Business starts (note that since we don't have accounts, we can't actually log in to do anything with the link)

Actual:
I am then shown an error message box:
Caption: lync.exe - Entry Point Not Found
Message:

The procedure entry point GetCurrentProcessId could not be located in the dynamic link library C:\Program Files\WindowsApps\Microsoft.Office.Desktop.SkypeForBusiness_16051.11727.20244.0_x86__8wekyb3d8bbwe\Office16\RtmMvrSplitter.dll.

The code that starts lync.exe is a ShellExecuteEx call.

While the error message box is up, the lync.exe process continues living. Examining it in Process Explorer, I don't see anything there that differs significantly from a lync.exe process that was started manually.

I'll try doing it with process mitigations set and see how that works.

I have reproduced this via a simple test program!

Indeed, the failure is due to the fact that the process calling ShellExecuteEx has the PreferSystem32Images process mitigation policy set.

I sent an email to the Microsoft discussion list.

According to our Microsoft contacts, process mitigations are inherited by child processes. Those child processes might not like what they are inheriting, as is the case for Skype for Business.

There are two options that I see for resolving this:

• We already have code in the launcher process that does not directly perform a ShellExecute, but rather asks Explorer to do it on our behalf. I modified my test program to do this, and this does work. OTOH I am concerned about security implications, as based on the code we'd need to be careful about not reintroducing bug 394974.
• We back out the setting of mitigation policies on the browser process until we can come up with a bulletproof way of launching these URLs.

(In reply to Aaron Klotz [:aklotz] from comment #5)

• We already have code in the launcher process that does not directly perform a ShellExecute, but rather asks Explorer to do it on our behalf. I modified my test program to do this, and this does work. OTOH I am concerned about security implications, as based on the code we'd need to be careful about not reintroducing bug 394974.

I have figured out a way to make all of this work. Patch forthcoming.

This is just so that both the launcher process and other Gecko code can share
this method.

For the URI handling case, we still want to parse the URI to look for any
malformation. OTOH, IShellDispatch2::ShellExecute does not accept PIDLs as
arguments, we we need an overload that converts the absolute PIDL back to a
path for the purposes of passing on to that interface.

Depends on D38943

Now that we have built up the required primatives in previous patches, this
patch simply replaces the previous code with a new version that uses the new
APIs from ShellHeaderOnlyUtils.h.

Depends on D38944

https://hg.mozilla.org/mozilla-central/rev/e8bf96e8321a
https://hg.mozilla.org/mozilla-central/rev/cae98337ddda
https://hg.mozilla.org/mozilla-central/rev/e7d500f650cc

Is this fixed with new release? As even after upgrading to Firefox 68.0.1(20190717172542), we are getting the same error while opening Skype meeting URL. Tested on 2 of the affected systems.

Are there any additional steps required to perform?

This is fixed in the Nightly channel. We need to proceed through some QA testing to confirm that the issue is fixed (and, more importantly, has not caused any new issues) before we can uplift this to beta, release, and ESR.

[Tracking Requested - why for this release]: Windows users cannot properly start external programs that are registered on their systems as handlers for custom URI schemes.

Please request Beta approval on this as soon as you get a chance. I'm assuming that you'd like this on the radar for possible dot release inclusion for 68, so the sooner we get it on Beta the better.

Comment on attachment 9079880 [details]
Bug 1567614: Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies!

Beta/Release Uplift Approval Request

• User impact if declined: Windows users starting applications with custom URIs registered with their system will not be able to correctly start the registered application.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See bug description
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch re-uses well-tested code that is already out on release. Furthermore, since the feature in question is completely broken, even if this change still does not work 100% correctly, the situation can't be any worse than it already is!
• String changes made/needed: None

Comment on attachment 9079880 [details]
Bug 1567614: Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies!

Fixes a regression in Fx68 causing Windows users to be unable to correct start applications registered as custom URI handlers. Approved for 69.0b9 so we can get some testing in this before possible dot release inclusion.

https://hg.mozilla.org/releases/mozilla-beta/rev/eb91f1f3358e
https://hg.mozilla.org/releases/mozilla-beta/rev/daeca9ef3140
https://hg.mozilla.org/releases/mozilla-beta/rev/23d9c50ee55a

I successfully reproduced the issue on Firefox 68.0.1 under Windows 10 (x64) using the STR from Comment 0.

The issue is no longer reproducible on latest Nightly 70.0a1 (2019-07-29) and Firefox 69.0b9 under Windows 10 (x64).

Same here - we use Firefox 68.0.1esr x64 on some test machines and are affected in a local-links environment. With latest nightly, problem is not reproducible any more.

Will this fix get it into Firefox 68.1.0esr?

(In reply to Robert Geißler from comment #21)

Will this fix get it into Firefox 68.1.0esr?

We are currently testing the fix on beta, and if that looks good then we will uplift to ESR.

Comment on attachment 9079880 [details]
Bug 1567614: Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies!

Beta/Release Uplift Approval Request

• User impact if declined: Windows users starting applications with custom URIs registered with their system will not be able to correctly start the registered application.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1569756
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): * The feature is completely broken on release, so even if the fix doesn't work 100%, it is still an improvement over what was there.
• We're reusing existing code that is well tested on release via the launcher process.
• String changes made/needed: None

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Launching of external programs for custom URI schemes is currently broken. This affects Firefox ESR's ability to start various enterprise products, including Skype for Business, vSphere client, the newest version of the Zoom client.
• User impact if declined: Windows users starting applications with custom URIs registered with their system will not be able to correctly start the registered application.
• Fix Landed on Version: 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): * The feature is completely broken on release, so even if the fix doesn't work 100%, it is still an improvement over what was there.
• We're reusing existing code that is well tested on release via the launcher process.
• String or UUID changes made by this patch: None

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment on attachment 9079880 [details]
Bug 1567614: Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies!

regression fix for 68.0.2

https://hg.mozilla.org/releases/mozilla-release/rev/05634b24b8ef
https://hg.mozilla.org/releases/mozilla-release/rev/51aa10f2e418
https://hg.mozilla.org/releases/mozilla-release/rev/cb3f768f7cd8

https://hg.mozilla.org/releases/mozilla-esr68/rev/716e4b5fcc30
https://hg.mozilla.org/releases/mozilla-esr68/rev/b5700e59daa1
https://hg.mozilla.org/releases/mozilla-esr68/rev/d54b5d4890a7

FIREFOX_ESR_68_0_X_RELBRANCH:
https://hg.mozilla.org/releases/mozilla-esr68/rev/cc87c2fd68129b9d989995bbc2e2f8847be80c20
https://hg.mozilla.org/releases/mozilla-esr68/rev/c5c1fe625bb123a71c6e57abe75040981e2bd6d5
https://hg.mozilla.org/releases/mozilla-esr68/rev/b6aa833fc219fc95d54303be47dc3228b2756e12

Note: bug 1570845 does not block releasing this in 68.0.2 and 68ESR.

The issue is fixed on Firefox 68.0.2 (20190807142214 from Treeherder) and on 68.0.2esr (20190807144252 from Treeherder) under Windows 10 (x64) using Skype for Business from the Windows Store.

Hmm, looks like you've broken opening links from Thunderbird, bug 1573051 which is a blocker, and bug 1573051.

Since we're building TB 68.0 ESR from our own branch, I'll have to back it out there. Not being able to open links from e-mail really obliterates an e-mail client :-(

BTW, can you still launch 3rd party apps passing a link with a reference, the #thingy?

The change made for this bugfix seems to have cause an issue with our application. We use IdentityServer for our login. We use a .net desktop application to login via the browser and with the latest Firefox update, the IdentityModel.Client assembly returns this error:
"Malformed callback URL."

It worked prior to 68.0.2 and currently works fine with Chrome, Edge, and IE11.
Here is a stacktrace from Visual Studio:
at IdentityModel.Client.AuthorizeResponse.ParseRaw()
at IdentityModel.Client.AuthorizeResponse..ctor(String raw)
at IdentityModel.OidcClient.OidcClient.<ProcessResponseAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at IdentityModel.OidcClient.OidcClient.<LoginAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Daikin.DaikinTools.Authentication.AuthenticationService.<Login>d__66.MoveNext()

(In reply to cstaff16 from comment #32)

The change made for this bugfix seems to have cause an issue with our application. We use IdentityServer for our login. We use a .net desktop application to login via the browser and with the latest Firefox update, the IdentityModel.Client assembly returns this error:
"Malformed callback URL."

It worked prior to 68.0.2 and currently works fine with Chrome, Edge, and IE11.
Here is a stacktrace from Visual Studio:
at IdentityModel.Client.AuthorizeResponse.ParseRaw()
at IdentityModel.Client.AuthorizeResponse..ctor(String raw)
at IdentityModel.OidcClient.OidcClient.<ProcessResponseAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at IdentityModel.OidcClient.OidcClient.<LoginAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Daikin.DaikinTools.Authentication.AuthenticationService.<Login>d__66.MoveNext()

FYI, I added a new bug to report this: Bug 1574209

(In reply to cstaff16 from comment #33)

FYI, I added a new bug to report this: Bug 1574209

Thank you.

Added a regression test case to our External Software Affecting Firefox test suite.

This seems to have resurfaced in 70. Can anyone else confirm?

(In reply to ryan.calabrese from comment #36)

This seems to have resurfaced in 70. Can anyone else confirm?

Yep, same here. FF70 (fresh install, new profile) on Windows 10 with S4B 16.0.11328.20438 (32-Bit)

(In reply to holger.wesser from comment #37)

(In reply to ryan.calabrese from comment #36)

This seems to have resurfaced in 70. Can anyone else confirm?

Yep, same here. FF70 (fresh install, new profile) on Windows 10 with S4B 16.0.11328.20438 (32-Bit)

Are you clicking links with the skype protocol (lync<something>://something) ? Or opening ocsmeet files or similar (bug 1588975)?

(In reply to :Gijs (he/him) from comment #38)

(In reply to holger.wesser from comment #37)

(In reply to ryan.calabrese from comment #36)

This seems to have resurfaced in 70. Can anyone else confirm?

Yep, same here. FF70 (fresh install, new profile) on Windows 10 with S4B 16.0.11328.20438 (32-Bit)

Are you clicking links with the skype protocol (lync<something>://something) ? Or opening ocsmeet files or similar (bug 1588975)?

The former-- using lync<something> links from Skype for Business meeting invitations.

Please do not alter status or tracking flags.

I tried lync15:echo123?call with the following combination, but no repro. Skype was opened correctly whether it was already launched or not.

• Windows 10 1909 64bit
• Firefox 70.0.1 64bit
• Skype for Business 16.0.12130.20232 32bit

(In reply to ryan.calabrese from comment #39)

Are you clicking links with the skype protocol (lync<something>://something) ? Or opening ocsmeet files or similar (bug 1588975)?

The former-- using lync<something> links from Skype for Business meeting invitations.

Actually I'm wondering what "from Skype for Business meeting invitations" precisely means. What I tried above was to click a hyperlink of lync15: on an HTML page. Did you try to open Skype differently?

Set Firefox as one's default browser in Windows 10. From an external application such as Microsoft Teams, click "Join Skype meeting" which is formatted as follows: https://meet.lync.com/org-id/someones.name/MEETINGID

This is an invalid link for privacy reasons, but it validates on skype's page before hitting the link handler and erroring out:

https://meetings.sfbassets.com/joinux/prod/config.json?rand=0.10613...

https://webdir2a.online.lync.com/Meet/?origurl=aHR0c...

https://meetings.sfbassets.com/joinux/prod/v20190418.1/views/Redirect.html

https://webpooldm12a12.infra.lync.com/Meet/?origurl=aHR....

https://meetings.sfbassets.com/joinux/prod/v20190418.1/views/MeetingJoin.html

lync.exe - Entry Point Not Found

The procedure entry point GetCurrentProcessId could not be located in the dynamic link library C:\Program Files\Microsoft Office\root\Office16\RtmMvrSplitter.dll.

OK