Handle msedgewebview2.exe Exception code: 0xe0000008

Question

After many hours of running on a 10" monitor PC, a rather basic Javascript injection webpage client UWP application fails with an exception that crashes the app, this exception not being caught by Application.UnhandledException:

    public App()
    {
        this.InitializeComponent();
        this.Suspending += OnSuspending;
        UnhandledException += async (sender, e) =>
        {
            e.Handled = true;

            ContentDialog unhandledExceptionDialog = new ContentDialog()
            {
                Title = e.Exception.GetType().Name,
                Content = e.Message,
                CloseButtonText = "Close/Fermer"
            };
            await unhandledExceptionDialog.ShowAsync();
        };
    }

Looking under Windows Event Viewer shows the following information:

Faulting application name: msedgewebview2.exe, version: 100.0.1185.29, time stamp: 0x6245ceb8 Faulting module name: KERNELBASE.dll, version: 10.0.17763.2452, time stamp: 0xad1c2e55 Exception code: 0xe0000008 Fault offset: 0x0000000000039319 Faulting process id: 0x1d38 Faulting application start time: 0x01d849ec159aa7e6 Faulting application path: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\100.0.1185.29\msedgewebview2.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 584ec720-9e16-43a1-85e2-210d26be7a0b Faulting package full name: Mecalink_1.0.8.0_x64__5vx274t353zgg

I haven't found much on the topic of msedgewebview2.exe exception code 0xe0000008. Apparently this would mean unknown software exception, possibly due to a lack of virtual memory? Is that correct? For the moment, looking at Task Manager, memory usage is stable through time, which would seem to invalidate the hypothesis of garbage collection problems' being the cause.

How to confirm that the application is the problem, especially seeing that this is due to the Microsoft Edge Runtime? Is there a way to handle exceptions once the webview crashes? Could it be that continuous 100ms Javascript injections through

    private async void Timer_Elapsed(object sender, ElapsedEventArgs e)
    {
        // Injection continues without removing the timer, because changing page in the app adds inputs that must have handlers
        await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, async () =>
        {
            string functionsToInject =
                @"document.addInputHandlers = function() {
                     ...
                     chrome.webview.postMessage('...');
                     ...
                  }
                  document.addInputHandlers();
                  ...";
            _ = await wv2.CoreWebView2.ExecuteScriptAsync(functionsToInject);
        });
    }

eventually overwhelm the runtime? Is there a way to programmatically emulate such a crash? (Since this has happened at night after many hours of running, the problem is really creating a reproducible example.)

Note: another answer suggests that KERNELBASE.dll is simply the messenger of an exception actually caused by the application. Is it possible that there be other unhandled exceptions on a thread somewhere? If that were the case, I don't see why msedgewebview2.exe is being singled out as the culprit.

Answer 1

The fact that you're using a timer to include scripts looks suspicious to me and might cause the issue (because it continues to inject the script).

WebView2 has a method to do that: AddScriptToExecuteOnDocumentCreatedAsync. It adds the script (once) to every page you visit.

See this: AddScriptToExecuteOnDocumentCreatedAsync

Now the script will only be added once - on every page.

It will be added again, when you refresh the page (with F5 or in code), so you still don't need a timer.

Add the script once with AddScriptToExecuteOnDocumentCreatedAsync and then use the timer to run the script:

_ = await wv2.CoreWebView2.ExecuteScriptAsync("document.addInputHandlers()");

Now you will only have one script in memory.

However, I don't think, you should not use 100ms as interval, that will only cause flicker, if you try to update that often and the server might not be able to process requests in that time.