WebView2Install /silent /install - no easy way to wait, crashing consuming applications

[g466a]

Description The WebView2 Installers (Bootstrapper+Standalone) exit too early, when run with /silent /install from another installer. There is no easy way for a parent installer to correctly wait until the installation finishes. Our Installer starts the WebView2 Consuming Application (Outlook.exe) immediately after the installation, causing Outlook.exe to have Access Violations and this even corrupts WebView2/Edge Data directories sometimes. We must support Windows 7 to Windows 10, so we expect that we will always need to include WebView2 in our installer. We do not want to deploy fixed versions along with our application since that would be too difficult/inappropriate.

If we manually install WebView2 to ensure the installation finishes before the Consuming Application (Outlook.exe) starts, then everything works fine.

Version Public Installer Versions avaiable as of 01-June-2021 from https://developer.microsoft.com/de-de/microsoft-edge/webview2/ Installers that we are interested in: Bootstrapper (prefered) Standalone Installer

Repro Steps

• start a VM/physical Windows 10 machine without any webview2 components installed
• Download any mentioned installer from https://developer.microsoft.com/de-de/microsoft-edge/webview2/
• start a cmd.exe, (admin or not -> same behaviour)
• run the installer, XXX.exe /silent /install
• check with process explorer / task manager to see when the installation finishes
• check when the installer exits in cmd.exe

Expected behaviour

• the main setup.exe exits AFTER the installation is complete
• so the parent process can simply wait for main setup.exe to complete

Actual behaviour

• the main setup.exe exits IMMEDIATELY, leaving no chance for the caller to wait for the finished webview2 installation
• the actual installation continues in background and takes some time to finish
• there seem to be multiple subprocesses having different names, depending on type of installer and platform

In our scenario this even means:

• Our installer does not wait until WebView2 installation is finished and starts consuming processes too early, while WebView2 installation is still running.
• This sometimes crashes Outlook (our Consumer) with Access Violation and may leave the WebView2 data dir "corrupted", because it has been created by a "partial installation" of WebView2.

Additional context Our Scenario:

• We use WebView2 from a COM Addin in Outlook, using C# and netoffice
• We are hosting an Outlook Web Addin inside this WebView2 to work via COM with a Desktop Outlook. (So we can use the same addin for web and Desktop)
• Beside this problem everything works like a charm (almost ;)
• We have created an installer which runs WebView2 setup (currently the evergreen bootstrapper)
• We do not want to have the fixed version installer, really not.
• There is no /wait parameter in the documentation resp. I did not find any hint how to solve this problem.
• I would expected the installer in general to wait or at least to have a documentented /wait parameter
• Waiting for process tree cannot be the solution, its also nearly impossible in plain C#, needing to either use PInvoke to call the Win32 API or to use tricks like WMI or PerformanceCounter to find parent/child relations.

AB#44876475

[champnic]

Thanks for the report @g466a - I'll follow up with our installer team to see what the intended behavior is here and if there's a workaround.

[champnic]

@g466a The installers should wait for completion before exiting, even when run silently.

Can you try the following? • uninstall WebView2 Runtime for clean state • rerun the silent install in an admin cmd • observe whether Webview2Setup.exe is exiting right away • observe if the exit code is 0 for success (echo %errorlevel%) or non-zero for failure • observe whether WebView2 Runtime was installed • if any failures or anything looked off, try just running the Webview2Setup.exe from admin cmd without any additional args if anything is different.

Afterwards, could you share these logs? %ALLUSERSPROFILE%\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log %LOCALAPPDATA%\Temp\msedge_installer.log %systemroot%\Temp\msedge_installer.log

Thanks!

[g466a]

Ok, here is what I did:

• I reset my test vm to a state where it has never seen WebView2
• FYI: This Windows 10 is up-to-date has recently been installed via offical Microsoft ISO in HyperV
• I download the current Evergreen Bootstrapper to the Desktop of my vm
• I open a administrator command box in that folder
• I run MicrosoftEdgeWebview2Setup.exe /silent /install
• this exits immediately with exit code 0
• I took a screenshot approx. 3 seconds after I started MicrosoftEdgeWebview2Setup.exe
• the installer runs for about 20-30 Seconds (Screenshot: Processes are visible in Task Manager)
• after that everything is installed correctly and works as expected

To me it seems as if the the installer simply does not wait...

appdata_msedge_installer.log MicrosoftEdgeUpdate.log windows_temp_msedge_installer.log

[champnic]

Thanks a lot for the information! We were able to repro the issue and are digging in. In the meantime, one possible solution is to wait for this Clients key to not be null or empty: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}\pv

https://microsoft.visualstudio.com/Edge/_wiki/wikis/Edge.wiki/5492/Detecting-Microsoft-Edge-(Chromium-based)-aka-Anaheim-installed-channels?anchor=channel-keys

[g466a]

Glad to help and thanks for the information - the provided workaround will save us A LOT of trouble with our testers... Thanks a lot!

[suprnova74]

A workaround I've found is to use start.exe to truly wait. if running from a non .cmd file (i.e powershell, vbscript, etc) it would be: cmd /c start.exe "install" /wait "fullpathtoyourinstaller.exe" /silent /install.

This waited ~15-20 seconds before returning whereas running it directly returned immediately.

Some installations such as Autodesk DWG Trueview behave similarly, but they added a /sms switch so the initial .exe waits for all spawned processes to accommodate similary. Not sure how feasible that is to do for this installer.

[fvanheeswijk]

We are also experiencing this problem in our WiX installer, unfortunately there is not really a way to wait on it with a start.exe call while it is still embedded in the .msi...

When can we expect a fix?

[champnic]

Added this to our backlog. I wouldn't wait for a fix here though. It will lower priority given the runtime has now been pushed to nearly all Win10 devices and is inbox on Win11 (and Win 7/8/8.1 is no longer supported).

[NJullienSweet]

A workaround I've found is to use start.exe to truly wait. if running from a non .cmd file (i.e powershell, vbscript, etc) it would be: cmd /c start.exe "install" /wait "fullpathtoyourinstaller.exe" /silent /install.

This waited ~15-20 seconds before returning whereas running it directly returned immediately.

Some installations such as Autodesk DWG Trueview behave similarly, but they added a /sms switch so the initial .exe waits for all spawned processes to accommodate similary. Not sure how feasible that is to do for this installer.

I came up with the same solution, but with Powershell's Start-Process which I find more readable:

Start-Process "<PathHere>/MicrosoftEdgeWebview2Setup.exe" -ArgumentList "/silent","/install" -Wait