-
Notifications
You must be signed in to change notification settings - Fork 54
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
[Problem/Bug]: Evergreen Standalone installer fails when running during Operating System Deployment via SCCM #5032
Comments
Thanks for reporting the issue. Can you kindly share the installer logs - instructions here? |
Logs attached. There was no %localappdata% log. These are from a failure that occurred 1/6/2025 at 2:14:33 PM. |
SCCM has an option for applications to run the .exe as a 32-bit process on 64-bit systems. I turned this on and the install appears to work partially (I see the files/folders in C:\Program Files x86\Microsoft\EdgeWebView), however, the installer (MicrosoftEdgeWebView2RuntimeInstallerX64.exe) is now hanging open. The installation step on my test has been running for over 30 minutes so far. I suspect it will hit the timeout and fail. Hopefully this may help narrow down what the issue is. Edit: It did fail, but the installer reported an error (code 2147747665). It did not hit the SCCM timeout, but the error was at exactly an hour, so I'm guessing that might be an installer timeout. |
is deleting the key prior to install/update HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} supported? |
@jones948, couple of things:
|
I have the exact same issue described in this bug. |
Yes, the logs I shared correspond to the failure in SCCM at 2:14:33 PM. As mentioned in my original submission, you need an SCCM environment to reproduce this. The error only happens when you are installing the application as part of an Operating System Deployment task sequence. This is an automated process where the disk is erased, a clean OS installed, and applications installed before you boot into the full Windows environment. The "AppEnforce" log file included with my original post is SCCM's log file of the application install process during OSD. I have an additional piece of information. I noted above that SCCM can run installers as 32-bit processes on 64-bit systems. When I tested it, I thought it wasn't working. However, I was affected by this bug in my test application: ...where the order of the command line switches matter: /silent /install works, but /install /silent does not (which absolutely should not matter and should be fixed as well). I tried the 32-bit option again with the switches in the correct order and the webview2 application works correctly now. I'd still argue something changed in the installer that should be fixed, because no one is going to think about this 32-bit option as a workaround. |
I can confirm the issue in our SCCM environment. Tried it again yesterday with the WebView installer version 132.0.2957.115 but it still fails with the error code 4294967295 during deployment. |
We encountered the same issue using SCCM. We created an application to deploy using SCCM, which runs as the SYSTEM account locally from a subfolder of C:\Windows\ccmcache. We use the command line below. When SCCM executes on workstations, it exits with error code 4294967295. Log found in C:\ProgramData\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log seems to indicate the issue is an HTTPS call is blocked by the firewall. [Send][url=https://msedge.api.cdp.microsoft.com/api/v2/contents/Browser/namespaces/Default/names?action=batchupdates][request=[{"Product":"msedgewebview-stable-win-x64",,"OsArch":"x64","OsPlatform":"win","OsRegionDMA":false,"OsRegionName":"","OsRegionNation":"","OsVersion":"10.0.19045.5371","Priority":0,"Updater":"MicrosoftEdgeUpdate","UpdaterVersion":"1.3.195.43","WIPBranch":""}}]][filename=] Considering we specifically downloaded the Standalone installer to avoid these types of firewall issues, it seems like the Standalone "offline" Installer might need to be more "offline". |
We are also experiencing this issue. It seems intermittent - I have seen some SCCM Task Sequence builds complete, but most of the time it is currently failing. Logs show some sort of download issue, but like @ClairmontAle I think this should not be happening for an offline install...
To clarify, this appears to happen with the WebView2 Evergreen standalone installers for v132 and v133. We reverted to the v131 installer and are no longer seeing OSD/SCCM Task Sequence provisioning install failures for WebView2. |
A network call requirement from standalone sounds like a bug. @apiontek/ @ClairmontAle Also please share a full set of logs. That would be really helpful. |
@ParadoxZero I can't post full logs publicly without sanitizing manually due to the nature of our environment, so prefer not to post logs, but I can confirm I downloaded the setup from the "Evergreen Standalone Installer" section as you have circled above. I should also point out this happens via SCCM application deployment as well, not only when running from a Task Sequence. |
I have also downloaded the standalone installer and we're seeing the same behaviour. I have been working around this issue by using a package/program in configmgr instead of an application. The issue has been that this would work up until a new version of Webview2 was released, at that point it would start trying to auto update during the task sequence causing it to fail. I've even tried writing the relevant reg keys for the GPOs to disable Webview2 updates at the start of the task sequence and although you can see the settings are honoured in the edge updater log it STILL tries to update. I noticed there was a new version released last night and for the first time since this issue started the penultimate version is still installing successfully (as a package/program) possibly something has been changed in the penultimate version in relation to this issue? |
@ParadoxZero - yes, I confirm that is the installer we are using, downloaded from the x64 link where you have circled. I have the same log sanitation needs @ClairmontAle mentioned but if necessary I could work to reproduce the issue again, collect logs and sanitize them. It will take some time & effort, however, so it would be good to know if the issue has already been fixed. Presumably the standalone installer should just not be trying to update at all. It should just install the version it has and leave potential updating for later. |
I downloaded the latest "Evergreen Standalone Installer" 64-bit a few hours ago, v133.0.3065.59 to be exact. Added to SCCM and deployed to a workstation, I can see from the SCCM logs that it executes, runs for about 40 seconds, then returns exit code "-1" or "4294967295". I had Process Monitor running during this attempt and noticed it simply creates a temp file under "C:\Program Files (x86)\Microsoft\Temp", then reads through the entire "MicrosoftEdgeWebView2RuntimeInstallerX64.exe", then it deletes the *.tmp file it created and the thread exits. It doesn't write to any *.log at any point. So realistically, there is no log file to provide. Here's the relevant portion of the SCCM log: +++ Starting Install enforcement for App DT "WebView2 Runtime v133.0.3065.59" ApplicationDeliveryType - ScopeId_A264/DeploymentType_d625, Revision - 1, ContentPath - C:\WINDOWS\ccmcache\cr, Execution Context - System AppEnforce 2025-02-12 16:42:09 10012 (0x271C) |
What happened?
I have the Evergreen Standalone installer packaged as an application in SCCM and included to be installed when I'm re-imaging a computer. The installer is failing with exit code 4294967295. This is happening with the latest installer downloaded from the WebView2 installer page.
I reverted my application to use an older installer (91.0.864.37) and it installs fine during imaging, which makes me think something has changed with the newer installer.
I'm installing it during imaging because other applications later in the imaging process require it (ArcGIS Pro, Camtasia, etc.) and will fail if it is not present.
This is the log of the install process that generates the error:
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
No response
SDK Version
No response
Framework
Win32
Operating System
Windows 10
OS Version
10.0.19045
Repro steps
You would need an SCCM environment to reproduce this, as it seems to only happen during Operating System Deployment.
Package the WebView2 Runtime as a application with "/install /silent" switches.
Include the application as an Install Application step in the OSD task sequence.
Application install fails with the mentioned error.
When the error happens, I can bring up a diagnostic command prompt while the Task Sequence is in the error state, go to the cache where the WebView2 installer .exe is located, and run the same command manually, and it will work. So the error is specific to being called via SCCM's application install step.
MicrosoftEdgeWebView2RuntimeInstallerX64.exe /install /silent
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
Runtime 91.0.864.37 is the newest installer I had on hand to test with. It likely was working in a newer version than that.
The text was updated successfully, but these errors were encountered: