Shutdown & Lingering Process Diagnostic

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

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