[Crash] Fatal CLR error (80131506) previewing any SVG when WebView2 controller creation fails — initialization failure is silently ignored
Los mantenedores suelen responder en 4 días
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.dll4.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)
RenderSvgWebat its default (true) →.svgrouted toSvgImagePanel(WebView2) instead of the ImageMagick fallback
Steps to reproduce
- Have a WebView2 runtime whose
CreateCoreWebView2ControllerAsyncfails (in our case: severely outdated Evergreen runtime; the failure had been logged asCOMException 0x80040404 E_ABORTrepeatedly for months). - Press Space on any
.svgin Explorer. - 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:
- Machine-level: outdated WebView2 runtime →
CreateCoreWebView2ControllerAsyncaborts. (Fixed on our side by installing the current Evergreen runtime.) - QuickLook robustness bug:
WebpagePanel.WebView_CoreWebView2InitializationCompleted(QuickLook.Plugin.HtmlViewer/WebpagePanel.cs) only acts whene.IsSuccessis 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
- In
WebView_CoreWebView2InitializationCompleted, handle!e.IsSuccess: log viaProcessHelper.WriteLog, dispose the control, and surface a benign error placeholder instead of the dead control. - For
ImageViewerspecifically: on WebView2 init failure, fall back to the ImageMagick render path (theRenderSvgWeb=falsebranch already exists inWebHandler— reuse it). - Optionally: validate
CoreWebView2Environment.GetAvailableBrowserVersionString()against the minimum runtime version required by the bundled SDK; reuse the existingCreateDownloadButtonUI 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.
- Lenguaje dominante
- C#
- Estrellas
- 25.7k
- Forks
- 1.4k
- Merge medio
- 4 d 8 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de QL-Win/QuickLook
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
QL-Win/QuickLook#2028 · 3 comentarios ·
Los mantenedores suelen responder en 4 días
-
[Bug] If the first character entered into the search box is a space, the preview window will close.Posiblemente ocupada @MORTEM3845 la tomó hace 14 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 48/100
QL-Win/QuickLook#2056 · 1 comentario ·
Los mantenedores suelen responder en 4 días
-
WebView2 panels become permanently unavailable until restart (shared UDF + incompatible AdditionalBrowserArguments)Posiblemente ocupada @Henglie la tomó hoy. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
Los mantenedores suelen responder en 4 días
Todos los issues de QL-Win/QuickLook
Issues similares
-
needs-triage
Dificultad 1/5 1-3 horas Aptitud para principiantes 76/100
Azure/azure-sdk-for-net#64658 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dotnet/aspnetcore#70370 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
NethermindEth/nethermind#15684 ·
Los mantenedores suelen responder en 1 día
-
area/ai-assistant squad/flyt
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Altinn/altinn-studio#21798 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
SubtitleEdit/subtitleedit#16699 ·
Los mantenedores suelen responder en 1 día