Quick answer: Read the line the exception points to, find which reference on it is null, then trace back to why it was never assigned — an empty Inspector slot, a failed GetComponent, or a destroyed object — and guard it before use.

A NullReferenceException is the single most common error in Unity, and it always means the same thing: you tried to use something that was null. The fix is never the exception itself — it is finding which reference on that line is empty and why. This walks through the four usual causes and how to stop guessing.

How to fix it

1. Read the exact line, not just the message

The console gives you a file and line number — double-click it. Only one or two things on that line can be null, so identify each reference and ask which one was never assigned. The message tells you nothing about which variable; the line does.

2. Check the obvious causes in order

An unassigned public or SerializeField slot in the Inspector, a GetComponent that found no component, a reference to an object that was already Destroyed, or an array or list index that holds null. One of these four is the cause roughly every time.

3. Guard the access where it can legitimately be null

If a reference can be null by design, check it first with an if statement or the null-conditional operator before calling into it. Use TryGetComponent instead of GetComponent so a missing component returns false instead of null. Never let a possibly-null value flow into a method call unchecked.

4. Initialise in Awake, assign in the Inspector

Cache GetComponent results in Awake so they are ready before any other script's Start runs, and confirm every serialized field actually has a value in the scene — a slot that looks filled in the prefab can be empty on the instance.

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 bug you can't reproduce isn't gone — it's just invisible until you capture it from the player's device.