[Problem/Bug]: Webview 131.0.2903.48 control panel entry mysteriousely disappeared

[orbitalfenestra]

What happened?

Just updated Webview2 this morning and I noticed that the control panel entry has vanished. Impossible to uninstall it from the control panel.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

131.0.2903.48

SDK Version

No response

Framework

Win32

Operating System

Windows 11

OS Version

24h2 (26100.2314)

Repro steps

Update webview2 to the latest version (I did with winget)

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

Previous version

[vbryh-msft]

Is your app able to pick it up? Could you please share installer logs?

[orbitalfenestra]

EdgeFiles.txt
EdgeRegistryMachine.txt
EdgeRegistryUser.txt
MicrosoftEdgeUpdate (2).log
MicrosoftEdgeUpdate.log
msedge_installer.log

Hope it can help!

Steps to reproduce:

From webview2 130.0.2849.80 do a winget update
Once at 131.xx.xx.xx.... entry in control panel is gone.

[orbitalfenestra]

For some reason on one of my machines (not all of them), I realised that also Edge has vanished from control panel. I had to go tweak the registry to make it visible again. That trick doesn't seem to work with Webview2 tho.

[ajtruckle]

Is your app able to pick it up? Could you please share installer logs?

You should tag this on my ticket where the issue of installer logs was raised.

[asjimene]

I can confirm this issue, when attempting to install WebView2 silently (using /silent /install), the ARP registry keys are not populated. Logs and a screenshot of the ARP registry key are included.
EdgeFiles.txt
EdgeRegistryMachine.txt
MicrosoftEdgeUpdate.log
msedge_installer.log

[orbitalfenestra]

I use this key as a SCCM detection. That's how I noticed. All softwares that require Webview2 will fail unless I change my detection method. I guess the best would be to wait to deploy this version everywhere?

[crian]

I have the same problem. After the webview update, it no longer appears in the windows settings -> apps. Reinstalling webview doesn't solve the problem either.

[aluhrs13]

Assuming WV2 is still working and the only delta is the visibility of installation, yes this is intentional - https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#announcement

@orbitalfenestra - For your SCCM purposes, we have our recommended installation detection method here - https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#detect-if-a-webview2-runtime-is-already-installed . Let me know if that doesn't work for your use-case.

[asjimene]

I'm sorry, why remove the Display name though? The proper, standard way of hiding an application from Add/Remove Programs is to set the SystemComponent registry value. This would prevent a breaking change for users and systems administrators while achieving the same effect.

https://learn.microsoft.com/en-us/windows/win32/msi/arpsystemcomponent

http://www.itninja.com/question/hide-in-add-remove-programs

This not only breaks standard detection methods, it also needlessly complicates software inventory collected by ConfigMgr and Intune for this application. I ask that you please reconsider this change and move to adding the SystemComponent registry value instead.

[MDawg957]

Assuming WV2 is still working and the only delta is the visibility of installation, yes this is intentional - https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#announcement

@orbitalfenestra - For your SCCM purposes, we have our recommended installation detection method here - https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution?tabs=dotnetcsharp#detect-if-a-webview2-runtime-is-already-installed . Let me know if that doesn't work for your use-case.

I was using the Installed Software.Product Name in MECM to create a collection based on the app. That's cut off and this alternate detection method is terrible for that. Is there some reason you can't just use the SystemComponent value that @asjimene references? It seems like the better option and wouldn't break everything like this non-standard change does.

[orbitalfenestra]

If it is the case, then will there be some kind of auto-update (like Edge) in SCCM possible ?

[aluhrs13]

Thanks for the feedback and details. We've paused the rollout of 131 at 5% and are revisiting our implementation to see if we missed this scenario.

[asjimene]

@aluhrs13 Looks like the latest 131.0.2903.63 has fixed this issue by adding the DisplayName back and utilizing SystemComponent. Thank you!

[orbitalfenestra]

I confirm it is working now.