Introduction

Debugging async and await code in Visual Studio 2013 is possible, but it feels less polished than in newer Visual Studio releases. The debugger can still step through async methods, inspect task state, and break on exceptions, but you need to understand that the method is compiled into a state machine and that continuations may resume later on a different call path than older synchronous habits suggest.

What Makes Async Debugging Feel Strange

An async method does not run as one uninterrupted stack frame. It executes until an await, returns control to the caller, and later resumes when the awaited task completes.

1using System;
2using System.Threading.Tasks;
3
4class Demo
5{
6    static async Task<int> ComputeAsync()
7    {
8        await Task.Delay(100);
9        return 42;
10    }
11
12    static async Task MainAsync()
13    {
14        int value = await ComputeAsync();
15        Console.WriteLine(value);
16    }
17}

If you step line by line, the debugger appears to "jump" because it is actually following continuation points rather than one continuous synchronous stack.

Breakpoints Still Work Normally

The simplest technique is still the right one: set breakpoints before and after important await expressions.

1static async Task<string> LoadNameAsync()
2{
3    string before = "starting"; // breakpoint 1
4    await Task.Delay(100);
5    string after = "finished";  // breakpoint 2
6    return after;
7}

Hitting both breakpoints helps you see that the method resumes after the awaited task completes, not necessarily in one immediate step-through flow.

Use The Tasks Window

Visual Studio 2013 includes the Tasks window, which is useful when several asynchronous operations are in flight.

You can open it from the Debug windows menu while debugging. It shows scheduled, running, and completed tasks, which helps answer whether the code is stuck waiting, faulted, or simply not resumed yet.

This is particularly useful when an awaited task never completes because the issue may not be in the current method at all.

Break On Thrown Exceptions

Async exceptions are often observed when the task is awaited, not necessarily at the instant the logical failure began. Enabling exception settings helps catch them earlier.

1static async Task<int> BrokenAsync()
2{
3    await Task.Delay(10);
4    throw new InvalidOperationException("boom");
5}

If the debugger is configured to break on thrown InvalidOperationException, you get a much more useful stop point than if you only notice the failure after it propagates into a higher-level await.

Watch Task State And Locals

In VS 2013, inspecting Task.Status, local variables, and captured state in the Watch or Locals windows is often more informative than relying only on the call stack.

For example, if a task appears to hang, check whether:

• the awaited task is actually running
• it is faulted and the exception was not observed yet
• it is waiting on another task or synchronization context

Those checks often explain more than single-stepping alone.

Avoid Blocking Calls While Debugging Async Code

Sometimes the real bug is not the debugger but the code mixing await with blocking calls such as .Result or .Wait().

Task<int> task = ComputeAsync();
int value = task.Result;

In UI or ASP.NET-style contexts, that pattern can deadlock. If the code behaves strangely under the debugger, verify that you are not forcing asynchronous work back into synchronous blocking patterns.

VS 2013 Has Limits

Compared with newer IDE versions, Visual Studio 2013 provides less rich async call-chain visualization. That means you sometimes need to reconstruct the control flow yourself from breakpoints, exception settings, and task inspection.

That is not a sign the async code is impossible to debug. It only means the tooling is older and expects more manual reasoning.

Common Pitfalls

The most common mistake is expecting the call stack to look like a normal synchronous stack across every await. Another is stepping over an await and assuming the next executed line will appear immediately in the same stack frame. Developers also often miss early exception breakpoints and end up debugging the symptom rather than the original fault. Finally, if the code uses .Result or .Wait(), the strange behavior may be a deadlock issue rather than a debugger limitation.

Summary

• Visual Studio 2013 can debug async code, but the experience is less advanced than newer versions.
• Use breakpoints before and after await to understand continuation flow.
• Inspect tasks directly through debugger windows instead of relying only on the call stack.
• Break on thrown exceptions to catch async failures closer to their origin.
• Check for blocking .Result or .Wait() calls when async behavior looks wrong.