[Problem/Bug]: Still Error loading Webview2Loader from UNC path for VSTO add-in

[Mark-IDB]

What happened?

I have just upgraded the webview2 sdk to the latest release (1.0.2088.41).
The problem reported earlier in bug #3465 are still present in a vsto project.

See the reproduction in #3465 to encounter the bug.

We still have to use 1.0.1020.30 to use our software without problems.

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

118.0.2088.46

SDK Version

1.0.2088.41

Framework

Winforms

Operating System

Windows 10

OS Version

10945.3570

Repro steps

See all steps described in #3465

Regression

Regression in newer SDK

Last working version (if regression)

1.0.1020.30

AB#47129343

[champnic]

@Mark-IDB I just tried and see WebView2Loader.dll loading correctly from a UNC path using SDK 1.0.2088.41. I wonder if it has something to do specifically with being a VSTO?

[Mark-IDB]

@Mark-IDB I just tried and see WebView2Loader.dll loading correctly from a UNC path using SDK 1.0.2088.41. I wonder if it has something to do specifically with being a VSTO?

Hello @champnic ,
Yes, it has to do with being a VSTO project. Which is why i added a testproject containing a vsto project. A regular exe file works as expected.
I added a new project zip file to this bug. It contains a excel vsto.
If you load the vsto from an unc path the CoreWebView2Environment.CreateAsync throws an DLLNotFoundException 'Unable to load DLL 'WebView2Loader.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'
(Important; remove the webview2loader.dll from your office 365 solution, because this one wil be used and there will be no problem. But Office 2016/2019 won't have this file)
If you load the vsto from a network drive there is no problem. This situation was working in the mentioned previous SDK version.
ExcelAddInWebView.zip

[ThomasReinhardt]

As requested by @champnic here is a reproducer that exposes the bug outside of a VSTO. My environment: Windows 11 23H2 fully patched. I can also reproduce at a customer site on Windows Server 2019.
Steps to reproduce:

1. unzip the BrowserLogin.zip
2. open the .sln file in visual studio (I used 2019 professional if that matters)
3. click build/rebuild solution
4. copy everything from $src\bin\x64\Release x64\ to C:\temp\BrowserLogin
5. share C:\temp (all defaults)
6. open command prompt
7. enter \\$computername\temp\BrowserLogin\BrowserLogin.exe https://google.com

On step 7 nothing will happen - an empty WinForms application opens
If you use the local path instead C:\temp\BrowserLogin\BrowserLogin.exe https://google.com the page opens as expected.

BrowserLogin.zip

[champnic]

Thanks both! I was able to repro the issue by loading the entire application from a UNC path. In the past we were only testing that the WebView2Loader.dll could be properly loaded from a UNC path, and that seems to be working fine.

The issue I'm seeing when the entire app is loaded from UNC is that .NET fails to load Microsoft.Web.WebView2.Winforms.dll. Using Process Monitor I see it trying to load the assembly from the GAC which fails (as expected), and then tries to load from an incorrect UNC path. For example, I see it try to load from:
\\localhost\c$\c$\<pathToWinforms>
With an extra c$, and it should have been:
\\localhost\c$\<pathToWinforms>

Is that similar to what you are seeing?

[champnic]

I'm not sure yet whether this is a bug in how .NET looks for assemblies with UNC paths, or if it's something we have control over in the WebView2 package.

[champnic]

I reached out to the .NET team and they mentioned that they thought that loading binaries from UNC paths was a known issue. I also tried with another Winforms WebView2 app, but this time using .NET 7, and it loaded fine from the local UNC path using c$. It correctly found the right path and didn't append an extra c$. So it seems it was a known issue at some point and then fixed in later versions of .NET.

As this seems to be a bug in .NET that has been resolved in newer versions, I'm going to close this item as out-of-scope for WebView2. Can you please try with the newer .NET versions?

If you are still running into this issue and have checked with Process Monitor that it's some other path or files that's failing to load, please let me know and we can consider looking into it further. Thanks!

[Mark-IDB]

Hi @champnic ,
The loading binaries from an UNC path is not a problem in .Net. All other dependencies are loaded. (Incl. Microsoft.Web.WebView2.WinForms.dll because if the webview2loader.dll is in the office path everything loads and works fine)
Also it is working with webview 1.0.1020.30!! So it is a problem in webview2.

I also would like to upgrade to a newer .Net version very much....But this is not possible in a vsto application! You are limited to .Net Framework (and we are using the latest 4.8 version)

[Mark-IDB]

Thanks both! I was able to repro the issue by loading the entire application from a UNC path. In the past we were only testing that the WebView2Loader.dll could be properly loaded from a UNC path, and that seems to be working fine.

The issue I'm seeing when the entire app is loaded from UNC is that .NET fails to load Microsoft.Web.WebView2.Winforms.dll. Using Process Monitor I see it trying to load the assembly from the GAC which fails (as expected), and then tries to load from an incorrect UNC path. For example, I see it try to load from: \\localhost\c$\c$\<pathToWinforms> With an extra c$, and it should have been: \\localhost\c$\<pathToWinforms>

Is that similar to what you are seeing?

Thanks for the tip on process monitor. I am seeing it searching for webview2loader.dll on all paths in the environment (which is why it is working if the loader file is present in the office install).
But with a unc path it seems to join the 2 locations... for example this is a location its trying:
C:\Users\MK\AppData\Local\Microsoft\WindowsApps\file:\idbgroep.local\Users\Transfer\Mark\ExcelWebview2\Microsoft.Web.WebView2.Core.DLL\runtimes\win-x86\native\WebView2Loader.dll

The last part would be correct (but the Microsoft.Web.WebView2.Core.DLL would not be a directory). The location seems a local search path combined with the actual path.

Once again: This is working in 1.0.1030.20! This version also doesn't allow you to specify the location of the webview2loader.dll. The later versions do and the problem starts with these versions.

[ThomasReinhardt]

@champnic
I can not confirm the mangled path. Please see the attached process monitor trace. If you filter with path begins with \\ you can see that all the .DLLs are found and I think they are also loaded correctly. I have included the other events my binary created just in case. The binary is the same that I have attached above.

Also, I can not change to .NET 7 as our customer specifically required Framework 4.7.1 to use.

Logfile.zip

[champnic]

Reopening again for the VSTO issue. @ThomasReinhardt trying your app (though I removed the args piece of it and just have it always navigate to a specific url) it worked fine even from a UNC path and using .NET framework. Not sure what's going wrong on your machine but I'd recommend debugging it and seeing if there's an exception being thrown or other info. The procmon log you shared also seemed to indicate that the WebView2Loader.dll was being located correctly and wasn't showing the mangled paths that I saw (which required a dollar sign to be in the UNC path).

[ThomasReinhardt]

I just installed a complete vanilla Server 2019 on a physical laptop. Only change I have done to the installation is installing the WebView2 Evergreen Standalone Installer. The error is still reproducible. There are no exceptions (there is a try catch in Form1.Navigate () but for completeness I added one in Program.Main() ). No events in EventViewer or anything. I am currently installing all windows updates but I do not expect any changes.
@champnic can you please try to check on a vanilla installation? Also, how exactly did you remove the args piece? I suppose just a webView.Source = new Uri("..."); in the Form1 constructor, right?

[champnic]

@ThomasReinhardt Yes, just set the uri in the constructor. Can you try stepping through the code and verify that the expected code is getting hit? You can also add WebView2.CoreWebView2InitializationCompleted handler and verify that args.IsSuccess is true, and if not, check what the error is.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2initializationcompletedeventargs?view=webview2-dotnet-1.0.2151.40

[champnic]

@Mark-IDB I've been trying to get the add-in to load from a UNC but have been unsuccessful so far. I'm not sure why as the regkeys and files seem to be loaded fine in Process Monitor. I've reached out to the Outlook team and am waiting to hear back. Are your repro steps complete for how you are changing the registry to successfully load your add-in from UNC?

[Mark-IDB]

Hi @champnic ,
If the vsto is not loading from the unc path it could be that you need to add this registry setting (32 or 64 bit!):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\vsto runtime Setup\v4]
"EnableVSTOLocalUNC"=[dword:00000001]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4]
"EnableVSTOLocalUNC"=[dword:00000001]

