[Windows] Fix for Runtime error when closing external window with WPF Webview Control

[BagavathiPerumal]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root cause

The issue occurs due to a race condition in the WPF BlazorWebView during window closure. When a Blazor component sends messages to the WebView, those messages are queued on the WPF dispatcher thread. If the window is closed while messages are still pending, WPF begins disposing of the WebView2CompositionControl along with its underlying CoreWebView2 COM object.

Once disposal starts, the queued messages may still execute. When they attempt to call PostWebMessageAsString(), the method tries to access an already disposed COM object, which results in an InvalidOperationException.

Regression PR: #31777

Description of Issue Fix

The fix introduces a three-layer defense mechanism to safely handle the disposal race condition.
The first layer adds a disposal flag that is checked before sending any message. If disposal has already started, the method exits immediately to prevent further operations.

The second layer wraps the PostWebMessageAsString() call in a try-catch block to safely handle cases where the COM object is disposed externally before the disposal flag is updated.

The third layer sets the disposal flag when an exception is caught. This creates a self-healing behavior that prevents repeated attempts after disposal is detected.

The solution ensures safe execution during both normal disposal and race scenarios while maintaining minimal performance overhead.

Tested the behavior in the following platforms.

• Windows
• Mac
• iOS
• Android

Testcase: Unable to add a test case for this scenario due to the reported issue with the WPF Blazor WebView.

Issues Fixed

Fixes #32944

Output

Before Issue Fix	After Issue Fix
32944-BeforeFix.mp4	32944-AfterFix.mp4

[Copilot]

Pull request overview

This PR fixes a race condition in the WPF BlazorWebView that occurs when closing a window while messages are still being sent to the WebView2 control. The issue was introduced in PR #31777, which migrated from WebView2 to WebView2CompositionControl.

Changes:

• Implements a three-layer defense mechanism to prevent crashes during disposal
• Adds disposal flag checking in SendMessage to exit early when disposing
• Adds exception handling for COM object disposal errors
• Introduces MarkAsDisposing() method to allow the owning control to signal disposal start

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
src/BlazorWebView/src/Wpf/BlazorWebView.cs	Calls MarkAsDisposing() in DisposeAsync before setting disposal flag
src/BlazorWebView/src/SharedSource/WebView2WebViewManager.cs	Adds disposal flag, modifies SendMessage with defensive checks and exception handling, adds MarkAsDisposing() method

[sheiksyedm]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[kubaflo]

Could you please try the AI's summary suggestions?

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34006

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34006"

[BagavathiPerumal]

Could you please try the AI's summary suggestions?

I’ve reviewed and updated the changes based on the latest findings.

Case 1: Use a simpler volatile bool disposal flag
I have updated the code to use a simpler volatile bool disposal flag based on the AI summary.

Case 2: COMException handling

• If PostWebMessageAsString() throws an InvalidOperationException with a COMException as the inner exception, it is already handled by the existing catch (InvalidOperationException) block.

• Upon further analysis, a separate catch (COMException) block is not required, as exception handling is based on the outer exception type.

Case 3: WinForms parity
This issue is specific to the WPF Blazor scenario and does not affect the Windows Forms implementation. The same behavior was verified in BlazorWinFormsApp, where the issue does not occur. Therefore, no code changes are required for the WinForms section.

[sheiksyedm]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MauiBot]

🚦 Gate - Test Before and After Fix

📊 Expand Full Gate — 23434b1 · fix-32944-Removed the unnecessary null check.

---

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent:

@copilot write tests for this PR

The agent will analyze the issue, determine the appropriate test type (UI test, device test, unit test, or XAML test), and create tests that verify the fix.

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 23434b1 · fix-32944-Removed the unnecessary null check.

---

🔍 Pre-Flight — Context & Validation

---

Issue: #32944 - Runtime error when closing external window with WPF Webview Control
PR: #34006 - [Windows] Fix for Runtime error when closing external window with WPF Webview Control
Platforms Affected: Windows (WPF BlazorWebView only)
Files Changed: 2 implementation, 0 test

Key Findings

