Диагностика останова и затянувшегося процесса

Если Steam продолжает отображать вашу игру Unity как «Выполняемую» после выхода, воспользуйтесь этим эвристическим опросом и контрольным списком для расследования.

Вы отмечаете, что на самом деле делает ваша сборка; мы ранжируем общие причины и добавляем практический список сортировки. Сопряжение с сортировкой Player.log при сопоставлении с журналами игроков.

Ответьте для релизной сборки. Инструмент не сканирует ПК — даёт чек-лист, почему Steam может показывать «Running» после выхода.

Эвристический риск

НЕТ

Полный чек-лист расследования
## Чек-лист расследования

### На машине с воспроизведением
1. Выйдите из игры штатно; подождите 30–60 с. Steam всё ещё **Running**?
2. Диспетчер задач (Подробности): сортировка по **Parent PID** или дерево в **Process Explorer**.
3. Ищите: `UnityCrashHandler`, имя игры, WebView2, CEF, апдейтер, лаунчер или ваши тулзы.
4. Зависший PID — основной процесс или дочерний; снимите командную строку (Process Explorer → Properties).

### Код / дизайн
- Один путь выхода: меню, Alt+F4 и закрытие ОС — одна и та же последовательность shutdown.
- Отмените или завершите висящий `async` / потоки; не стартуйте новое после запроса выхода.
- Нативные плагины: логирование вокруг `OnDestroy` / финализации.
- С `Application.wantsToQuit`: false только когда нужно, и всегда разруливайте состояние.

### Специфика Steam
- Проверяйте **Running** при запуске из клиента Steam, а не только «голым» EXE.
- Сравните: Development vs Release, Mono vs IL2CPP.

### Что приложить к багрепорту
- Скрин дерева Process Explorer в момент зависания
- Хвост `Player.log` той же сессии
- Build ID / ветка
Это автоматически исправляет ошибку?
Нет. Он структурирует расследование: диспетчер задач/обозреватель процессов, журналы и пути кода для аудита.
Почему Steam заботится о дочерних процессах?
Дерево процессов ОС и способы выхода вашего плеера могут оставить работу в живых; Состояние «Работа» Steam отслеживает жизненный цикл запущенного приложения.