Ошибки запуска служб Windows 1053, 1067, 1068: диагностика и исправление

Код 1053 означает, что служба не ответила Service Control Manager в отведённое время. Код 1067 сообщает об аварийном завершении процесса службы. Код 1068 указывает, что не удалось запустить службу из её списка зависимостей. Эти три кода закрывают основную часть сбоев запуска служб в Windows Server 2016/2019/2022 и Windows 10/11, и каждый ведёт к своему классу причин.

Порядок работы одинаков: зафиксировать имя службы и код, найти событие в журнале System с источником Service Control Manager, прочитать описание, а затем проверять гипотезы по одной. Последовательная проверка даёт меньше побочных эффектов, чем правка нескольких параметров сразу.

Как устроен Service Control Manager и чем отличаются типы запуска, разобрано в статье системные службы Windows: назначение и типы запуска.

Команды и пути ниже описывают документированное поведение Windows и типовые сценарии восстановления. На продакшене проверяйте шаги на тестовом сервере: часть операций меняет права, реестр и параметры запуска служб.

Что означают коды ошибок 1053, 1067, 1068 и другие

Коды возвращает Service Control Manager (процесс services.exe). SCM запускает процессы служб и ждёт от них отчёт о состоянии. Если отчёт не приходит или процесс падает, SCM возвращает код и пишет событие в журнал System.

Код 1053: служба не ответила вовремя

Windows отводит службе 30000 мс на ответ при старте и на обработку запросов управления. Тайм-аут означает, что SCM не дождался ответа в это окно.

Типовые причины: долгая инициализация с разбором большой базы или прогревом кэша, блокировка на дисковом вводе-выводе, ожидание сети или DNS, взаимная блокировка потоков, нехватка памяти и дескрипторов.

Практический пример: экземпляр SQL Server на медленном массиве восстанавливает логи при старте и не укладывается в 30 секунд. IIS с десятками пулов приложений показывает ту же картину при первом запуске после перезагрузки.

Увеличение тайм-аута через ServicesPipeTimeout даёт отсрочку, но причину не убирает. Диск, сеть и конфигурация остаются прежними, а служба просто дольше остаётся в состоянии запуска.

Код 1067: процесс неожиданно завершился

SCM принял команду запуска, но процесс службы завершился до перехода в рабочее состояние либо сразу после старта. Частые причины: отсутствующая DLL, неверный путь к исполняемому файлу, ошибка в конфигурационном файле, конфликт версий библиотек, необработанное исключение в коде.

Подсказку даёт код выхода процесса: 0x8007007E означает, что модуль не найден, 0xC0000135 указывает на отсутствующую библиотеку .NET, 0x80004005 это общая ошибка без конкретики. Ищите код выхода в журнале Application.

Код 1068: не удалось запустить зависимую службу

Служба не стартует, пока не запущены службы из её списка зависимостей. Причины: зависимая служба отключена, остановлена, работает под другой учётной записью с нехваткой прав или падает сама.

Пример: «Диспетчер печати» не поднимется без Remote Procedure Call (RPC). Если RPC не отвечает, диспетчер печати вернёт 1068, и чинить нужно RPC, а не принтеры.

Смежные коды того же семейства: 1058 (служба отключена или не имеет связанных устройств), 1069 (ошибка входа в систему у учётной записи службы), 1075 (зависимая служба не существует).

Код ошибки это отправная точка, а не диагноз. Точную причину дают журнал событий, список зависимостей и права учётной записи службы.

Как читать журнал событий Windows для диагностики служб

Основной источник данных: оснастка «Просмотр событий», журнал Windows Logs, раздел System. Здесь SCM пишет все события запуска, остановки и сбоев служб.

Фильтрация событий по источнику Service Control Manager

1. Откройте оснастку командой eventvwr.msc или через «Управление компьютером».
2. Разверните Windows Logs и выберите System.
3. В правой панели нажмите Filter Current Log.
4. В поле Event sources отметьте Service Control Manager.
5. В поле Event IDs введите через запятую 7000, 7009, 7023, 7031, 7034.
6. Нажмите OK, затем сохраните выборку: Action, Save Filter to Custom View. Получите готовое представление для повторного использования.

На серверах с высокой нагрузкой журнал System быстро перезаписывается. Увеличьте максимальный размер журнала в свойствах System (Log Properties), иначе событие о сбое исчезнет раньше, чем вы до него доберётесь. Очищать и удалять журналы до завершения диагностики не нужно, потеряете историю.

Общие принципы чтения журналов при сбоях сервисов разобраны в материале как читать логи при ошибке аутентификации: те же приёмы фильтрации и сопоставления событий работают и в Windows.

Сопоставление Event ID с кодом ошибки службы

Пример текста события: «Служба не запустилась из-за ошибки 1053: служба не ответила на запрос запуска или управления в течение заданного времени». Из описания извлекаются три величины: имя службы, код ошибки и путь к исполняемому файлу. Скопируйте текст события целиком, он удобен для поиска по базе знаний и для заявки вендору.

