Your app works fine in testing. You deploy it, a few users come on, and then it just... hangs. No error, no crash. The request sits there until it times out.

You check the logs. Nothing useful. You restart the app and it's fine again for a while, then it locks up again under load.

If you've got .Result or .Wait() anywhere in your code, that's very likely your problem. They look harmless. They're not.
What These Actually Do

.Result and .Wait() take an async method and force it to run synchronously. You've got a Task and you want the value now, without making your method async, so you write:

var data = GetDataAsync().Result;

It compiles. It works on your machine. It looks like a quick way to avoid turning half your code async.

What it actually does is block the current thread and tell it to sit and wait until the async operation finishes. And in certain setups, that wait never ends.
The Deadlock

Here's how it locks up.

In older ASP.NET (and some desktop apps), there's a synchronization context that controls which thread continues after an await. When the async work finishes, it tries to come back to the original thread to continue.

But that original thread is the one you blocked with .Result. It's sitting there waiting for the async work to complete. The async work is waiting for that thread to be free so it can finish. Neither one gives way.

The request hangs. No exception, no log line, nothing. Just a thread stuck forever, and eventually a timeout. Do this enough times under load and you run out of threads, and the whole app stops responding.

The worst part is it often doesn't show up in testing. One request at a time on your machine works fine. It's only under real traffic, with the thread pool under pressure, that it falls apart. So it passes your tests and breaks in production.
The Fix Is Boring

Don't block. Go async the whole way.

var data = await GetDataAsync();

That's it. Make your method async, return a Task, and await the call instead of reaching for .Result.

The rule people say for this is "async all the way." If a method calls something async, it should be async too, and so should the method that calls it, up the chain. Once one part of your code is async, that tends to spread upward, and that's fine. That's how it's supposed to work.

public async Task<Customer> GetCustomerAsync(int id)
{
    var customer = await _repository.GetByIdAsync(id);
    return customer;
}

No blocking, no deadlock, and the thread is free to handle other requests while it waits.
"But I Can't Make This Method Async"

This is the usual reason people reach for .Result. A constructor can't be async. A property getter can't be async. Some old interface you have to implement isn't async.

Most of the time the real fix is to move the async work somewhere it belongs. Don't do database calls in a constructor. Don't run async work inside a property. If you've got async work stuck inside something that can't be async, that's usually a sign the work is in the wrong place, not a sign you need to block.

There are a few genuine exceptions. The Main method in older console apps sometimes had to block (modern .NET lets Main be async, so this is mostly gone). And there are rare spots in framework-level code where you're truly stuck. But those are rare. If you're reaching for .Result in your normal request-handling code, it's almost never one of those cases.
A Note on ConfigureAwait

You'll see advice to use ConfigureAwait(false) to avoid the deadlock:

var data = await GetDataAsync().ConfigureAwait(false);

This tells the await it doesn't need to come back to the original thread, which sidesteps the deadlock. It's worth using in library code. But treat it as a safety net, not a fix. The actual fix is to not block in the first place. If your code is properly async all the way through, you don't have the deadlock to work around.
Our Take

At Qodors, when a .NET app hangs under load with no error in the logs, .Result and .Wait() are one of the first things we grep for. It's a common one, and it's nasty precisely because it hides during testing and only shows up when real users arrive.

The fix is rarely complicated. It's usually just making a chain of methods async that should have been async from the start. It feels like more work than slapping .Result on the end of a call, and that's exactly why people skip it. Then they spend a week chasing a production hang that a single await would have prevented.

Async all the way isn't a style preference. It's how the thing is meant to be used.
Quick Checklist

• Search your codebase for .Result and .Wait() — find every one
• Anywhere in request-handling code, replace blocking with await
• Make the calling methods async Task up the chain
• If async work is stuck in a constructor or property, move it out
• Use ConfigureAwait(false) in library code as a safety net, not a substitute for going async

.Result and .Wait() are quick to type and they'll pass your tests. Then they hang in production with no error to point you at the cause.

Go async properly and the problem never shows up. That's the whole trade.

DotNet #CSharp #AsyncAwait #AspNetCore #BackendDevelopment #SoftwareEngineering #Performance #DotNetCore #StartupCTO #QodorsEdge

Written by the team at Qodors — we fix .NET apps that hang under load. → www.qodors.com