CoreWebView2Environment.BrowserProcessExited Event

Definition

Namespace:

Microsoft.Web.WebView2.Core

Assembly:

Microsoft.Web.WebView2.Core.dll

Package:

Microsoft.Web.WebView2 v1.0.2849.39

BrowserProcessExited is raised when the collection of WebView2 Runtime processes for the browser process of this CoreWebView2Environment terminate due to browser process failure or normal shutdown (for example, when all associated WebViews are closed), after all resources have been released (including the user data folder).

public event EventHandler<Microsoft.Web.WebView2.Core.CoreWebView2BrowserProcessExitedEventArgs> BrowserProcessExited;

member this.BrowserProcessExited : EventHandler<Microsoft.Web.WebView2.Core.CoreWebView2BrowserProcessExitedEventArgs> 

Public Custom Event BrowserProcessExited As EventHandler(Of CoreWebView2BrowserProcessExitedEventArgs) 

Event Type

EventHandler<CoreWebView2BrowserProcessExitedEventArgs>

Examples

private bool shouldAttemptReinitOnBrowserExit = false;

void Environment_BrowserProcessExited(object sender, CoreWebView2BrowserProcessExitedEventArgs e)
{
    // Let ProcessFailed handler take care of process failure.
    if (e.BrowserProcessExitKind == CoreWebView2BrowserProcessExitKind.Failed)
    {
        return;
    }
    if (shouldAttemptReinitOnBrowserExit)
    {
        shouldAttemptReinitOnBrowserExit = false;
        _webViewEnvironment = null;
        _ = ReinitializeWebView(_useCompositionControl);
    }
}

Remarks

Multiple app processes can share a browser process by creating their webviews from a CoreWebView2Environment with the same user data folder. When the entire collection of WebView2Runtime processes for the browser process exit, all associated CoreWebView2Environment objects receive the BrowserProcessExited event. Multiple processes sharing the same browser process need to coordinate their use of the shared user data folder to avoid race conditions and unnecessary waits. For example, one process should not clear the user data folder at the same time that another process recovers from a crash by recreating its WebView controls; one process should not block waiting for the event if other app processes are using the same browser process (the browser process will not exit until those other processes have closed their webviews too).

Note this is an event from @CoreWebView2Environment, not @CoreWebView2. The difference between BrowserProcessExited and ProcessFailed is that BrowserProcessExited is raised for any browser process exit (expected or unexpected, after all associated processes have exited too), while ProcessFailed is raised for unexpected process exits of any kind (browser, render, GPU, and all other types), or for main frame render process unresponsiveness. To learn more about the WebView2 Process Model, go to Process model.

In the case the browser process crashes, both BrowserProcessExited and ProcessFailed events are raised, but the order is not guaranteed. These events are intended for different scenarios. It is up to the app to coordinate the handlers so they do not try to perform reliability recovery while also trying to move to a new WebView2 Runtime version or remove the user data folder.