How do I refactor legacy synchronous code to avoid deadlocks?

Deadlocks often appear when synchronous code waits for an asynchronous operation with .Result, .Wait(), or GetAwaiter().GetResult(). On a UI thread or in older ASP.NET applications, the awaited operation may need to resume on the same synchronization context that the blocked code is holding.

Make the call chain asynchronous

The most reliable refactor is async all the way: use asynchronous APIs, return Task or Task<T>, and await the work instead of blocking for it.

public async Task<Order> LoadOrderAsync(
    int orderId,
    CancellationToken cancellationToken)
{
    // Use the asynchronous API so this method doesn't block a thread while waiting.
    using var response = await _httpClient.GetAsync(
        $"orders/{orderId}",
        cancellationToken);

    response.EnsureSuccessStatusCode();

    // Await the body read and return the deserialized result.
    return await response.Content.ReadFromJsonAsync<Order>(
        cancellationToken: cancellationToken)
        ?? throw new InvalidOperationException("The response contained no order.");
}

public async Task<string> GetOrderSummaryAsync(
    int orderId,
    CancellationToken cancellationToken)
{
    // Propagate the async call instead of blocking with .Result or .Wait().
    var order = await LoadOrderAsync(orderId, cancellationToken);

    return $"{order.Id}: {order.Status}";
}

That usually means changing the method signature and then updating its callers until the operation reaches a natural asynchronous boundary, such as an ASP.NET action or a UI event handler. An event handler may be async void; ordinary methods should generally return Task so callers can await them and observe exceptions.

What if a synchronous interface can't change?

First check whether the interface can be made asynchronous. If it truly cannot, avoid adding a blocking bridge around an async method: there is no general-purpose way to block on arbitrary asynchronous work safely in every context. Keep the synchronous path genuinely synchronous where possible, or isolate the boundary behind an API redesign rather than scattering blocking calls through the application.

ConfigureAwait(false) can be useful in library code that doesn't need to resume on the caller's context, but it isn't a blanket fix: every relevant await in the call chain matters, and application code may need its context. Wrapping an async call in Task.Run is not a reliable deadlock fix either; on servers, blocking workers can instead contribute to thread-pool starvation. Search for .Result, .Wait(), and GetAwaiter().GetResult(), then refactor outward from each occurrence.