Debugging async code in C# with Visual Studio 2022

Asynchronous programming is central to modern .NET applications. It keeps web requests responsive, allows background work to run without blocking a user interface, and helps cloud services handle many operations at once. The same flexibility can make failures difficult to follow because execution moves between methods, threads, tasks, and continuation points.

Visual Studio 2022 provides several features for investigating these problems, including breakpoints, exception settings, the Call Stack window, Parallel Stacks, Parallel Watch, Tasks, and async-aware debugging information. Used together, they can reveal whether code is genuinely concurrent, waiting on I/O, deadlocked, or simply hiding an exception inside an unobserved task.

This matters to Australian development teams working across Melbourne, Sydney, Brisbane, Perth and regional offices. A slow API call can affect customers using the NBN during evening peaks, while an unhandled exception in an Azure-hosted service can create operational issues across time zones. Good async diagnostics also support secure handling of personal information under the Privacy Act 1988 and reduce costly production troubleshooting.

Understand what the debugger is showing

An async method usually returns a Task or Task<T>. When execution reaches an incomplete await, the method yields control to its caller. The remainder of the method is stored as a continuation and may resume later on a different thread. This means the source code may look linear even though the runtime is scheduling separate pieces of work.

Start by identifying the task boundary. In this example, the HTTP operation is asynchronous, but the caller must still await it:

public async Task<Customer?> LoadCustomerAsync(
    HttpClient client,
    int customerId,
    CancellationToken cancellationToken)
{
    using HttpResponseMessage response =
        await client.GetAsync(
            $"customers/{customerId}",
            cancellationToken);

    response.EnsureSuccessStatusCode();

    return await response.Content.ReadFromJsonAsync<Customer>(
        cancellationToken: cancellationToken);
}

Place a breakpoint before the first await, after it, and at the caller. Watch the Call Stack as each breakpoint is hit. If the debugger appears to leave the method, that is usually normal: the method has returned an incomplete task and will resume when the I/O operation finishes.

The most useful question is not “which thread am I on?” but “what is this task waiting for?” The Threads window shows physical threads, whereas the Tasks window shows logical asynchronous work. In server applications, several requests may share a small number of thread-pool threads, so a thread-focused view can give an incomplete picture.

Expose exceptions and missing awaits

A common async defect is an exception that occurs inside a task which nobody awaits. Calling an asynchronous method without awaiting it can allow the caller to continue before the operation finishes. Exceptions may then surface later through logging, a task inspection, or an unobserved-exception event.

public async Task ProcessOrderAsync(Order order)
{
    await SaveOrderAsync(order);
    await SendReceiptAsync(order);
}

A call such as ProcessOrderAsync(order); is a warning sign unless fire-and-forget behaviour is deliberate and has a controlled error-handling strategy. Prefer await ProcessOrderAsync(order);. In Visual Studio, enable compiler warnings for ignored tasks and treat relevant warnings as errors in CI where practical.

Open Debug > Windows > Exception Settings and select Common Language Runtime Exceptions when investigating a failure that appears to be swallowed. Breaking when an exception is thrown, rather than only when it is unhandled, shows the original line and the variables that caused the problem. This is especially valuable when an ASP.NET Core middleware later converts the exception into a generic HTTP 500 response.

Use try and catch around an awaited operation, not around the creation of a task that has not yet completed:

try
{
    await paymentClient.AuthoriseAsync(payment, cancellationToken);
}
catch (HttpRequestException ex)
{
    logger.LogError(ex, "Payment service request failed");
    throw;
}

Preserve the original stack trace by using throw; rather than throw ex;. Also avoid logging sensitive payloads while debugging. Australian organisations often need to limit exposure of customer names, addresses, health data, or payment details under privacy and sector-specific obligations.

Compare tasks, threads and synchronisation

Async failures often resemble one another. A deadlock, a long-running operation, and a race condition can all look like “the application is stuck”. Visual Studio 2022 helps separate them when the right window is used.

The classic blocking pattern is:

public Customer GetCustomer()
{
    return LoadCustomerAsync().Result;
}

This can deadlock in environments with a synchronisation context, and it consumes a thread while waiting. Convert the call chain to asynchronous methods instead:

