What causes a broken async or coroutine call stack?

An await or yield breaks the synchronous call chain, so when the continuation later throws, the stack trace shows the scheduler that resumed it rather than the code that originally started the operation.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a Bug When the Async or Coroutine Call Stack Is Useless

Quick answer: Capture context at the await point with logging or async-local state, enable your runtime's async stack-trace support, and avoid fire-and-forget so exceptions are observed rather than lost on a continuation.

Debugging async code is hard because the stack trace at the failure no longer contains the code that launched the task. The continuation runs on a thread pool or the next frame, orphaned from its origin. You recover the missing context by recording it before the await.

How to recover the context

1. Log at the await/yield boundary

Record an operation id and the relevant state just before each await or yield. When the continuation throws, you correlate the failure to where it started even though the stack no longer shows it.

2. Turn on async stack support

Enable your IDE's async call stack view so it stitches the logical chain across awaits. It reconstructs the conceptual stack the runtime threw away.

3. Never fire-and-forget

An unawaited task that throws often loses the exception entirely. Await it, or attach a continuation that logs faults, so the error surfaces instead of vanishing on the scheduler.

4. Use async-local state for tracing

Flow a trace/correlation id through AsyncLocal (or coroutine-scoped data) so every log line across the async chain carries the same id, letting you reassemble the full path after the fact.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.