Imagine you're going to a bank to file some paperwork.

You hand your files to a window, then you have two choices:

1. Stand at the window, never leave until you get the result — even if an earthquake hits.
2. Wait in the lobby and do your own thing, until you are called.

Option 2 is what await does. Option 1 is what .Result does. The trick is in which window calls you back — and that's where .ConfigureAwait(false) comes in.

The mental model

• Request (you) = the calling code.
• Bank vault = the async operation doing its work in the background.
• Window / clerk = a thread that delivers the result back to you.
• SynchronizationContext = the rule that says which window must deliver your result (e.g. "always window #3").

In a UI app (WPF, WinForms) or classic ASP.NET, there's always an assigned window — it's the UI thread or the request thread. In ASP.NET Core or a console app, there is no assignment — any free clerk can deliver the result.

The three options side by side

// 1. await — go wait in the lobby, come back to my ASSIGNED window
var result = await GetDataAsync();

// 1. await — go wait in the lobby, come back to my ASSIGNED window, .ConfigureAwait(true) is not neccessary
var result = await GetDataAsync().ConfigureAwait(true);

// 2. await + ConfigureAwait(false) — go wait in the lobby, come back to ANY free window
var result = await GetDataAsync().ConfigureAwait(false);

// 3. .Result — stand at the window, refuse to move until I have the receipt, even the earthquake come
var result = GetDataAsync().Result;

• await (default) = "I leave the lobby; when ready, deliver through my assigned window."
• await ... .ConfigureAwait(false) = "I leave the lobby; when ready, deliver through any free window."
• .Result = "I block the lobby; I will not move until the receipt is in my hand."

When to actually use it

• In your own ASP.NET Core services and controllers: skip it. ASP.NET Core has no assigned windows — .ConfigureAwait(false) does nothing.
• In library code (NuGet packages, shared infrastructure): use it everywhere as defensive armor — you don't know if a caller might block on .Result from WPF or classic ASP.NET.
• In WPF / WinForms / classic ASP.NET app code: use await (default) when you need to touch the UI or request state after the await; switch to .ConfigureAwait(false) only for work that doesn't need the original context.
• Never mix .Result (or .Wait()) with async code unless you have a very specific reason — that's the only situation where this whole discussion matters.

TL;DR

• await = leave the lobby, come back through my window.
• .ConfigureAwait(false) = leave the lobby, come back through any window.
• .Result = block the lobby until the receipt arrives.
• Deadlock = .Result blocks the very window the continuation insists on using.
• ASP.NET Core has no assigned windows, so the whole problem doesn't exist there.