[Problem/Bug]: Runtime 153.0.4234.32 — renderer main thread permanently blocked in WebGPU command-buffer wait while GPU process is idle (page freezes, no hang reported to host)

What happened?

Environment

WebView2 Runtime: 153.0.4234.32 (Evergreen; auto-installed 2026-09-16, previous version removed by the update so we could not diff)
OS: Windows 11 Pro 10.0.26200 (KB5129195 applied 2026-09-19)
GPU: NVIDIA GeForce GTX 4090
Host: Tauri 2.11.5 (wry 0.55.1, tao 0.35.3, webview2-com 0.38.2), HWND-based controller (CreateCoreWebView2Controller, not Composition mode), single frameless window, default WebView2 settings, no ScriptDialogOpening handler, no NewWindowRequested deferral
Page: React app whose canvas uses PixiJS 8.20.1 with the WebGPU renderer (WebGL2 fallback disabled). Presentation is a normal requestAnimationFrame loop; the freeze also occurs before the first frame is presented (see capture 3).

Symptoms

The page becomes completely unresponsive: no pointer or keyboard input, Ctrl+R / Ctrl+Shift+R / F12 do nothing, the visible content stays frozen at the last frame. The host window is not reported as hung (IsHungAppWindow = false, SendMessageTimeout succeeds) because the host UI thread and the WebView2 browser UI thread keep pumping. The only recovery is terminating the process tree. It reproduces within seconds to minutes of page load; four occurrences were captured on 2026-09-19 (JST 03:14, 12:41, 13:35, 13:44). It started after the runtime updated to 153; the app and GPU driver were unchanged.

What the process tree looks like during a freeze (captured with GetThreadContext + stack-walk + GetThreadDescription, no symbols; offsets are relative to msedge.dll 153.0.4234.32 x64)
Renderer --type=renderer, thread CrRendererMain — 0 ms CPU for the duration, parked in:

ntdll!NtWaitForAlertByThreadId
ntdll!RtlSleepConditionVariableSRW
msedge.dll+0xB201DA (base::ConditionVariable::Wait)
msedge.dll+0x36B16B4 (mojo sync wait — WaitSet)
msedge.dll+0x1F14A49
msedge.dll+0x7A93810 (task runner)

base::Location/interface-name string pointers live on that stack region: gpu\command_buffer\client\webgpu_implementation.cc and gpu.mojom.CommandBufferClient, i.e. the renderer is inside the WebGPU client's synchronous command-buffer wait (CommandBufferProxyImpl::WaitForGetOffsetInRange / WaitForTokenInRange) and the reply never arrives. Identical stack in all four captures.

Renderer, all other threads — idle (ThreadPoolForegroundWorker × N in WorkerThread::RunWorker wait, Chrome_ChildIOThread in GetQueuedCompletionStatus). Exception in capture 2: Compositor thread at 100 % of one core for 6,367 s (accumulating ~1 s/s), executing a tight loop in a function whose rip-relative references are the lambda name cc::Scheduler::FinishImplFrame()::(lambda)… and the trace-argument literals is_waiting_on_main, has_pending_tree, DidNotSubmitInLastFrame — consistent with cc::Scheduler::ProcessScheduledActions() never returning to its message loop while the state machine reports "waiting on main". In the other three captures the compositor thread was idle.

GPU process --type=gpu-process — idle: CrGpuMain in NtUserMsgWaitForMultipleObjectsEx (2.25 s total CPU over 6.5 h of process life in capture 2; 0–31 ms per 5 s during freezes), VizCompositorThread idle, GpuVSyncThread in WaitForVerticalBlankEvent, all ~45 NVIDIA D3D12 UMD worker threads (nvwgf2umx.dll) and D3D12Core threads in ordinary idle waits. No thread stuck in a driver call; no context-lost/crash event (ProcessFailed was not observed; no WER/Application-Error events).GPU process --type=gpu-process — idle: CrGpuMain in NtUserMsgWaitForMultipleObjectsEx (2.25 s total CPU over 6.5 h of process life in capture 2; 0–31 ms per 5 s during freezes), VizCompositorThread idle, GpuVSyncThread in WaitForVerticalBlankEvent, all ~45 NVIDIA D3D12 UMD worker threads (nvwgf2umx.dll) and D3D12Core threads in ordinary idle waits. No thread stuck in a driver call; no context-lost/crash event (ProcessFailed was not observed; no WER/Application-Error events).

Importance

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

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

153.0.4234.32

SDK Version

1.0.3650.58

Framework

Win32

Operating System

Windows 11

OS Version

10.0.26200 (KB5129195 applied 2026-09-19)

Repro steps

Framework: Win32 — the WebView2 is created with CreateCoreWebView2Controller on an HWND (not Composition mode, not WinUI/WPF/WinForms). Host is Tauri 2.11.5 / wry 0.55.1 / tao 0.35.3 (Rust).

Symptoms

