1567614 - "Entry Point Not Found" message box when opening Skype for Business URL

Status: VERIFIED FIXED

(External Software Affecting Firefox :: Other, defect, P1)

Description

[(No longer employed by Mozilla) Aaron Klotz]

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.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

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.

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

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.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

I sent an email to the Microsoft discussion list.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

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.

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

(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.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1567614: Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies!

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

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1567614: Part 2 - Add ShellExecuteByExplorer overload to handle absolute PIDL lists; r=jmathies!

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

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1567614: Part 3 - Use ShellExecuteByExplorer in nsMIMEInfoWin; r=jmathies!

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

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e8bf96e8321a
Part 1 - Refactor launcher process's LaunchUnelevated to delegate to ShellExecuteByExplorer; r=jmathies
https://hg.mozilla.org/integration/autoland/rev/cae98337ddda
Part 2 - Add ShellExecuteByExplorer overload to handle absolute PIDL lists; r=jmathies
https://hg.mozilla.org/integration/autoland/rev/e7d500f650cc
Part 3 - Use ShellExecuteByExplorer in nsMIMEInfoWin; r=jmathies

Comment 11

[Alexandru Michis [:malexandru]]

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

Comment 12

[Heramb]

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?

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

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.

Comment 15

[(No longer employed by Mozilla) Aaron Klotz]

[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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

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 17

[(No longer employed by Mozilla) Aaron Klotz]

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 18

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

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

Comment 20

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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).

Comment 21

[Robert Geißler]

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?

Comment 22

[(No longer employed by Mozilla) Aaron Klotz]

(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 23

[(No longer employed by Mozilla) Aaron Klotz]

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

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 25

[Julien Cristau [:jcristau]]

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

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 27

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 28

[(No longer employed by Mozilla) Aaron Klotz]

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

Comment 29

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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.

Comment 30

[Jorg K (CEST = GMT+2)]

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 :-(

Comment 31

[Jorg K (CEST = GMT+2)]

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

Comment 32

[cstaff16]

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()

Comment 33

[cstaff16]

(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

Comment 34

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to cstaff16 from comment #33)

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

Thank you.

Comment 35

[Emil Ghitta, QA [:emilghitta]]

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

Comment 36

[ryan.calabrese]

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

Comment 37

[holger.wesser]

(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)

Comment 38

[:Gijs (he/him)]

(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)?

Comment 39

[ryan.calabrese]

(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.

Comment 40

[(No longer employed by Mozilla) Aaron Klotz]

Please do not alter status or tracking flags.

Comment 41

[Toshihito Kikuchi [:toshi]]

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?

Comment 42

[ryan.calabrese]

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