[Crash] Fatal CLR error (80131506) previewing any SVG when WebView2 controller creation fails — initialization failure is silently ignored

Start with QuickLook.Plugin.HtmlViewer/WebpagePanel.cs and WebView_CoreWebView2InitializationCompleted, then trace how QuickLook.Plugin.ImageViewer/WebHandler.cs routes SVGs through SvgImagePanel and the ImageMagick fallback. Check how initialization failures are logged and how the existing RenderSvgWeb=false path works. Done means a failed WebView2 initialization is handled safely so SVG preview does not leave a broken control that can crash QuickLook.

Summary

QuickLook 4.5.0 kills the whole process when pressing Space on any .svg file, if WebView2 CoreWebView2Controller creation fails on the machine. The crash is a fatal CLR internal error (exit code 80131506) triggered by a NULL COM interface pointer marshaled from the half-initialized WebView2 window procedure. It is 100% reproducible for every SVG file on the affected machine.

WebpagePanel.WebView_CoreWebView2InitializationCompleted ignores e.IsSuccess == false completely (no logging, no disposal, no fallback), leaving a broken WebView2 WPF control in the visual tree whose subclassed window proc still receives messages.

Environment

• QuickLook 4.5.0 (both MSI install and Scoop zip build affected)
• Windows 11 24H2 (build 26100), .NET Framework 4.8 (clr.dll 4.8.9266.0)
• WebView2 Evergreen Runtime stuck at 100.0.1185.36 (April 2022) — while the bundled WebView2 SDK is 1.0.3912.50 (2025)
• RenderSvgWeb at its default (true) → .svg routed to SvgImagePanel (WebView2) instead of the ImageMagick fallback

Steps to reproduce

1. Have a WebView2 runtime whose CreateCoreWebView2ControllerAsync fails (in our case: severely outdated Evergreen runtime; the failure had been logged as COMException 0x80040404 E_ABORT repeatedly for months).
2. Press Space on any .svg in Explorer.
3. QuickLook.exe dies instantly. Other file previews stop working until it is restarted.

Crash signature

Event Log (Application Error 1000 + .NET Runtime 1023), identical across 3 crashes over 7 weeks:

Faulting module: clr.dll 4.8.9266.0
Exception code:  0xC0000005, offset 0x14EB0F
Exit code:       80131506 (fatal CLR error / ExecutionEngineException)

Full-dump analysis (WinDbg + SOS, crash on the main UI thread):

[HelperMethodFrame_1OBJ] System.StubHelpers.InterfaceMarshaler.ConvertToManaged(IntPtr, IntPtr, IntPtr, Int32)
DomainBoundILStubClass.IL_STUB_COMtoCLR(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
[ComMethodFrame]
[InlinedCallFrame]  MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
                    System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame)
                    System.Windows.Application.RunDispatcher(Object)
                    QuickLook.App.Main()
--- native frames above ---
user32!CallWindowProcW → EmbeddedBrowserWebView.dll (WebView2 window proc)

The faulting instruction is cmp qword ptr [rax+8], rcx with rax = 0: the COM→CLR marshal stub receives a NULL interface pointer returned from the broken WebView2 window procedure and the CLR dies dereferencing it.

Evidence that controller creation was already failing on this machine — QuickLook.Exception.log (unobserved task exceptions, rethrown by the finalizer):

========8/19/2026 20:09:23========   (and 9/1, 9/2 — 6 E_ABORT occurrences total)
System.AggregateException: A Task's exception(s) were not observed ...
---> System.Runtime.InteropServices.COMException: Operation aborted (Exception from HRESULT: 0x80040404 (E_ABORT))
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.<CreateCoreWebView2ControllerAsync>d__159.MoveNext()
   at Microsoft.Web.WebView2.Wpf.WebView2.<InitializeController>d__19.MoveNext()

Root cause

Two layers:

1. Machine-level: outdated WebView2 runtime → CreateCoreWebView2ControllerAsync aborts. (Fixed on our side by installing the current Evergreen runtime.)
2. QuickLook robustness bug: WebpagePanel.WebView_CoreWebView2InitializationCompleted (QuickLook.Plugin.HtmlViewer/WebpagePanel.cs) only acts when e.IsSuccess is true:

protected virtual void WebView_CoreWebView2InitializationCompleted(object sender, CoreWebView2InitializationCompletedEventArgs e)
{
    if (e.IsSuccess)
    {
        _webView.CoreWebView2.AddWebResourceRequestedFilter("*", CoreWebView2WebResourceContext.All);
        _webView.CoreWebView2.WebResourceRequested += WebView_WebResourceRequested;
    }
    // e.IsSuccess == false → silently ignored: no log, no dispose, no fallback
}

WebHandler.TryView has already replaced the ImageMagick render path with SvgImagePanel, so a failed WebView2 init leaves the user with a live-but-broken control that deterministically crashes the process on the next dispatched message.

Suggested fixes

1. In WebView_CoreWebView2InitializationCompleted, handle !e.IsSuccess: log via ProcessHelper.WriteLog, dispose the control, and surface a benign error placeholder instead of the dead control.
2. For ImageViewer specifically: on WebView2 init failure, fall back to the ImageMagick render path (the RenderSvgWeb=false branch already exists in WebHandler — reuse it).
3. Optionally: validate CoreWebView2Environment.GetAvailableBrowserVersionString() against the minimum runtime version required by the bundled SDK; reuse the existing CreateDownloadButton UI for "runtime too old" in addition to "runtime missing".

Workaround for affected users

Add to QuickLook.Plugin.ImageViewer.config (portable installs: %APPDATA%\pooi.moe\QuickLook\ or scoop persist dir):

<Settings>
  <RenderSvgWeb>False</RenderSvgWeb>
</Settings>

This restores SVG preview via ImageMagick rendering and stops the crash immediately. (Verified on the affected machine.)

---

Full crash dumps (QuickLook.exe.*.dmp, 3 files) are available if needed.