The page becomes completely unresponsive: no pointer or keyboard input, Ctrl+R / Ctrl+Shift+R / F12 do nothing, the visible content stays frozen at the last frame. The host window is not reported as hung (IsHungAppWindow = false, SendMessageTimeout succeeds) because the host UI thread and the WebView2 browser UI thread keep pumping. The only recovery is terminating the process tree. It reproduces within seconds to minutes of page load; four occurrences were captured on 2026-09-19 (JST 03:14, 12:41, 13:35, 13:44). It started after the runtime updated to 153; the app and GPU driver were unchanged.

What the process tree looks like during a freeze (captured with GetThreadContext + stack-walk + GetThreadDescription, no symbols; offsets are relative to msedge.dll 153.0.4234.32 x64)

Renderer --type=renderer, thread CrRendererMain — 0 ms CPU for the duration, parked in:

ntdll!NtWaitForAlertByThreadId
ntdll!RtlSleepConditionVariableSRW
msedge.dll+0xB201DA            (base::ConditionVariable::Wait)
msedge.dll+0x36B16B4           (mojo sync wait — WaitSet)
msedge.dll+0x1F14A49
msedge.dll+0x7A93810           (task runner)

base::Location/interface-name string pointers live on that stack region: gpu\command_buffer\client\webgpu_implementation.cc and gpu.mojom.CommandBufferClient, i.e. the renderer is inside the WebGPU client's synchronous command-buffer wait (CommandBufferProxyImpl::WaitForGetOffsetInRange / WaitForTokenInRange) and the reply never arrives. Identical stack in all four captures.

Renderer, all other threads — idle (ThreadPoolForegroundWorker × N in WorkerThread::RunWorker wait, Chrome_ChildIOThread in GetQueuedCompletionStatus). Exception in capture 2: Compositor thread at 100 % of one core for 6,367 s (accumulating ~1 s/s), executing a tight loop in a function whose rip-relative references are the lambda name cc::Scheduler::FinishImplFrame()::(lambda)… and the trace-argument literals is_waiting_on_main, has_pending_tree, DidNotSubmitInLastFrame — consistent with cc::Scheduler::ProcessScheduledActions() never returning to its message loop while the state machine reports "waiting on main". In the other three captures the compositor thread was idle.

GPU process --type=gpu-process — idle: CrGpuMain in NtUserMsgWaitForMultipleObjectsEx (2.25 s total CPU over 6.5 h of process life in capture 2; 0–31 ms per 5 s during freezes), VizCompositorThread idle, GpuVSyncThread in WaitForVerticalBlankEvent, all ~45 NVIDIA D3D12 UMD worker threads (nvwgf2umx.dll) and D3D12Core threads in ordinary idle waits. No thread stuck in a driver call; no context-lost/crash event (ProcessFailed was not observed; no WER/Application-Error events).

Browser process — UI thread pumping (NtUserMsgWaitForMultipleObjectsEx), IO thread idle. Network / storage utility processes — idle. Host process — UI thread in GetMessageW.

So: renderer waits on GPU-side command-buffer progress; GPU process has nothing scheduled; compositor (when observed) spins waiting on main. Nobody moves. Memory/handles are flat throughout (renderer WS ~520 MB, no growth).

Renderer state at the moment of each freeze (from a 1 Hz heartbeat the page sends to the host; last beacon before silence)

#	time (JST)	window	page state when it stopped
1	03:14	minimized at capture	idle canvas view
2	12:41	visible, foreground	canvas loop running; compositor spinning as above
3	13:35	visible, not minimized, no dialogs, no input	~10 s after page load, WebGPU render loop not yet started (frame 0)
4	13:44	visible, not minimized	pointer drags in a DOM (non-canvas) view; canvas loop presenting underneath (frame 558, rendered 1 ms earlier)

Ruled out on our side

• JavaScript dialogs (no alert/confirm/prompt pending; no dialog HWND; no ScriptDialogOpening handler), window.open (no NewWindowRequested deferral is taken), native <select> popups (removed, still reproduces)
• Input-routing regressions #5713/#5712 (we are HWND mode, and the renderer main thread is genuinely blocked) and app-region: drag inheritance #5696 (we don't use CSS app-region)
• Third-party DLL injection into the sandboxed renderer (none present), memory/handle exhaustion (none), host event-loop starvation (host thread alive and pumping), persistence/back-end IPC (all idle)
• Continuous presentation of a hidden canvas (we now park the WebGPU loop when the canvas is not shown) — reduces exposure but the freeze also occurs before the first frame (capture 3)

Expected

A WebGPU page should never block the renderer main thread indefinitely: the command-buffer wait should time out / surface device-loss, or the GPU process should keep draining the WebGPU stream.

Actual

Renderer main thread blocks forever in the WebGPU command-buffer wait with an idle GPU process; the host is never told (no ProcessFailed), so the app appears alive to Windows but is dead to the user.

Repros in Edge Browser

Yes, issue can be reproduced in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

no freezes observed on 152.0.4191.66 or earlier through Sep 16; first observed on 153.0.4234.32