Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

7031 Windows Server, AD и Роли

Event ID 7031: Служба неожиданно прервана (С действием по восстановлению)

Обновлено: 15.08.2026 · Официальная документация ↗

Архитектура восстановления служб (Recovery Action)

Событие 7031 логируется в журнале System источником Service Control Manager (SCM). Сообщение гласит: «Служба [ИмяСлужбы] была неожиданно завершена. Будет выполнено следующее корректирующее действие: Перезапуск службы через X миллисекунд». Это событие является полным аналогом жесткого краша >7034 (Service terminated unexpectedly), НО с одним принципиальным отличием: для упавшей службы в оснастке services.msc УЖЕ включена политика автоматического восстановления (Recovery).

Симптомы сбоя (Flapping Services)

Из-за того, что SCM мгновенно поднимает службу (рестартит), проблема маскируется. Администратор заходит на сервер, видит статус службы «Работает» (Running) и думает, что всё хорошо. Однако пользователи могут испытывать кратковременные "глюки": отвал сетевых дисков на 5 секунд, моргание RDP-сессий, сброс очереди печати (Spooler) или разрывы соединений с базами SQL.

Пошаговое дерево решений (Поиск скрытых падений)

Сценарий 1: Анализ масштаба проблемы (PowerShell)

Службы, которые циклически падают и поднимаются (Flapping), уничтожают производительность сервера, постоянно нагружая CPU и диск.

Скрипт поиска нестабильных служб:
# Ищем службы, которые постоянно падают и восстанавливаются
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7031; StartTime=(Get-Date).AddDays(-3)} | 
    Select-Object @{N='ServiceName';E={$_.Properties[0].Value}} | 
    Group-Object ServiceName | Sort-Object Count -Descending | Format-Table -AutoSize

Сценарий 2: Поиск первопричины (Журнал Application)

Событие 7031 — это лишь констатация того, что SCM сделал рестарт. Чтобы починить саму службу, вы должны найти причину её смерти (Crash).

  1. Откройте eventvwr.msc -> Журналы Windows -> Приложение (Application).
  2. Найдите событие 1000 (Application Error), произошедшее секундой ранее, чем 7031.
  3. В событии 1000 будет указан Имя сбойного модуля (Faulting module name) — например, сторонняя .dll плагина антивируса или поврежденный драйвер ядра принтера (для Spooler).
  4. Удалите или обновите этот сбойный модуль.

Сценарий 3: Настройка предела восстановлений (Subsequent failures)

Если служба 'лежит' в бесконечном цикле падений (Crash Loop), она может забить диск минидампами (WER). В свойствах службы (вкладка Восстановление) установите действие Последующие сбои (Subsequent failures) на Не выполнять никаких действий, чтобы разорвать цикл и позволить администратору разобраться.

Типовые ошибки администраторов

  • Лечение симптома, а не болезни: Некоторые админы пишут кастомные PowerShell-скрипты для проверки статуса 'упавших' служб каждые 5 минут, игнорируя встроенную вкладку Recovery. Это создает лишнюю нагрузку. Используйте штатные механизмы ОС (SCM Recovery Actions), а силы бросьте на анализ дампов памяти (WinDbg).
Пользователи жалуются на обрывы связи и отвал программ, а на серверах 'всё зеленое'?
Циклические падения служб (Flapping) маскируют серьезные архитектурные проблемы программного обеспечения или утечки памяти (Memory Leaks). Делегируйте ИТ-инфраструктуру нам: настроим глубокий Zabbix-мониторинг событий 7031, отладим работу баз данных и обеспечим бесшовную работу без 'зависаний'.
💡 Практика специалистов: Событие 7031 массово генерируется службой 'TermService' (Службы удаленных рабочих столов), когда происходит переполнение пула драйверов принтеров (Easy Print). Пользователей выкидывает из RDP-сессии, TermService падает, а через 5 секунд поднимается вновь. Лечится только настройкой Изоляции драйверов принтеров (Print Isolation) через GPO.

Частые вопросы (FAQ)

Почему 7031 появляется при перезагрузке сервера?

При экстренной или зависшей перезагрузке (Shutdown timeout), диспетчер может жестко убить процесс (Kill). Если для него стояло 'Восстановление', SCM успеет записать 7031 в лог перед самым выключением машины.

Можно ли запустить скрипт при падении службы?

Да. На вкладке 'Восстановление' в свойствах службы выберите действие 'Запуск программы' (Run a Program). Вы можете указать путь к PowerShell скрипту, который отправит алерт в Telegram или соберет логи до перезапуска службы.

Чем 7031 отличается от 7032?

7031 означает, что служба упала и ядро запланировало ее рестарт. 7032 (Service Control Manager) означает, что сама попытка автоматического рестарта ПРОВАЛИЛАСЬ (например, не хватило прав или поврежден .exe файл).

Служба падает, но события 7031 нет. Почему?

Если служба завершается сама (вызывает функцию ExitProcess) с ненулевым кодом ошибки, ядро пишет событие 7023 (Служба завершена из-за специфической ошибки). 7031 пишется только при жестком отказе памяти (Access Violation/Crash).

Что означает 'Сбросить счетчик ошибок через N дней'?

Если служба упала 1 раз (сработал Restart), счетчик сбоев стал равен 1. Если она проработает стабильно указанное число дней, счетчик обнулится. Это нужно для корректной отработки сценариев 'Первый сбой' и 'Последующие сбои'.

Полезные материалы
Рекомендуем