From fd22f2d51e53c13d1a367d6944a46408eb1bc6a5 Mon Sep 17 00:00:00 2001 From: Dennis Doomen Date: Wed, 25 Mar 2026 07:12:54 -0700 Subject: [PATCH] Update AV1835 guideline Split from #298. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- _rules/1835.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_rules/1835.md b/_rules/1835.md index f9571125..f1374e38 100644 --- a/_rules/1835.md +++ b/_rules/1835.md @@ -1,7 +1,7 @@ --- rule_id: 1835 rule_category: performance -title: Beware of `async`/`await` deadlocks in special environments (e.g. WPF) +title: Beware of `async`/`await` deadlocks in UI frameworks (e.g. WPF, WinForms) severity: 1 --- Consider the following asynchronous method: @@ -20,4 +20,4 @@ Now when a button event handler is implemented like this: textBox1.Text = data; } -You will likely end up with a deadlock. Why? Because the `Result` property getter will block until the `async` operation has completed, but since an `async` method _could_ automatically marshal the result back to the original thread (depending on the current `SynchronizationContext` or `TaskScheduler`) and WPF uses a single-threaded synchronization context, they'll be waiting on each other. A similar problem can also happen on UWP, WinForms, classical ASP.NET (not ASP.NET Core) or a Windows Store C#/XAML app. Read more about this [here](https://devblogs.microsoft.com/pfxteam/await-and-ui-and-deadlocks-oh-my/). +You will likely end up with a deadlock. Why? Because the `Result` property getter will block until the `async` operation has completed, but since an `async` method _could_ automatically marshal the result back to the original thread (depending on the current `SynchronizationContext` or `TaskScheduler`) and WPF uses a single-threaded synchronization context, they'll be waiting on each other. A similar problem can also happen on WinForms. Read more about this [here](https://devblogs.microsoft.com/pfxteam/await-and-ui-and-deadlocks-oh-my/).