• Race condition in WebView2WebViewManager.SendMessage() when WPF window is closed while Blazor messages are pending on the dispatcher queue
• Regression introduced by PR Use the WebView2CompositionControl in Blazor WPF #31777 (migrated WPF BlazorWebView from WebView2 to WebView2CompositionControl), which changed disposal ordering
• The exception is InvalidOperationException wrapping COMException (0x8007139F) when PostWebMessageAsString() is called on a disposed COM object
• _webview is private readonly, initialized via constructor injection — it is never null; only CoreWebView2 (which can be null before init completes) is null-checked in the fix
• Fix lives in SharedSource/WebView2WebViewManager.cs, which is shared by WPF, WinForms, and MAUI BlazorWebView builds
• Author confirmed WinForms BlazorWebView.Dispose(bool) uses ComponentsDispatcher.InvokeAsync() for async disposal and does not exhibit the same race; MarkAsDisposing() intentionally only called from WPF's DisposeAsync()
• All prior inline review threads resolved: trailing whitespace, null check on _webview, COMException catch, WinForms parity
• Prior agent review (on same commit 23434b1) recommended REQUEST CHANGES for one outstanding item: add code comment explaining why WinForms doesn't call MarkAsDisposing()
• Author responded without making the requested documentation change: "No changes required for WinForms because the issue is limited to the WPF Blazor flow"
• Gate: SKIPPED — no automated tests for this race condition; author states tests cannot be added for this scenario
• Labels: platform/windows, community ✨, partner/syncfusion, s/agent-reviewed, s/agent-changes-requested, s/agent-fix-pr-picked

Current Fix (commit 23434b1)

1. volatile bool _isDisposing field added to WebView2WebViewManager
2. SendMessage(): disposal flag fast-path → CoreWebView2 null check → try/catch InvalidOperationException → self-healing flag set on catch
3. MarkAsDisposing() internal method added with XML doc: "This should be called by the owning control before starting disposal"
4. WPF.BlazorWebView.DisposeAsync() calls _webviewManager?.MarkAsDisposing() before _isDisposed = true

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #34006	Three-layer defense: volatile bool disposal flag + CoreWebView2 null check + try/catch InvalidOperationException + self-heal + MarkAsDisposing()	⚠️ SKIPPED (no automated test for race condition)	WebView2WebViewManager.cs, Wpf/BlazorWebView.cs	Author verified fix manually on reproduction; WinForms parity intentionally omitted

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Pure try/catch in SharedSource: CoreWebView2 null-check + catch (InvalidOperationException | ObjectDisposedException | COMException); no flag, no MarkAsDisposing()	⚠️ BLOCKED (compiles, no runtime test)	1 file	Simplest; single-file; catches broader exception set; no coupling to owning control
2	try-fix (claude-sonnet-4.6)	WPF-specific subclass WpfWebView2WebViewManager overrides SendMessage() with guard + try/catch; SharedSource unchanged	⚠️ BLOCKED (compiles, no runtime test)	2 files (new file + Wpf/BlazorWebView.cs)	Cleanest architecture; keeps SharedSource pure; requires subclass wiring
3	try-fix (gpt-5.3-codex)	CancellationTokenSource-based shutdown via StopAcceptingMessages() in SharedSource; idiomatic .NET cancellation pattern	⚠️ BLOCKED (compiles, no runtime test)	2 files	Most idiomatic .NET; more overhead; better composability with async patterns
4	try-fix (gpt-4.1)	Interlocked.Exchange with int state field (0=active, 1=disposing) instead of volatile bool; stronger memory ordering	❌ FAIL (build command error — infrastructure issue, not code)	2 files	Stronger memory semantics than volatile bool; code is logically correct
PR	PR #34006	Three-layer defense: volatile bool _isDisposing + CoreWebView2 null-check + try/catch InvalidOperationException + self-heal + MarkAsDisposing() called from WPF DisposeAsync()	⚠️ SKIPPED (no automated test for race condition)	2 files	Author verified manually on reproduction; comprehensive defense-in-depth

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	NO NEW IDEAS	All viable strategies covered: guard flags (volatile/Interlocked), exception handling, CancellationToken, subclass override. PR's fix is most comprehensive.

Exhausted: Yes — all 4 models queried; cross-pollination produced no new viable approaches
Selected Fix: PR's fix — All alternatives compile (Attempt 4 had a build command error, not a code error) but all are BLOCKED (no runtime test). The PR's three-layer approach is defense-in-depth appropriate for COM disposal races. Attempt 1 is the simplest alternative (broader exception catch, single file, no state), but the PR's approach is more explicit about lifecycle semantics and was manually verified by the author on the exact reproduction case.

---

📋 Report — Final Recommendation

---

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	WPF BlazorWebView race condition; Windows only; no tests
Gate	⚠️ SKIPPED	No tests detected in PR
Try-Fix	✅ COMPLETE	4 attempts, all BLOCKED (no runtime test for race condition); cross-pollination exhausted
Report	✅ COMPLETE

Summary

PR #34006 fixes a real regression (introduced in PR #31777) where closing a WPF window while Blazor messages are queued causes an InvalidOperationException on a disposed CoreWebView2 COM object. The fix is technically sound and the author manually verified it on the reproduction case. The prior agent review (on the same commit 23434b1) recommended REQUEST CHANGES for one outstanding item: a code comment explaining why WinForms does not call MarkAsDisposing(). The author responded without making that change, stating "No changes required for WinForms because the issue is limited to the WPF Blazor flow."

The single remaining issue is a documentation gap: MarkAsDisposing()'s XML doc comment says "This should be called by the owning control before starting disposal", but WinForms does not call it — with no comment in the code explaining why. This is a maintainability concern for future contributors who may not have access to the PR discussion.

Root Cause

PR #31777 migrated WPF BlazorWebView from WebView2 to WebView2CompositionControl, changing disposal timing. When a WPF window closes, queued Blazor messages on the dispatcher thread may still execute SendMessage() → PostWebMessageAsString() after CoreWebView2 has been disposed, throwing InvalidOperationException.

Fix Quality

What's good:

• volatile bool _isDisposing is correctly typed for cross-thread read/write
• SendMessage() correctly reads _webview.CoreWebView2 (no dead null check on _webview itself) and null-checks CoreWebView2 which CAN be null before initialization
• Try/catch around PostWebMessageAsString() is the documented pattern for COM objects without exposed disposal state
• Self-healing behavior (_isDisposing = true on exception) prevents repeated exception overhead
• MarkAsDisposing() called before _isDisposed = true in WPF DisposeAsync() provides a proactive fast-path

Issues found:

1. WinForms disposal difference undocumented (minor, but maintaining REQUEST CHANGES):
   MarkAsDisposing()'s doc comment says "This should be called by the owning control before starting disposal", yet WinForms BlazorWebView.Dispose(bool) does not call it. The code contains no explanation of why. A future maintainer reading this code will not know if this is intentional or an oversight.

   Requested change: Add one of these (pick either):

   • A comment on MarkAsDisposing() noting the WinForms exception: e.g., // Note: WinForms BlazorWebView.Dispose() dispatches async disposal via ComponentsDispatcher.InvokeAsync(), which serializes disposal differently and does not exhibit this race condition.
   • OR a comment in WinForms BlazorWebView.Dispose(bool disposing) explaining why MarkAsDisposing() is not called

2. No tests (acknowledged): The author explicitly stated tests cannot be added for this race condition scenario, which is understandable given the timing-dependent COM disposal race.

Try-Fix Findings

All 4 alternative approaches compiled successfully but were BLOCKED (no runtime test). The simplest alternative (Attempt 1: pure try/catch with broader exception types, single file) demonstrates the fix can be achieved without MarkAsDisposing() — but the PR's approach is more explicit about lifecycle intent and was directly verified by the author on the reproduction case.

Selected Fix: PR's fix — Selected Fix: PR

---

[kubaflo]

Could you please check the AI's summary?

[BagavathiPerumal]

Could you please check the AI's summary?

I’ve reviewed and updated the changes based on the latest findings:

• Case 1: Updated the code according to the Copilot recommendation and removed the unnecessary null check.
• Case 2: No changes required for WinForms because the issue is limited to the WPF Blazor flow, and the behavior does not reproduce in WinForms.
• Case 3: Unable to add a test case for this scenario due to the reported issue with the WPF Blazor WebView.

[kubaflo]

Code Review — PR #34006

Independent Assessment

What this changes: Adds defensive disposal handling to WebView2WebViewManager.SendMessage(). Rewrites the one-liner PostWebMessageAsString call into a three-layer defense: volatile bool _isDisposing fast-path → CoreWebView2 null check → try/catch InvalidOperationException with self-healing flag. Adds MarkAsDisposing() method called from WPF DisposeAsync().