[reynoldslabware]

A similar issue with UNC though not with web forms scenario.

My VS 2022 DLL was just compiled with WebView SDK 1.0.2194
The runtime version cross reference is 119.0.2151.44.manifest
The WebView2Loader.dll is 10-31-2023 4:23 AM
This is for Windows 10 as well.
A shortcut pointing to local files runs my scenario OK.
Target- the path to the executable
Start in - the local path

A shortcut with a UNC path to the same local folder encounters a failure. That shortcut has
Target- the UNC path to the executable
Start in - the local path

We are using local files. There is no web server in play.
The user data folder is C:\Users\USER~1.LAB\AppData\Local\Temp\WebView2User
The runtime folder is \vm-lab\C$\Lab\webview2_runtime
The environment is created OK.
The controller is created OK.
The call to create a webview2 widget returns OK.
The call to navigate returns OK. The URL being loaded is
file://vm-lab/C$/Lab/hello.html
The widget displays all grey.
About 15 seconds later I see
myBrowserProcessExitedEventHandler() called
BrowserProcessExited result kind 1

The '1' indicates 'error' per
https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2browserprocessexitkind?view=webview2-dotnet-1.0.2106-prerelease

Where can I find more information on the cause of the error?
Is there any other diagnostic information guidance?
Thank you

