New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebView2 Runtime does not install correctly #2030
Comments
I have the same problem. |
I have just come across this issue. The registry key is no longer being created. I tested this by uninstalling my existing webview2 runtime, then re installing using both the evergreen bootstrapper and evergreen Standalone. |
💯 same issue |
Hey all - thanks for reporting this issue. I know we just made some changes to allow for installing without elevation, but I'm not sure exactly when that shipped or in what version of the installer. @liminzhu do you have any info you can share? Otherwise I think we may have an installation bug when not elevated. |
If it helps.... I've written a workaround so that we launch the installer with elevated privileges. If you don't do that, the regkeys are not created as per the documentation. |
After getting some feedback around running without elevation, we recently updated our installer to install WebView2 Runtime per-user if run without elevation (previously it'd prompt or fail), and per-machine with elevation. If you run with elevation, the per-machine installation shows up in the HKLM regkey location in our docs. If run without elevation, the per-user installation shows up in the corresponding HKCU location. With the new change, developer can check both the HKLM and HKCU location before attempting an installation, or what do they used to do, which is checking HKLM and trigger an installation w/ elevation if no HKLM regkey, which will put the per-machine runtime on the box. Sorry our docs haven't been updated yet and I will make sure our docs reflect that! |
Thanks Limin! To be explicit, this is the key that gets written when it's installed per-user: |
This issue requires quick resolution as its really confusing for the user - to investigate this basic installation check. Just got stuck on this problem over hours now. |
hey @geekykant, our docs have been updated to include how per-user or per-machine installation works and what regkeys you need to check. Let me know if you're confused about anything. https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#deploying-the-evergreen-webview2-runtime |
Same problem here. |
After uninstalling the WebView2 runtime, if we install it again without elevation it gets installed and the registry keys are created in the corresponding HKCU location. |
Hey @hakzhyena - What framework are you using to build you app and host the WebView2? The HKCU runtime doesn't work with WinUI2/UWP WebView2 which might be what you are running into. |
Hi @champnic , please ignore my previous comment. I had missed to update the logic to look for path in HKCU for the first parameter (browserExecutableFolder); after doing that CreateCoreWebView2EnvironmentWithOptions is successful and the webpage is loading as expected. |
@champnic I guess UWP isolates registry access, because I had also issues with not being able to load WebView2 from within UWP. Is it only the registry isolation that is problematic or are there other bottlenecks too? We would like to install our application using the Microsoft Store, but most of our end-user don't have administrator access. So we have an issue with the WebView2 runtime installation for UWP apps. What is the recommended approach to fix this? |
@ramondeklein It's the registry and the actual install location of the user-level runtime. We are doing two things to fix this. 1) We are looking into fixing the permissions of the user-level install location to make sure it's accessible by UWPs, and 2) we are currently pushing out the system-level WebView2 runtime to Windows 10 devices which UWP apps will have access to - rollout is in stages, so you might not see this available right away. |
@champnic just to get this clear, once a system-level WebView2 is deployed one wouldn't need to deal with WebView2 installation at all? and this is supposed to be rolled out for all windows devices? |
Yes (unless the user mucks with the installation on their machine) - once the system-level WebView2 Runtime is on the machine, it will keep itself up to date and is usable by all WebView2 apps. Here's some info on the Win10 runtime rollout: |
I had the same problem, (error 0x80000003 when installing webview2). |
We have a problem, that the installation of the webview is kind of arbitrary when integrated in our setup and that setup is installed elevated. |
We just released our UWP Webview2 app to the store and we are now experiencing the same issue. This is very bad experience and communications. |
@mnasers Can you add some detail on what issue you are hitting? Is your app trying to deploy the WebView2 runtime itself? |
@champnic No we are not trying to deploy the WebView2 runtime. AFAIK, this is not possible for UWP apps that use MSIX. When certain Windows10 users attempt to launch our app after updating, they are presented the following screen instructing them that the WebView2 runtime needs to be installed along with a link. After downloading and installing the runtime, users are still not able to open our application and they are presented with the same screen. As mentioned by @ChateauLaFite , the necessary registry entry was missing. Attempting to install the runtime with admin rights solves the issue. |
@mnasers Using the link to download unfortunately defaulted to downloading the per-user version (if it wasn't run elevated). We had a bug that the UWP apps didn't have permissions to access the per-user install, but that should have been fixed about a month ago. If you still have it available, can you see what version of the per-user runtime was installed? If the per-machine/elevated runtime was installed, I believe that removes the per-user install though. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@champnic What difference does it make which version is being installed. The end result is the same. |
It matters because we put in a fix into one version. If you share the runtime version we can confirm either 1) That you are using a version without the fix and the issue is expected, with the workaround being to get a newer version or figure out where the older version came from, or 2) That you are using a version with the fix, but the fix is not working as expected, or there is another issue occurring. |
@maribeiroleya For that particular machine, it looks like it's missing the WebView2 runtime. For the app in general, it should try and verify that the runtime is available, and potentially install it if it isn't on the machine yet: |
@champnic thanks for yout response. I try to verify if the machine have WebView2 runtime installed. My app is a react-native app and winrt/c++. I not found a way to verify this. I cannot access to regedit in a winrt/c++ app. Can you help me to get another way to verify this? |
Typically it's the installer that would check for the presence of the WebView2 Runtime, and install it if it's not on the machine yet. Alternatively the users can follow the instructions that are presented in your screenshot and install the runtime themselves. |
This should be generally fixed now. |
Runtime installer at https://go.microsoft.com/fwlink/p/?LinkId=2124703
It did not create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
It did not inform me that it did not install correctly, nor did it prompt for elevation. I am a local Administrator.
WebView2.EnsureCoreWebView2Async() threw a file not found exception until the Runtime was explicitly installed as Administrator.
Explicitly launching the WebView2 Runtime installer as Administrator did create the registry key and the WebView2 control did subsequently work. Deleting the above registry key after installation as Administrator results in successful instantiation of the WebView2 control (and its CoreWebView2), so the presence of the registry key is not required for the WebView2 control to determine if the WebView2 runtime is installed, contradicting the text "If this regkey doesn't exist, or if exists and is null or an empty string, this means that the WebView2 Runtime is not installed on the client." on the page https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution.
So, to resolve:
WebView2 Runtime installer needs to inform the user if it did not install correctly.
WebView2 Runtime installer did not create the above registry key unless explicitly run as Administrator, and presumably did not install some files. See paragraph 5.
WebView2.EnsureCoreWebView2Async() throws a file not found exception with a null filename, not because the registry key does not exist, but because some required files were not installed (?). The exception does not reveal which file could not be found.
Documentation of how to check if the WebView2 Runtime is installed is incorrect. Presence or absence of registry key doesn't cut it. See paragraph 5.
Attempting to instantiate a WebView2 control in a UWP app (in this case) shows the MessageBox: "Windows cannot access the specified device, path or file. You may not have appropriate permissions to access the item." I can't tell what the item is as the full path is set as the Title of the MessageBox only, and it is not in the MessageBox text, it is truncated, and MessageBox windows are not resizable. This error perhaps can be prevented by specific initialisation options which I have not yet tried.
Multiple entries for Microsoft Edge WebView2 Runtime v96.0.1054.57 are displayed in Windows Programs and Features. Uninstalling one of them seems to work, but attempting to uninstall others entries seemingly does nothing. The WebView2 control does successfully get instantiated at this point. Rebooting the PC does not remove additional entries for WebView2 Runtime from Programs & Features and they (it) can still not be uninstalled. The WebView2 control does successfully get instantiated at this point.
Doc Update: AB#37615931AB#37743143
The text was updated successfully, but these errors were encountered: