What causes an async void method in Unity?

An async void method has no Task to await or observe, so any exception it throws is rethrown on the synchronization context and tears down the process instead of being catchable.

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 async void Methods Crashing the Process in Unity

Quick answer: Change async void to async Task everywhere except true event handlers, and await or observe the returned Task so exceptions are handled.

You wrote async void DoThing() because the signature was convenient, but when it throws the whole editor or player crashes with no useful stack. async void exceptions cannot be caught by the caller. Here is how to fix it.

How to fix it

1. Return Task instead of void

Change the signature to async Task DoThing(). Now callers can await it, and exceptions flow into the Task where a try/catch can handle them.

2. Keep async void only for handlers

The one legitimate use is a UI or input event handler that must match a void delegate. Even then, wrap the entire body in try/catch so a throw cannot crash the app.

3. Enable a Roslyn analyzer

Add an analyzer rule that flags async void outside event handlers so these slip through code review less often.

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 Unity 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.

The errors you never hear about are the ones quietly costing you players. Visibility turns them into a worklist.