Пошаговое исправление ошибки 1053

Работа идёт от наиболее вероятных причин к редким: зависимости, права и целостность файлов, ввод-вывод и сеть, затем параметры тайм-аута.

Проверка зависимостей и их состояния

Список зависимостей показывает команда:

sc qc <ServiceName>

В выводе смотрите строку DEPENDENCIES: там перечислены службы, без которых старт невозможен. Проверьте состояние каждой:

sc query <DependencyName>

В оснастке services.msc откройте свойства службы и вкладку «Зависимости»: сверху показаны службы, нужные этой, снизу те, которым нужна она сама. Часть зависимостей задаётся группами (например, «Сетевые службы»), и отдельной службы с таким именем в списке не будет.

Пример: «Служба сведений о приложениях» опирается на RPC. Если RPC остановлен, увеличение тайм-аута проблему не решит.

Отдельно проверьте, какие действия настроены при сбое, иначе служба может циклически перезапускаться:

sc qfailure <ServiceName>

Проверка прав доступа и целостности файлов

Учётная запись службы видна в выводе sc qc в строке SERVICE_START_NAME. Права на папку с исполняемым файлом проверяются командой:

icacls "C:\Program Files\Vendor\Service"

Учётной записи службы нужны как минимум чтение и выполнение на папку приложения, а также запись в каталоги логов и данных. Служба может работать под LocalSystem, NetworkService, LocalService или доменной учётной записью, и в каждом случае набор прав отличается.

Пример сценария: после обновления Windows изменились права на подкаталог в ProgramData, и служба потеряла доступ к своим данным. Выдача прав возвращает запуск:

icacls "C:\ProgramData\Vendor" /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(RX)"

Целостность системных файлов проверяется командой sfc /scannow, а при её неудаче - восстановлением образа через DISM. Оба инструмента разобраны ниже в отдельном разделе.

Если зависимости работают, права в порядке, а тайм-аут всё равно срабатывает, смотрите журнал System на предмет ошибок дискового ввода-вывода (источники disk, Ntfs, storahci) и сетевых сбоев. Медленный диск и потерянный маршрут к контроллеру домена дают ту же картину 1053.

Пошаговое исправление ошибки 1067

Задача сводится к поиску причины падения процесса: код выхода, отсутствующие файлы, доступ к конфигурации и реестру.

Анализ кода выхода процесса

1. Откройте Windows Logs, Application.
2. Отфильтруйте события по источникам Application Error и .NET Runtime.
3. Найдите запись с именем исполняемого файла проблемной службы и кодом исключения.
4. Сверьте код выхода с документацией Microsoft для вашей версии .NET или Visual C++.

Расшифровки, которые встречаются чаще всего: 0x8007007E - не найден модуль или DLL; 0xC0000135 - отсутствует требуемая библиотека .NET; 0x80004005 - общая ошибка сбоя; 0xC0000005 - нарушение доступа к памяти. Для служб на .NET отдельно проверяйте журнал .NET Runtime: там указано имя сборки и метод, на котором произошло исключение.

Дальше сверьте путь к исполняемому файлу и параметры запуска:

sc qc <ServiceName>

Если бинарник поддерживает консольный режим, запустите его вручную из командной строки от имени администратора. Ошибка выведется в консоль целиком, включая отсутствующие зависимости. Для служб без консольного режима используйте ProcMon.

Использование ProcMon для поиска причины

Process Monitor показывает обращения процесса к файлам, реестру и сети. Работать без фильтров бессмысленно: поток событий огромен и создаёт нагрузку на диск.

1. Запустите ProcMon от имени администратора.
2. В Filter добавьте условие Process Name is <имя_процесса_службы>.
3. Оставьте включёнными категории File System и Registry.
4. Запустите службу и остановите захват (Ctrl+E).
5. Отфильтруйте по Result: NAME NOT FOUND и ACCESS DENIED.

Строки с NAME NOT FOUND указывают на отсутствующий файл, ключ реестра или DLL. Строки с ACCESS DENIED показывают нехватку прав. Пример: служба читает файл конфигурации в ProgramData, получает ACCESS DENIED и завершается с кодом 1067, хотя сам исполняемый файл и его библиотеки на месте.

Пошаговое исправление ошибки 1068

Поиск зависимых служб

Перечислить службы, которые зависят от указанной, позволяет команда:

sc enumdepend <ServiceName>

Обратный список (от чего зависит сама служба) показывает sc qc в поле DEPENDENCIES и вкладка «Зависимости» оснастки services.msc. Зависимости бывают каскадными: служба A требует B, а B требует C, и запуск упирается в самый нижний уровень.

Пример: «Диспетчер печати» зависит от Remote Procedure Call (RPC). Если RPC остановлен или отключён, диспетчер печати вернёт 1068.

