WebView2 Evergreen Standalone Installer - x64

[cgeier]

Description
WebView2 Evergreen Standalone Installer installs both x64 and x86 versions to %ProgramFiles(x86)%\Microsoft\EdgeWebView\Application.

Version

SDK: v1.0.705.50 (Microsoft.Web.WebView2)
Runtime: 89.0.774.45 (Evergreen Standalone Installer)
VB.NET WinForms
TargetFrameworkVersion: v4.6.2
Platform: Any CPU (Prefer 32-bit)
OS: Win10 and Win7
NuGet Package Management: PackageReference

Repro Steps

I created a demo application and compiled as Any CPU (Prefer 32-bit). I noticed that if WebView2 x64 was installed, but not WebView2 x86, my demo application attempted to use WebView2 x64. The "Microsoft Edge WebView2" processes seemed to get created (as seen in Task Manager), and calling CoreWebView2Environment.GetAvailableBrowserVersionString() seemed to report the correct version. However, the application hung and it would not display the website (white screen).

After further investigation, it appears that the WebView2 Evergreen Standalone Installer installs both x64 and x86 versions to %ProgramFiles(x86)%\Microsoft\EdgeWebView\Application. If one installs x86 version and then the x64 version, the x64 version will overwrite the x86 version causing one's WebView2 control to display a white (blank) screen.

This can be verified by installing the x64 version and then use dumpbin.exe to find the version:

dumpbin.exe location:

• %ProgramFiles(x86)%\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64\dumpbin.exe
• %ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\dumpbin.exe

Option 1: Open a Developer Command Prompt for Visual Studio 2019 window

• Click/select Start menu
• Select Visual Studio 2019
• Select Developer Command Prompt for Visual Studio 2019

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional>dumpbin "%ProgramFiles(x86)%\Microsoft\EdgeWebView\Application\89.0.774.45\msedgewebview2.exe" /headers | find /i "machine"

Option 2: Open a cmd window and run the following command (VS 2019):

C:\Users\Test> cd %ProgramFiles(x86)%\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64> dumpbin "%ProgramFiles(x86)%\Microsoft\EdgeWebView\Application\89.0.774.45\msedgewebview2.exe" /headers | find /i "machine"

Output:

8664 machine (x64) indicates the msedgewebview2.exe file is x64.

14C machine (x86) indicates the msedgewebview2.exe file is x86.

The registry entries are also incorrect. Windows 7 and Windows 10 seem to write entries for both x86 and x64 versions to HKLM\Software\Wow6432Node\Microsoft\EdgeUpdate\Clients\{...}. (other registry entries weren't verified).

After this issue is resolved, further testing may be required to ensure that when an application is compiled as Any CPU (Prefer 32-bit), and the x64 version of WebView2 Runtime is installed, but not the x86 version of WebView2 Runtime, that an error (exception) is raised.

Update: It appears that this issue also affects the Evergreen BootStrapper. On a computer running Windows x64, the WebView2 Runtime x64 is installed to %ProgramFiles(x86)%\Microsoft\EdgeWebView\Application.

AB#32060505

[champnic]

Thanks for the bug report @cgeier, and the follow-up on other threads! I've opened this bug on our backlog and we'll take a look right away.

[champnic]

Hey @cgeier - Can you expand a bit more when you say both versions are installed? When I tried the bootstrapper it only installed one msedgewebview2.exe in the ...\Applications<version>\ folder. Or is the assertion that the exe is both x86 and x64?

When running dumpbin I only see x64.

It would be a bug if the x64 runtime got installed by the bootstrapper on an x86 OS. The registry path/location is dependent on the bitness of the OS, not of the runtime. That's why on your machine both x86 and x64 runtimes are using the same registry path.

Any x86/x64 app should be able to use either arch runtime. So we should dig in further as to why the app is failing with x64 runtime. Can you confirm if you uninstall the WebView2 runtime, and then specifically install the x86 runtime, that the app works as expected?

[cgeier]

@champnic :

Sorry, I made a mistake in the last sentence. I've updated the post.

It's my understanding that, historically, on a Windows x64 OS, 32-bit programs should be installed in %ProgramFiles(x86)% and 64-bit programs should be installed in %ProgramFiles%. Likewise, in the registry, on a Windows 64-bit OS, 32-bit programs are stored below HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node, whereas 64-bit programs are stored to HKEY_LOCAL_MACHINE\SOFTWARE. The point I was trying to make is that the 64-bit WebView2 runtime shouldn't be storing files in %ProgramFiles(x86)% nor should the 64-bit Webview2 runtime be storing registry entries in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node.

[champnic]

Ah gotcha. So this isn't an error or bug that's blocking you, but rather a design bug. I'll update it to indicate that, thanks for the clarification!

[will-hickman]

I'd like to request that we classify this as a bug again, since this can lead to issues for an app that runs as 64 bit (and so requires the 64-bit WebView2 runtime).

Example:

• Machine has run the 32-bit WebView2 evergreen installer previously
• My installer wants to install the 64-bit version, but it sees that WebView2 is already installed (by checking the registry).

If my app runs as a 64-bit process, and it's trying to use the methods recommended for determining whether to install WebView2 (i.e. checking the registry), I have no way of telling whether I have the 64-bit runtime components installed. Both installers write to the same registry location, and they have identical information.

So far, we've come up with the following options:

• Don't worry about it - we'd be relying on luck and/or administrators to run the installer by hand if/when there are issues
• Make a custom action (we're building a Windows installer) that's likely fragile (because it would be based on something like looking at the install directory for certain files) to determine whether the 64-bit components are installed.
• Always run the 64-bit evergreen installer, regardless of whether it looks like WebView2 is installed or not.

I think ideally the two installers would write something different to the registry. An additional key indicating the bitness would help and shouldn't break existing checks that folks have written already, but it would allow folks to update their install checks to verify that the 64-bit runtime is installed, if their app needs to run as 64-bit (like ours).

[champnic]

Hey @will-hickman -

Have you noticed any actual issues arising from this, or just general concerns about mismatched bitness?

A 64-bit app running on a 64-bit machine should work fine with a 32-bit WebView2 runtime. I'm also trying to confirm, but I believe if you use the bootstrapper (https://developer.microsoft.com/en-us/microsoft-edge/webview2/#download-section) that it will automatically upgrade to the 64-bit version if it can, and won't do anything if already installed. This should save you from having to do custom logic yourself.

[will-hickman]

Sorry for never getting back to you on this - we're no longer concerned about this, because our use case is covered by the evergreen auto-update behavior.

The evergreen installers (including the standalone/offline version, which is what we're using) appear to upgrade to the 64-bit version when they update, as you mentioned above, so that's going to work just fine for us.

It wasn't clear to me that the auto-update would upgrade to the 64-bit version previously, and all of our test scenarios were on VDI images that were rebuilt from scratch each time (and didn't run windows updates the way an end user machine would). They happened to have the 32 bit version installed first (order of install details that don't matter for real-life scenarios), so they were skipping the 64-bit install instruction from our 64-bit app, but then that 64-bit app didn't work (because the x64 folders weren't there).

In real-life scenarios, this isn't a concern, because we don't expect anyone to be running the 32-bit webview2 installer on these machines anyway. We just wanted to make sure that we could fix it, if it happened, but it seems like the auto-update will do what we need.

[champnic]

Sounds great, thanks for confirming!