[champnic]

@Mark-IDB Thanks - I was able to repro the issue with that and I'm now debugging.

@reynoldslabware Can you open a separate issue for that? It sounds like a different problem if the dlls are loading fine.

[reynoldslabware]

Thank you. I will open a separate issue. Is was soooo similar that I wanted to start herein and fork if requested. Much appreciated

[champnic]

@Mark-IDB I've root caused the issue and I'm testing a fix now :)

[Mark-IDB]

@Mark-IDB I've root caused the issue and I'm testing a fix now :)

Great! :-)

[champnic]

Microsoft.Web.WebView2.1.0.2226.zip
Seems to fix the issue, working on getting it checked in! Would you mind trying out this nuget package (after extracting from zip) to see if it resolves the issue for you as well?

[reynoldslabware]

FWIW
@champnic As a reference point to the related UNC'ish issue
#4171
I still see the browser process exiting in my scenario. Maybe you were expected that?
The WebView2Loader.dll timestamp used is Nov/15/2023 6:56 PM.
I believe that confirms the use of the 1.0.2226 NuGet package which I do see in my Visual Studio solution.

[ThomasReinhardt]

@champnic unfortunately it does not solve my issue. I added the init listener as you suggested last week. Local execution works normal, calling over UNC does not:

\\localhost\temp\BrowserLogin\BrowserLogin.exe https://google.com

CoreWebView2InitializationCompletedEventArgs: IsSuccess = False InitializationException = System.Runtime.InteropServices.COMException (0x800700AA): The requested resource is in use. (Exception from HRESULT: 0x800700AA) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo) at Microsoft.Web.WebView2.Core.CoreWebView2Environment.<CreateCoreWebView2ControllerAsync>d__98.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at Microsoft.Web.WebView2.WinForms.WebView2.<InitCoreWebView2Async>d__25.MoveNext()

[champnic]

@reynoldslabware That's expected, as your issue seems to be separate from this one.

@ThomasReinhardt That also looks like a separate issue. 0x800700AA "Resource is in use" can be due to having trouble connecting to an existing msedgewebview2.exe runtime instance if one is already running. Can you make sure there are no running WebView2 processes related to you app before running it, so you're starting from a clean slate? Can also see: #2446

[Mark-IDB]

Microsoft.Web.WebView2.1.0.2226.zip Seems to fix the issue, working on getting it checked in! Would you mind trying out this nuget package (after extracting from zip) to see if it resolves the issue for you as well?

@champnic I can confirm it is working now :)

[ThomasReinhardt]

@champnic There are no processes that relate to WebView2 and/or my test program. The error is 100% reproducible - even directly after a reboot on a completely fresh Server 2019 installation. Tested with the Administrator user. Also, I don't think #2446 applies here since there is only a single invocation and no reuse.

After more testing I think the error might just be a misleading error code. When I gave "Full Access" to "Everyone" on the share the test seems to work. Have to check at the customer and of course full access is not a solution but at least there is progress.

@champnic can you please check again with just "read" permissions on the share?

[champnic]

@Mark-IDB Thanks for verifying!

@ThomasReinhardt I think that might be expected then. You'll need "Execute" permissions to correctly allow loading and running code from the share.

[champnic]

The fix has been checked in and should be available in the next pre-release SDK.

[ThomasReinhardt]

@champnic I have done some tests and whatever I do the application only works if the calling user has write permissions. To be more precise: my share has to have "change" and "read" permissions in addition to "create files/write data" and "create folders/append data" along with read + execute permissions on the filesystem.

That is not acceptable from a security point of view (write permissions on a share).

I suspect that is kind of by design for the evergreen runtime. I have to re-check with the fixed version runtime.

[champnic]

Hm, I suspect the write permissions may be coming from the User Data Folder. Are you setting the User Data Folder somewhere local, or is it defaulting to the share? Can you try using a local UDF if you aren't, like a folder in C:\temp?

[ThomasReinhardt]

@champnic Thanks so much! That did the trick!
Maybe the error handling needs a little more love so that the next guy does not have to wonder about funny messages too :)

[champnic]

@ThomasReinhardt Glad to hear it's working now!