public async Task<Customer> GetCustomerAsync()
{
    return await LoadCustomerAsync();
}

In ASP.NET Core, there is generally no request synchronisation context in the same way as older UI frameworks, but blocking is still harmful because it ties up thread-pool resources. Under load, a service may suffer thread-pool starvation even though each individual request seems simple. That can become noticeable for an Australian e-commerce site during a major sale or for a public service portal during a deadline period.

Use the Tasks window to inspect task status, ID, location, and whether a task is waiting. Parallel Stacks can display relationships between tasks and threads, while Parallel Watch is useful for comparing values across concurrent operations. Add task IDs and correlation IDs to structured logs so debugger observations can be connected with Azure Application Insights or another production monitoring system.

Trace cancellation, timing and concurrency

A task that remains in WaitingForActivation or Running is not automatically faulty. It may be waiting for DNS, a database connection, an HTTP response, a lock, or a timer. Add explicit cancellation and time limits so the debugger can distinguish a valid long operation from an operation with no escape path.

using CancellationTokenSource timeout =
    CancellationTokenSource.CreateLinkedTokenSource(
        requestAborted);

timeout.CancelAfter(TimeSpan.FromSeconds(15));

await client.GetAsync(
    endpoint,
    timeout.Token);

Set a breakpoint where cancellation is requested and another where OperationCanceledException is handled. Cancellation is a normal control flow outcome, so it should usually be logged at an appropriate level rather than treated as an unexpected server error. Check that downstream APIs actually accept and honour the token; passing a token that no operation observes provides little protection.

Use the Diagnostic Tools window to examine CPU, memory, and exception activity while reproducing the issue. For timing-sensitive defects, add timestamps and operation names to logs instead of relying only on breakpoints. A breakpoint changes scheduling and can make a race condition disappear. Conditional breakpoints, tracepoints, and debugger actions are safer for observing high-frequency code.

Useful checks during a live debugging session include:

• Confirm every created task has an owner and an awaited completion path.
• Check whether a lock, semaphore, or connection pool is delaying continuation.
• Verify timeout and cancellation tokens reach database and HTTP calls.
• Compare timestamps before and after each asynchronous boundary.

When several tasks update shared collections or counters, inspect the design rather than simply adding delays. Task.WhenAll is appropriate when operations are independent, but it can amplify load against a database or an external service. For Australian teams operating in Azure Australia East or Australia Southeast, regional latency may be low while a dependency in another region remains slow. Record dependency duration and endpoint location before changing concurrency limits.

Build reliable async diagnostics

A repeatable debugging process begins with a small reproduction. Reduce the operation to one request, one dependency, and one cancellation path. Then run it under the same target framework and configuration used by the application. Differences between Debug and Release builds, local secrets, feature flags, and environment variables can change scheduling and exception behaviour.

Use nullable reference types, analyzers, and compiler warnings to identify defects before runtime. Naming methods with an Async suffix communicates intent, while returning Task rather than async void makes failures observable. Reserve async void for event handlers that require it. For library code, consider ConfigureAwait(false) where avoiding a captured context is intentional, but do not use it as a generic fix for unclear execution flow.

A practical diagnostic workflow is:

1. Reproduce with exception breaking enabled.
2. Inspect the first thrown exception and its inner exception.
3. Follow the task from its creation to its awaiter.
4. Check cancellation, timeout, and dependency timing.
5. Confirm the fix with a test that exercises failure and cancellation.

Production diagnostics should be designed before an incident occurs. Include a request or operation correlation ID, dependency name, elapsed time, retry count, and cancellation reason in structured logs. Avoid putting full customer records into logs, particularly when systems process information covered by Australian privacy requirements. Retain enough technical context to investigate without creating a second data-protection problem.

Testing should cover successful completion, dependency failure, cancellation, timeout, and concurrent calls. A fake HTTP handler or test server can simulate delayed and malformed responses. For race conditions, run the test repeatedly and vary delays rather than assuming one successful run proves correctness. These practices make Visual Studio 2022 a powerful investigation tool while keeping the application observable when the defect reaches a hosted environment.