Deadlocks, ConfigureAwait and ValueTask

When an await has to wait, it captures the current SynchronizationContext (if there is one) and later asks that context to run the rest of the method. A UI framework (WPF, WinForms, MAUI) installs a context whose job is to run continuations back on the UI thread; classic ASP.NET's context similarly lets only one thread at a time work on a request. ASP.NET Core and console apps have no such context, so continuations just run on the thread pool.

The classic deadlock

1. Code on the UI thread calls an async method and then blocks on it with .Result or .Wait().
2. The async method awaits something that is not finished, so it captures the UI context and returns an incomplete task.
3. The awaited operation completes and the continuation is posted to the UI thread.
4. The UI thread is blocked in step 1, waiting for the task, so it never runs the continuation, and the task never completes.

The example builds a minimal single-threaded context that only queues posted work, which is the essential behaviour of a UI thread that is blocked. Rather than hang forever, the blocked thread wakes as soon as either the task finishes or a continuation is posted to its own queue. Work queued behind a thread that never pumps can never run, so that moment is the deadlock, and no timeout is involved:

1using System.Collections.Concurrent;2 3// A stand-in for a UI thread: work posted here runs only when the owning4// thread pumps the queue, and a thread blocked on a task never pumps.5public sealed class SingleThreadContext : SynchronizationContext6{7    private readonly ConcurrentQueue<(SendOrPostCallback, object?)> _queue = new();8    private readonly TaskCompletionSource _posted =9        new(TaskCreationOptions.RunContinuationsAsynchronously);10 11    public Task Posted => _posted.Task;          // completes when anything is posted here12 13    public override void Post(SendOrPostCallback d, object? state)14    {15        _queue.Enqueue((d, state));16        _posted.TrySetResult();17    }18}19 20public static class Solution21{22    static async Task<int> GetAsync(bool continueOnCapturedContext)23    {24        await Task.Delay(50).ConfigureAwait(continueOnCapturedContext);25        return 42;26    }27 28    static string BlockOn(bool continueOnCapturedContext)29    {30        var previous = SynchronizationContext.Current;31        var context = new SingleThreadContext();32        SynchronizationContext.SetSynchronizationContext(context);33        try34        {35            var task = GetAsync(continueOnCapturedContext);36            // Block this thread, as .Result would, until the task finishes or its37            // continuation is queued to this thread, which will never pump it.38            Task.WaitAny(task, context.Posted);39            return task.IsCompleted40                ? $"finished ({task.Result})"41                : $"continuation queued to the blocked thread, task {task.Status}: deadlock";42        }43        finally44        {45            SynchronizationContext.SetSynchronizationContext(previous);46        }47    }48 49    public static string Describe() =>50        $"default await: {BlockOn(true)} | ConfigureAwait(false): {BlockOn(false)}";51}

With a normal await the continuation was queued to the blocked thread and the task could never finish. With ConfigureAwait(false) the await did not capture the context, the continuation ran on the thread pool, and the task finished.

What ConfigureAwait(false) does and does not do

ConfigureAwait(false) affects one await: if that await has to wait, its continuation will not be posted back to the captured context. Two consequences:

• If the awaited task is already complete, the method simply continues on the same thread, still inside the context. The next await without ConfigureAwait(false) captures the context again. That is why library code puts it on every await, not just the first.
• It is a fix for library code, not for the caller. The real fix for the deadlock is not to block: be async all the way up and await instead of .Result.

.Result versus GetAwaiter().GetResult()

Both block. They differ in how they report a failure:

1public static class Solution2{3    static async Task<int> FailAsync()4    {5        await Task.Yield();6        throw new InvalidOperationException("inner problem");7    }8 9    public static string Describe()10    {11        string viaResult, viaGetResult;12 13        try { _ = FailAsync().Result; viaResult = "no exception"; }14        catch (Exception e) { viaResult = e.GetType().Name + " -> " + e.InnerException?.GetType().Name; }15 16        try { _ = FailAsync().GetAwaiter().GetResult(); viaGetResult = "no exception"; }17        catch (Exception e) { viaGetResult = e.GetType().Name; }18 19        ValueTask<int> fast = new ValueTask<int>(5);   // already has its result: no Task allocated20        return $".Result throws {viaResult} | GetAwaiter().GetResult() throws {viaGetResult} | " +21               $"ValueTask completed={fast.IsCompletedSuccessfully} value={fast.Result}";22    }23}

.Result and .Wait() wrap the failure in an AggregateException; GetAwaiter().GetResult() rethrows the original exception, as await would. When you truly must block (a Main method, a legacy synchronous interface), prefer the latter.

ValueTask

ValueTask<T> is a struct that holds a result, a Task<T>, or a reusable IValueTaskSource<T> that the producer may recycle for its next operation. A method that usually completes synchronously, such as a cache hit, can return a value without allocating a Task object. The cost is a set of rules: consume a ValueTask once (one await, or one .AsTask()), never await it concurrently, and do not read .Result or call GetAwaiter().GetResult() before it has completed. If you need to await it twice or hand it to Task.WhenAll, call .AsTask() once and use the task. Default to Task; reach for ValueTask when profiling shows the allocations matter.

Common mistakes