Inferred motivation: Race condition where Blazor messages queued on the WPF dispatcher execute SendMessage() after CoreWebView2 COM object is disposed during window closure. COM objects don't expose disposal state, so catching the exception is the documented pattern.

Reconciliation with PR Narrative

Author claims: Race condition in WPF BlazorWebView from PR #31777 regression (WebView2 → WebView2CompositionControl migration changed disposal timing).
Agreement: ✅ Code matches the description. Git history confirms #31777 introduced the control type change. The three-layer defense is clearly implemented. WinForms parity intentionally omitted — author verified WinForms does not exhibit the race.

Findings

✅ Good — Defense-in-depth is appropriate for COM disposal races

• volatile bool is correct for a simple cross-thread flag (read/write visibility, not compound atomicity)
• CoreWebView2 null check handles initialization race (CoreWebView2 is null before EnsureCoreWebView2Async)
• Try/catch handles the remaining race window between flag check and actual COM call
• Self-healing (_isDisposing = true on catch) prevents repeated exception overhead
• _webview is private readonly in the manager — never null, but its CoreWebView2 can be null or disposed ✅

💡 Suggestion — Document why WinForms and MAUI Windows don't call MarkAsDisposing()

MarkAsDisposing() XML doc says "This should be called by the owning control before starting disposal", but only WPF calls it. WinForms Dispose(bool) and MAUI DisconnectHandler do not. The SendMessage defense works without it (the try/catch self-heals), but the doc comment implies all consumers should call it.

A one-line comment on MarkAsDisposing() would prevent future confusion:

// Note: WinForms serializes disposal via ComponentsDispatcher.InvokeAsync() and MAUI 
// uses DisconnectHandler() which nulls the manager; both avoid the WPF dispatcher race.
// The try/catch in SendMessage() still protects against edge cases.

💡 Suggestion — Consider catching ObjectDisposedException alongside InvalidOperationException

The author tested and only observed InvalidOperationException, which is valid. However, COM objects can throw ObjectDisposedException in some disposal timing scenarios. Since this is a defense-in-depth layer (not the primary defense), broadening the catch would be cheap insurance:

catch (Exception ex) when (ex is InvalidOperationException or ObjectDisposedException)

This is a minor suggestion — the current catch is sufficient based on observed behavior.

ℹ️ Note — MAUI Windows DisconnectHandler has a theoretical similar race

BlazorWebViewHandler.Windows.cs fire-and-forgets _webviewManager.DisposeAsync() in DisconnectHandler. During that async gap, SendMessage could theoretically be called. The new SendMessage defenses (null check + try/catch) protect against this, but MarkAsDisposing() is not called proactively. This is acceptable since the defense-in-depth in SendMessage handles it, but worth noting for completeness.

ℹ️ Note — CI Status

Helix Unit Tests (Windows Debug/Release) are failing but appear to be infrastructure-related — all build, pack, and integration tests pass. The failures are unrelated to BlazorWebView changes.

Devil's Advocate

• "Is volatile sufficient?" — Yes. volatile bool guarantees visibility across threads. Since it's a simple flag (no read-modify-write), Interlocked is unnecessary.
• "Could SendMessage be called from a non-UI thread?" — Blazor's renderer dispatches through Dispatcher, which uses WPF's DispatcherQueue. The race is between the UI thread (disposal) and dispatched callbacks — volatile handles this.
• "Should this change also go in MAUI's SendMessage overrides?" — The iOS/Android/Tizen SendMessage overrides are in separate files with different disposal patterns. They don't use COM. Out of scope.

Verdict: LGTM

Confidence: high
Summary: The fix correctly addresses a real WPF-specific race condition with an appropriate defense-in-depth pattern. The volatile flag, null check, and try/catch layers are all correctly implemented. The only suggestions are documentation improvements (explaining why only WPF calls MarkAsDisposing()) and optionally broadening the exception catch. Neither blocks merge. The previous agent review's request for a WinForms documentation comment is reasonable but minor — the code is safe regardless.

Review performed by Copilot CLI using the code-review skill

[ScarletKuro]

The PR was merged, but the underlying issue wasn't closed #32944?
Also, on what version of Microsoft.AspNetCore.Components.WebView.Wpf can we expect this fix?
I found some of threading issues in WPF's BlazorWebView #34855 and I want to test to see what is still relevant and what not.