Error loading Webview2Loader from UNC path

[Mark-IDB]

Description
This problem occurs not on every machine.
We have several VSTO applications which use Webview2. After an update of webview2 a number of users reported the application giving an error that webview2 could not be loaded. Our applications are started from a network share and because of the vsto there is a shadow cache created locally.
In version 1.0.1020.30 the webview2loader was loaded from the share (as seen in process explorer). But after upgrading it could not find the webview2loader.

Version
SDK: 1.0.1722.45
Runtime: Evergreen 112.0.1722.68
Framework: WinForms (vsto)
OS: Win10, Win11

Repro Steps
I found a way to easily reproduce the exception with an winform program.
The attached zipfile contains a winform project. Open the BrowserForm.cs. In the InitializeWebView2Async is a CoreWebView2Environment.SetLoaderDllFolderPath(path);
If the path is an UNC (ex: \\computer-name\Releases\OutlookTest\runtimes\win-x86\native) the Initialisation will give an exception. If the path is a local path (ex: D:\Releases\OutlookTest\runtimes\win-x86\native) it will continue loading.
The UNC is the same location as the local path so the Webview2loader is the same file.

In our VSTO i don't call (or want) the setLoaderDllFolderPath to be executed. It should automatically load the webview2loader from the unc path. Just as the 1.0.1020.30 did.

Start the app and click on the button 'test webview2'

UNC location or local path should make no difference.

In the 1.0.1020.30 version the SetLoaderDllFolderPath is not present. May be this change caused this behaviour/bug?
Screenshots

Additional context
Example project.
WebView2Test.zip

AB#44716307

[ElyssaJyu]

Hi @Mark-IDB, it seems like an outlook add-in scenario, and you have mentioned you won't want to use setLoaderDllFolderPath to local path. Do you mean that webview2loader.dll is expected loaded from outlook UNC path by default? In my knowledge, webview2loader cannot load from a UNC path. I'm trying to repro and find the root cause, but I'm blocked in getting a UNC path. If possible, could you share a sample VSTO project for easy repro?
Also, you can use procmon to check what behavior have been changed between two SDK versions. Thanks

[ElyssaJyu]

Currently, fixed version runtime cannot be run from a network location or UNC path, and please see this. Hope it can give you more details. Thanks

[Mark-IDB]

Hello @ElyssaJyu ,
We don't use the fixed version runtime but the evergreen. Loading from UNC was not a problem in 1.0.1020.30.
I have created a small Outlook VSTO project which can reproduce the problem. The following steps are necessary:

1 if you use outlook 365, rename the webview2loader.dll in C:\Program Files (x86)\Microsoft Office\root\Office16. The addin will use this file if it can't be found on the unc path. (outlook 2016 doesn't have this file so the problem is always present)
2. run the outlook vsto addin (Webview2OutlookAddin which is attached). Click the button on the webview2 and see that a website is displayed. (webview2loader can be seen loaded from the local path in process explorer
3. copy the bin\debug folder including the runtime folder to an unc path.
4. change the manifest location in the registry (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\WebView2OutlookAddIn) to the new unc location (ex: \servername\share\WebView2OutlookAddIn.vsto|vstolocal )
5. start outlook and repeat step 2 and observe that the website isn't displayed any more.
6. If the manifest location is a drive letter to the unc path it will work.

I hope this example will help you locating the problem. Thanks for the reply!

WebView2OutlookAddIn.zip

[champnic]

@Mark-IDB Is there a reason you don't want to try the setLoaderDllFolderPath function?

[Mark-IDB]

@champnic if i have to use setLoaderDllFolderPath it wil be a last solution to the problem. Because:

• I can't use a unc location
• I have to copy the loaderdll's to a local directory
• have to resolve which cpu type the client is because the setloaderdllFolderPath can't resolve this (normally a runtimes/win-cpytype/native folder structure is present in the output folder.

[champnic]

Thanks for the info. I've added this bug to our backlog to investigate fixing.

[champnic]

This is fixed in the latest prerelease SDK: 1.0.1988-prerelease Thanks!

[Mark-IDB]

@champnic
I have waited for the normal release of the sdk (1.0.2045.28) to test this issue.
But the problem is still there. (also in the 1988 prerelease)

if the addin is loaded from an unc path(!) the webview2 component cannot find the webview2loader.dll.
If the unc path is mapped to a drive letter than there is no problem. So it is important to set the manifest location to an unc path.

[Mark-IDB]

@champnic
Just used the newest sdk 1.0.2088.41 but the problem still remains.
I have created a new bug as this still isn't working (#4081)

[ThomasReinhardt]

I can confirm it still does not work. Also, just to clarify: this has nothing to do with outlook. A simple WinForms application that opens a hardcoded page is all that is needed to reproduce this bug.

[champnic]

@ThomasReinhardt We're tracking this in #4081. I was unable to reproduce outside of a VSTO, so if you can provide a sample or repro steps that demonstrated the issue for you that would be helpful.