Shutdown & Lingering Process Diagnostic

When Steam keeps showing your Unity game as Running after quit, use this heuristic survey plus an investigation checklist.

How it works

You tick what your build actually does; we rank common causes and append a practical triage list. Pair with Player.log triage when correlating with player logs.

Answer for your shipping build. This does not inspect your machine — it produces a structured checklist for why Steam may still show "Running" after exit.

Heuristic risk

NONE

Full investigation checklist
## Investigation checklist

### On a repro machine
1. Exit the game normally; wait 30–60s. Does Steam still show **Running**?
2. Open Task Manager (Details): sort by **Parent PID** or use **Process Explorer** tree view.
3. Look for: `UnityCrashHandler`, your game name, WebView2, CEF, updater, launcher, or tool EXEs you spawn.
4. Note whether the stuck PID is your main player or a child; capture command line (Process Explorer → Properties).

### Code / design review
- Single exit path: menu quit, Alt+F4, and OS close should all run the same shutdown sequence.
- Cancel or complete pending `async` / threaded work; avoid new work after quit requested.
- Native plugins: add logging around plugin `OnDestroy` / finalize paths.
- If using `Application.wantsToQuit`, return false only when necessary and always resolve pending state.

### Steam-specific
- Confirm players launch from Steam client (not only loose EXE) when testing **Running** state.
- Compare behavior: Development vs Release, Mono vs IL2CPP.

### What to attach in a bug report
- Screenshot of Process Explorer tree at hang time
- `Player.log` tail from the same session
- Build ID / branch

FAQ

Does this fix the bug automatically?
No. It structures investigation: Task Manager / Process Explorer, logs, and code paths to audit.
Why does Steam care about child processes?
The OS process tree and how your player exits can leave work alive; Steam’s Running state tracks the launched app lifecycle.

Related tools