[Problem/Bug]: GetAvailableBrowserVersionString fails with EntryPointNotFoundException after upgrading to SDK 1.0.2365.46

[ShaunLoganOracle]

What happened?

After upgrading to SDK 1.0.2365.46:

1. compilation succeeded without any changes (unlike in #4352)
2. at runtime, calling CoreWebView2Environment.GetAvailableBrowserVersionString() with no arguments throws an exception With earlier SDKs (<= 1.0.2088.41 (for example), the no-arg call compiled and worked as expected at runtime.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

122.0.2356.52

SDK Version

1.0.2365.46

Framework

Winforms

Operating System

Windows 11

OS Version

Win 11 23H2 Build 22621.3155

Repro steps

Upgrade simple app to SDK 1.0.2365.46 Set breakpoint on call to CoreWebView2Environment.GetAvailableBrowserVersionString(); // no args passed Trigger code path that hits breakpoint. Step over. Observed:

Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'.

 at Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableCoreWebView2BrowserVersionStringWithOptions(String browserExecutableFolder, ICoreWebView2EnvironmentOptions options, String& versionInfo)
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableBrowserVersionString(String browserExecutableFolder, CoreWebView2EnvironmentOptions environmentOptions)
   at mystuff.WebView2Helper.GetWebView2Version() in C:\dev\main-feature\myStuff\WebView2Helper.cs

Expected: no exception

Notes: I tried compiling and passing null for both arguments to the method - same result at runtime. Eg. method call: var version = CoreWebView2Environment.GetAvailableBrowserVersionString (browserExecutableFolder: null, environmentOptions: null); produces same result.

I am aware of the issue in #4352, and I never adopted that SDK, so never released the workaround to fix that issue. However, in testing SDK 1.0.2277.86, I did not see the EntryPointNotFoundException when I did try the workaround.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Regression in newer SDK

Last working version (if regression)

1.0.2088.41

AB#49329163

[vickiez]

Hi @ShaunLoganOracle, we're not able to repro this with the same SDK version. Can you provide the full dump? You can send it to [email protected] if it contains app details.

It's also possible that the build output is caching the old loader dll. Can you see if the issue repros after cleaning and rebuilding?

[ShaunLoganOracle]

@vickiez The issue reproduces after cleaning and rebuilding. Here is some addition context: My app is a VSTO add-in running within Excel. I can see that the loaded WebView2Loader.dll instance is from the MS Office folder - not the one from where I build my add-in: WebView2Loader C:\Program Files\Microsoft Office\Root\Office16\WebView2Loader.dll WebView2Loader Version 1.0.1774.30

We investigated which WebView2Loader.dll was active a while back (link). Ever since the fix for #2372 was included in the WV2 SDKs, we have relied on the default behavior for locating WebView2Loader.dll, which for our add-in, ends up using the version from Office16.

There seems to be an incompatibility between the SDK and older WebView2Loader.dlls, this is a regression.

[vickiez]

@ShaunLoganOracle can you use the CoreWebView2Environment.LoaderDllFolderPath to point to the correct dll? We added this property for situations like this

[ShaunLoganOracle]

@vickiez We view this as a regression in behavior that block us from upgrading to SDK 1.0.2365.46, we'd like to see a fix from Microsoft so that our existing code continues to work with the new SDK as it did with the old. Thanks.

[vickiez]

@ShaunLoganOracle our expectation is that when you update SDK, you also use the new loader that ships with it. We only guarantee compat between SDK (including loader) and WebView2 Runtime. Are you able to try the workaround?

I'll create a bug to investigate further in case there is an issue on our end that prevents you from using the correct loader by default.

[ShaunLoganOracle]

@vickiez re:

a bug to investigate further in case there is an issue on our end that prevents you from using the correct loader by default.

Yes, thanks. We would very much like to use the correct loader by default.

Can you change the way that loaders are found? We include the matching loaders with our product (a VSTO add-in). However, it seems that there is a redundant loader under Excel that is found first. If you are not going to support older loaders, please make sure older loaders under Excel are not given priority. Thanks!

[ShaunLoganOracle]

Hi @vickiez Is there a bug filed for this issue and how can I track it? We want to track progress on this issue because we're blocked from upgrading our WebView2 SDK until it is resolved.

[vickiez]

Hi @ShaunLoganOracle, we have an internal bug linked to this issue and we'll post updates here. In the meantime have you tried the workaround? It should unblock you on upgrading SDK

[ShaunLoganOracle]

@vickiez Thanks, but the workaround is not feasible for us and we're looking for a definitive fix for this bug as soon as possible. We (Microsoft and Oracle) have a broad audience of joint customers for this Excel add-in and we'd like to get them an updated WebView2 SDK. Is there any ETA on the fix?

[AlexDavisOracle]

@vickiez Is there any update? It is important for us to upgrade the SDK and we are blocked by this issue. Thanks in advance for putting it on the priority list!

[vickiez]

@ShaunLoganOracle @AlexDavisOracle we are working on a fix now - unfortunately it won't change which loader is picked up by default but it should resolve this particular error so you are unblocked on upgrading SDK

[AlexDavisOracle]

Thanks for the update, @vickiez ! Is the fix available now for verification?

[AlexDavisOracle]

@vickiez Is the fix available now for verification? We really need to upgrade the SDK...

[ShaunLoganOracle]

@vbryh-msft @vickiez @lflores-ms @champnic Could we please get an update on the status of this fix? It is blocking our ability to upgrade to the latest WV2 SDK. Thanks.

[ShaunLoganOracle]

@vickiez @vbryh-msft @lflores-ms @champnic I have an important update (including root cause) for this issue. Let me start by summarizing the issue (and end with Next Steps)

Issue Summary Our VSTO add-in running in Excel calls CoreWebView2Environment.GetAvailableBrowserVersionString() with no arguments. When the add-in uses older WV2 SDKs (eg. 1.0.1774.30) this works as expected. Using a new SDK (eg. something after 1.0.2088.41), this method call fails with "Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'." You suggested a workaround that we explicitly set the WV2 loader path (in recent SDKs, this is CoreWebView2Environment.SetLoaderDllFolderPath (loaderFolderPath)). This does not work in our case (explanation follows). For corporate policy compliance, we need to upgrade the WV2 SDK used by our add-in on a frequent basis.

Root Cause - summary Our VSTO add-in runs in the Excel process. By the time our add-in's ThisAddin.Startup event handler is called (before any of our add-in code has been called), the Excel process has already loaded its own copy of WebView2Loader.dll. This loader DLL is from the Office folder: C:\Program Files\Microsoft Office\root\Office16\WebView2Loader.dll. The version of this loader DLL presumably corresponds to the WV2 SDK that Office was built with. The add-in can have no influence on which WV2 loader is loaded already by Excel, hence the suggestion to call CoreWebView2Environment.SetLoaderDllFolderPath(...) does not work. Some changes made by Microsoft to the WebView2 SDK and loader .DLL (specifically, adding a new method, changing the signature of an existing method) are incompatible when an older version of the loader DLL has already been loaded. @vickiez noted above:

"our expectation is that when you update SDK, you also use the new loader that ships with it. We only guarantee compat between SDK (including loader) and WebView2 Runtime."

So our use case (Excel loads WebView2Loader.dll, add-in compiled against a different SDK) has been overlooked.

Root Cause - details In our test case with Excel Microsoft 365 MSO (Version 2407 Build 16.0.17830.20166) 64-bit , the WebView2Loader.dll version loaded by Excel from the Office folder is: 1.0.1774.30.

When our add-in calls CoreWebView2Environment.GetAvailableBrowserVersionString(), (with no args) the call is resolved to a DllImport method referencing the loader DLL. In older SDKs, it resolves to: [DllImport ("WebView2Loader.dll")] internal static extern int GetAvailableCoreWebView2BrowserVersionString( . . .); Since this entry point is present in older loader DLLs, everything works as expected.

In newer SDKs, it resolves to: [DllImport ("WebView2Loader.dll")] internal static extern int GetAvailableCoreWebView2BrowserVersionStringWithOptions(. . .); Since the WithOptions method does not exist in older loader DLLS, we see the error: "Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'."

The exception stack from the new SDK + old DLL case:

Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'.
at Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableCoreWebView2BrowserVersionStringWithOptions(String browserExecutableFolder, ICoreWebView2EnvironmentOptions options, String& versionInfo)
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.GetAvailableBrowserVersionString(String browserExecutableFolder, CoreWebView2EnvironmentOptions environmentOptions)

Next Steps Microsoft needs to upgrade the WV2 SDK (and WebView2Loader.dll) for Office and push that out as quickly as possible to users' desktops. Or, Microsoft needs to provide a mechanism to support the valid use case of using Excel with SDK xx.x and and add-in using SDK yy.y.

We'd like to hear back from Microsoft about the plans to address our use case and this issue, thanks.

[champnic]

Thanks for this great detail @ShaunLoganOracle! We'll try to work with Office to get them to update their SDK/WebView2Loader. In the meantime, I'm building a quick fix and I'll have a preview SDK package for you to validate shortly, if you don't mind.

[champnic]

@ShaunLoganOracle Would you mind trying out this SDK package and see if it resolves the issue for you? Microsoft.Web.WebView2.1.0.2806-prerelease.zip

[ShaunLoganOracle]

Thanks for your response, @champnic We'll take a look asap.

[ShaunLoganOracle]

@champnic We have confirmed with SDK 1.0.2806-prerelease that we no longer see the "Unable to find an entry point named '?' in DLL 'WebView2Loader.dll'." error calling CoreWebView2Environment.GetAvailableBrowserVersionString (); // with no args. Thank you for looking into that and providing this fix.

I think you'll agree that this does not address the larger issue we uncovered where Excel has already loaded an older version of WebView2Loader.dll which could be incompatible with a newer SDK used by our VSTO add-in.

There are many, many (joint MSFT/ORCL) users out there with different versions of Excel updated on different frequencies which could have a variety of WebView2Loader.dll versions in their Office folders. Oracle needs to update the WV2 SDK that our add-in uses frequently in order to comply with corporate policies. We have a legitimate concern that future changes to the WV2 SDK like the one just resolved (GetAvailableBrowserVersionString()) could arise and cause failures for a large number of users.

[champnic]

Thanks for confirming the fix! I'll try to get that out shortly.

We have two avenues we are pursuing to address the larger issue of apps hosting other apps with different/old WebView2Loader.dlls. First, we are asking Office to upgrade their SDK - I'm not sure what the timeline would be on that. Second, we are also investigating building the WebView2Loader functionality directly into the Microsoft.Web.WebView2.Core.dll, avoiding the need for separately shipping, loading, and managing the native WebView2Loader.dll. This would allow every WebView2 app to load using the loader that corresponds with the SDK they are using. However, I'm not sure on what the timeline of that work would be yet.

[ShaunLoganOracle]

re: your fix - great! we'll look forward to that appearing in a stable SDK soon.

re: Office team upgrading their SDK - we understand that different product groups have policies and processes for upgrading and appreciate any nudges you can give them. 1.0.1774.30 was released almost 16 months ago. That's 16 months of goodness from the SDK team that they're missing out on :-)

re: eliminating the loader and adding its capabilities into WebView2.Core - this sounds great! I bet there would be a lot of support for this from other WV2 developers, particularly add-ins or other cases where there might be multiple WV2 consumers in the same process. We'd be glad to add our voice to support this effort if it would help.