MicrosoftEdge / MicrosoftEdge/WebView2Feedback
WebView2 Evergreen Standalone Installer - x64
Nobody has claimed this yet.
- Dominant language
- PowerShell
- Stars
- 526
- Forks
- 67
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the x86/x64 installation-order problem with the Evergreen Standalone Installer and Bootstrapper, using the listed dumpbin commands to inspect msedgewebview2.exe and checking the registry entries described in the report. Done means the installers place and register the correct architecture, and an Any CPU (Prefer 32-bit) application handles a missing x86 runtime correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- visualbasic
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100