C# async/await pitfalls: sync-over-async, async void and ConfigureAwait

What it is

await on an incomplete Task captures the current SynchronizationContext (or TaskScheduler) and resumes the rest of the method there. Stephen Cleary's best-practices article in MSDN Magazine explains the consequence: if a UI or classic ASP.NET context that runs one chunk of code at a time is blocked in Task.Wait() or .Result waiting for that same method, the continuation can never run and the program deadlocks; a console application does not deadlock because, as the article puts it, its context schedules the continuation on the thread pool instead. ConfigureAwait(false) tells the awaiter not to resume on the captured context. async void methods have no Task to carry an exception, so a thrown exception goes straight to the context and cannot be caught by the caller; the article reserves async void for event handlers.

Why it matters

ASP.NET Core publishes no SynchronizationContext, which the ConfigureAwait FAQ notes lessens the need for ConfigureAwait(false) there, but sync-over-async still hurts on servers: a blocked thread-pool thread is unavailable, and the .NET diagnostics tutorial describes thread-pool starvation as the pool adding threads slowly while work queues up and CPU stays low. Engineers from JavaScript, where blocking on a promise is impossible, and from Go, where blocking is cheap, both misjudge the cost.

How to apply

• Async all the way: once a method awaits, its callers become async Task up to the entry point (controller action, Main, handler). Do not wrap an async call in a synchronous method with .Result.
• Return Task or Task<T> rather than void; keep async void for event handlers only, and have them await a Task-returning method that holds the logic.
• In library code put ConfigureAwait(false) on every await; in application code (controllers, UI handlers, test methods) leave the default. The FAQ states exactly this split.
• Use Task.Run for CPU-bound work you want off the calling thread, not for I/O; the async scenarios documentation separates the two cases.
• Await every task you start; a dropped Task hides its exception. Pass a CancellationToken through each async signature.

Pitfalls

Task.Wait and .Result wrap exceptions in AggregateException, whereas await rethrows the first exception directly, as the MSDN article shows. ConfigureAwait(false) does not cure a deadlock if any await in the chain lacks it, and the FAQ warns that a custom context may still appear even in ASP.NET Core. An async lambda passed where an Action is expected becomes async void. In .NET 9 the WaitHandleWait trace event flags sync-over-async waits, which the starvation tutorial describes.