Запуск зависимостей в правильном порядке

1. Определите полный список зависимостей через sc qc и services.msc.
2. Проверьте состояние каждой службы: sc query <DependencyName>.
3. Для отключённой службы выясните причину отключения, затем при необходимости смените тип запуска: sc config <DependencyName> start= demand.
4. Запустите службы по цепочке снизу вверх: net start <DependencyName>, затем net start <ServiceName>.
5. Если зависимая служба падает сама, сначала разберите её ошибку, иначе 1068 вернётся.

Windows обычно поднимает зависимости автоматически. Ручной запуск нужен, когда зависимость отключена, снята с автозапуска или падает при старте. Службы, отключённые групповой политикой или требованиями безопасности, не включайте без согласования: это меняет уровень защиты сервера.

Проверка целостности системных файлов и прав доступа

Использование sfc и DISM

Проверка целостности системных файлов выполняется из командной строки, запущенной от имени администратора:

sfc /scannow

Команда сверяет системные файлы с эталоном и восстанавливает повреждённые из локального хранилища. Процесс занимает от нескольких минут до получаса, прерывать его нельзя. Результат смотрите в конце вывода и в файле CBS.log в каталоге Windows\Logs\CBS.

Если sfc сообщает, что исправление невозможно, восстановите образ системы, а затем повторите проверку:

DISM /Online /Cleanup-Image /RestoreHealth

DISM берёт исходные файлы из Windows Update или из локального источника (параметр /Source). При отсутствии доступа к интернету укажите ISO установочного носителя той же сборки. После DISM запустите sfc /scannow повторно: типовой сценарий восстановления включает оба шага.

Проверка прав на ключи реестра службы

Параметры службы хранятся в ветке HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>. Учётная запись службы должна иметь как минимум чтение этого ключа и его подразделов.

1. Откройте regedit от имени администратора.
2. Перейдите к ветке службы: HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>.
3. Правый клик по ветке, пункт Permissions: проверьте список учётных записей и уровни доступа.
4. Перед любым изменением выгрузите ветку: File, Export, диапазон Selected branch.

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

Чек-лист быстрой диагностики служб Windows

1. Зафиксируйте код ошибки, имя службы и путь к исполняемому файлу из диалога сбоя.
2. Откройте Windows Logs, System и отфильтруйте события по источнику Service Control Manager.
3. Найдите Event ID 7000, 7009, 7023, 7031 или 7034 и прочитайте описание целиком.
4. Проверьте зависимости: sc qc <ServiceName> и sc enumdepend <ServiceName>.
5. Проверьте состояние каждой зависимости: sc query <DependencyName>.
6. Проверьте права учётной записи службы на файлы (icacls) и на ветку реестра (regedit, Permissions).
7. Проверьте целостность системы: sfc /scannow, при неудаче DISM /Online /Cleanup-Image /RestoreHealth.
8. Для падений процесса (1067) поднимите журнал Application и при необходимости подключите ProcMon с фильтром по имени процесса.
9. Перед правкой реестра создайте точку восстановления и экспорт ветки службы.
10. Запустите службу и снова проверьте журнал System: убедитесь, что событий об ошибке больше нет.

Чек-лист подходит для Windows Server 2016, 2019, 2022 и Windows 10/11. Отличия будут в наборе служб и в доступных типах запуска, но порядок действий и набор команд совпадают.

Риски и меры предосторожности при изменении системных параметров

• Правка ServicesPipeTimeout требует перезагрузки и маскирует реальную причину: служба продолжит работать медленно, а ошибка вернётся под нагрузкой.
• Отключение зависимых служб нарушает работу других компонентов: типовая зависимость RPC нужна десяткам служб, включая доменные и печатные.
• Изменение прав на ветки реестра и системные каталоги может сделать систему незагружаемой. Перед правкой делайте экспорт ветки и точку восстановления.
• ProcMon без фильтров создаёт большой объём записей и нагружает диск, что на слабом сервере само по себе вызывает тайм-ауты служб.
• Отключение антивируса для проверки версии DLL снижает защиту. Сначала проверьте журнал блокировок антивируса и добавьте исключение для конкретного файла.
• Изменения на продакшене выполняйте по одному и документируйте: так проще откатить шаг, который ухудшил ситуацию.

Дальше: возьмите журнал System за период сбоя, пройдите чек-лист по порядку и запишите результат каждого шага. Если событие указывает на зависимую службу, устраняйте её ошибку, а не ошибку верхней службы. Совпадение кода 1067 с кодом выхода 0x8007007E означает поиск отсутствующего модуля, а не правку параметров запуска.

Источники

• correctionError 10009 / Исправляем ошибку 10009
• Microsoft Finally Fixes Windows "Virus Protection Off" Alert Bug
• When Postgres Picks the Wrong Index (And How to Fix It)