EmbeddedBrowserWebView.dll calls CoReleaseServerProcess during instance cleanup, resulting in corrupted COM initialization for EXE-server

[pontusn]

What happened?

Our application embed WebView2 for multiple purposes, one is to handle an HTML-based login-dialog.

This dialog is displayed during initialization, after COM-objects have been registered, but before any APIs are available to external clients.

Starting with WebView2 v120 we have now identified that COM-objects provided by the EXE itself are not available,

The root cause seems to be calls to CoReleaseServerProcess when the WebView2 instance hosted in our login-dialog is cleaned up. The call effectively suspend all registered COM-objects via an implict call to CoSuspendClassObjects, resulting in various application errors at later stages.

Expected:
External DLLs (such as WebView2-integration) loaded by host process should not affect COM-state.

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

120.9.2210.61

SDK Version

1.0.2151.40

Framework

Win32

Operating System

Windows 10, Windows 11

OS Version

No response

Repro steps

1. Register EXE-level objects via _Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE)
2. Create, display and destroy dialog the host WebView2 using Win32/COM
3. Try to use previously registered COM-objects via CoCreateInstanance

Result:

• Externally creatable object will result in a new main process, which also fail due to login-dialog
• Objects that are only available within the process will result in COM-level errors (Class not registered)

Repros in Edge Browser

No

Regression

Regression in newer Runtime

Last working version (if regression)

119.x

AB#48130619

[pontusn]

Known workarounds

• Use CoResumeClassObjects to revert suspended state
• Avoid unloading instances of WebView2 during application startup
• Use separate explicit registration of in-proc COM-objects via _Module.RegisterClassObjects(CLSCTX_INPROC_SERVER, REGCLS_MULTIPLEUSE)

All workarounds will require us to build and distribute a new version of our application to all users.

[xMRi]

We see the same issue.

After destroying an wv2 window our current class factories for the main thread can't be accessed.
The next access to any class factory to create a COM object blocks.
The IMessageFilter is called and the corresponding "Server busy" dialog pops up.
We see this in all version of our software. Even we can influence and inject an DLL, we are not able to inject any code directly after the wv2 windows was destroyed to call CoResumeClassObjects.

We see currently 10 affected installations with nearly 500 users continual rising.
This is very urgent.

We can redirect the installation to call build 119 via
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Edge\WebView2\BrowserExecutableFolder
but due to the fact that the WebView2 can't be called from the network, all affected clients must install the build 119 into a private local folder.

[vbryh-msft]

Sorry, you are hitting this. We have merged the fix - it should be in Canary tomorrow. Will update with the version number, when we will have it.

[monica-ch]

This is fixed in Edge Canary 121.0.2277.0+. Can someone validate and confirm that the fix is working.

https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/set-preview-channel

[pontusn]

My 30 seconds smoke test using our software without mitigations and Edge Canary 121.0.277.0 confirms that the problem is fixed in current build.

When can we expect the fix in WebView2 120.*?

[DanielHWe]

I can also confirm that Edge Canary 121.0.277.0 fixes the issue. As several thousand of our customers may be affected, we are also requesting an update of 120.*, which will be rolled out via updates.

[fabiorocha]

Thanks for validating the fix folks. The fix was backported to 120.*, which should start rolling out today and reach 100% over the next 48 hours.

[DanielHWe]

Is Version 120.0.2210.77 including the fix?

[fabiorocha]

@DanielHWe that's correct. Please give it a try and let us know if you still see the issue. Thanks!

[DanielHWe]

@fabiorocha I can confirm 120.0.2210.77 fixed the issue for us.

[xMRi]

Edge has been updated.
My Evergreen WebView2 still shows the buggy version: 120.0.2210.61

[ooer]

I can confirm 120.0.2210.77 fixed the issue for us too.

[rgoodman1977]

I installed the new version. WebView2 is still using the older version that doesn't work

[monica-ch]

@xMRi @rgoodman1977 WebView2 rollout schedule is slower compared to Edge, do watch out for the latest WV2 evergreen that gets updated soon

[fabiorocha]

@xMRi @rgoodman1977 As @monica-ch said, WebView2 updates rollout over a 48-hour window, which is slower than the browser rollout window. This is because WebView2 has less usage in early release channels (Canary/Dev/Beta), so its Stable rollout is slower for us to be able identify issues early and have enough time to react and pause rollout, if needed.

If your apps have some sort of test coverage/infrastructure -- might be worth thinking about integrating WebView2 Canary/Dev into that, so that issues like these can be caught for your apps before they reach Stable for your customers. Internally, we'll conduct a postmortem to avoid issues like this in the future as well.

[pontusn]

We have now confirmed that builds without mitigations work with WebView2 120.0.2210.77

[xMRi]

I can confirm that evergreen pulls now the fixed 120.0.2210.77. Works again!

[ooer]

I can also confirm that evergreen pulls now the fixed 120.0.2210.77 and it works.