Обновлено 17.01.2023
Добрый день! Уважаемые читатели и гости, крупного IT ресурса Pyatilistnik.org. В прошлый раз мы с вами разобрали проблему с кодом 43 и сбоем запроса дескриптора, сегодня хочу вам показать еще один неприятный момент, который я встретил на Windows Server 2012 R2, но он встречается и на других платформах. Смысл глюка в том, что у вас появляется ошибка запуска службы код 1053, или еще может быть формулировка, что служба не ответила на запрос. Это не позволяет вашему приложению запуститься и работать, мы рассмотрим основные причины подобного поведения и устраним их.
Как выглядит ошибка 1053 служба не ответила на запрос
Небольшая предыстория. Я продолжаю процесс виртуализации старого парка физических серверов, для этого я использую утилиту P2V VMware vCenter Converter Standalone 6.2. Все шло как обычно, я накатил утилиту и попытался ее запустить, у меня долго не появлялось окно программы. Через некоторое время у меня возникла на экране ошибка:
Vmware vCenter Converter Standalone Server is installed but not running. When VMware vCenter Converter Standalone Server is not running, you will not be able to connect to local server. Do you want to start it now?
В сообщении сообщается, что служба конвертера не запущена, хотите ли вы ее запустить, я выбираю конечно да. Через секунд 30 появляется второе окно вот с таким текстом:
Unable to start VMware vCenter Converter Standalone Server. You will not be able to connect to local server.
Нам говорят, что служба конвертера не может быть запущена. В оснастке «Службы», вы можете наблюдать три службы VMware vCenter Converter.
Пробую запустить службу приложения в ручном режиме, через правый клик, но выскакивает предупреждение:
Windows could not start the VMware vCenter Converter Standalone Worker service on Local Computer. Error 1053: The service did not respond tj the start or control request in a timely fashion.
В русском варианте, это выглядит вот так:
Не удалось запустить службу (Имя службы) на локальном компьютере.
Ошибка 1053: служба не ответила на запрос запуска или управления своевременно.
Список служб и программ, где вы можете увидеть ошибку 1053
Давайте я вам приведу список с примерами, где вы можете увидеть ответ службы. что она не ответила
- VMware vCenter Converter Standalone 6.2
- Apple Mobile Device Service (ITunes)
- QEMU Guest Agent
- В момент установки драйверов Рутокен
- Skype
- Служба DNS
- Служба MSSQL
- SharePoint
- 4game-service
Как видите разброс проблем очень большой и разнообразный, то же самое касается и операционных систем, вы это легко увидите и на клиентских Windows 7 или Windows 10, так и на серверных Windows Server 2012 R2 и выше.
Как исправить ошибку 1053
Давайте я вам покажу, как я исправлял код ошибки 1053, в случае с утилитой Vmware vCenter Converter Standalone, но описанная методика подойдет и для других служб и программ.
- Первым делом вы должны зайти в оснастку службы, сделать это очень просто, для этого нажмите одновременно две клавиши Win и R, у вас вызовется окно «Выполнить», в нем напишите слово services.msc, это такое системное название данной оснастки, подробный список команд вызова оснасток смотрите по ссылке.
У вас откроется оснастка со всеми службами, которые есть в операционной системе. Вы находите нужную, которая в вашем случае выдавала сообщение «не запускается служба ошибка 1053», и пробуете ее стартануть в ручном режиме. Для этого вы щелкаете по ней правой кнопкой мыши и из контекстного меню выбираете пункт «Запустить». В некоторых случаях, это может помочь, как ни странно, но это был не мой случай.
Видим, что получили все тужу ошибку, не отчаиваемся, так как все только начинается. Через то же контекстное меню, выбираем пункт «Свойства». Тут ситуация может быть такой. Некоторые сервисы, вот хоть убей но не могут функционировать без других, и вот пока другие не запущены, они так же будут простаивать, и в следствии этого вы можете видеть сообщение с кодом 1053. Такая связка называется зависимость. Посмотреть есть она у вашей сбойной службы или нет, можно на соответствующей вкладке «Зависимости». В моем случае, чтобы работала утилита Vmware vCenter Converter Standalone, нужно чтобы работал сервис «Рабочая станция», который как видите состоит из трех компонентов.
Закрываем данное окно и в списке сервисов, ищем нужную нам зависимую, напоминаю у меня, это сервис «Рабочая станция». У меня как видите она оказалась запущенной, если у вас зависимая служба выключена, то пробуйте ее запустить и когда она заработает, пробуйте стартануть основную.
- Если вам фокус с зависимыми сервисами не помог и вы все так же как и я получаете сообщение «служба не ответила своевременно», пробуем проверить настройки DNS. Такое бывает, что некоторые программы для своей работы должны подключиться к рабочей станции или серверу по имени, и если это не получается, то вы оказываетесь в такой ситуации. Открываем настройки TCP/IPv4 и проверяем ваши данные по IP-адресу и DNS серверу, как туда попасть смотрите по ссылке слева. У меня адрес был настроен статически (вручную), если у вас автоматическая в большинстве случаев у пользователей там автоматическая настройка, которая прилетает от DHCP службы, расположенной на другом сервере или сетевом оборудовании, например, в домашних компьютерах, это WIFi или обычный роутер.
У себя я заметил, что первый из DNS серверов, какой-то странный не знакомый мне, видимо кто-то ранее его прописал. Пробую проверить его сетевую доступность, через команду ping и заодно узнать его имя.
ping -a ip адрес вашего dns
У меня он не отвечал, я так же попробовал разрезолвить имя данного сервера, где я получал ошибку, его ip-адрес в моем примере заканчивается на 157, имя определилось, значит второй DNS сервер, все обрабатывал корректно, первый я поправил. Если у вас доменный компьютер, то убедитесь, чтобы имена разрешались, через IP. Идем искать решение дальше.
- Я продолжил изучать данный вопрос и наткнулся на одно обсуждение по моей утилите Vmware vCenter Converter Standalone (https://docs.vmware.com/en/vCenter-Converter-Standalone/6.2/rn/conv_sa_62_rel_notes.html), там описывалась ситуация, что из-за того, что DNS имя не может разрешиться в течении 30 секунд, то вы можете получать ошибку службы 1053. Там предлагалось изменить стандартное значение идущее в операционной системе Windows на другое, увеличив интервал проверки.
Открываем редактор реестра Windows и переходим в ветку:
HKEY_LOCAL_MACHINESystemCurrentControlSetControl
Тут необходимо создать параметр DWORD32 с именем ServicesPipeTimeout и дать ему числовое значение в секундах,
например пять минут, это 3000.
После создания ключа реестра вам необходимо, ОБЯЗАТЕЛЬНО ПЕРЕЗАГРУЗИТЬСЯ.
В 90% случаев у вас ошибка 1053 служба не ответила своевременно, пройдет. Еще видел ситуацию, что после перезагрузки, те службы что идут с отложенным запуском, могут запускаться немного дольше обычного, иногда их даже приходится стартовать вручную, но зато они работают. Мне лично, этот метод помог с Vmware vCenter Converter Standalone.
Дополнительные методы исправления ошибки 1053
К сожалению трюк с ключом реестра срабатывает не всегда и не со всем софтом, в 10% случаев вы все будите видеть предупреждение «сервис не ответил своевременно на запрос», тут я приведу некий чек-лист который позволит вам устранить причину.
- В ряде случаев многие программы в своем коде имеют код, который работает с библиотеками net framework, и если на вашем компьютере они повреждены, то может появляться код 1053, в таких случаях делаем вот что:
- Открываем командную строку от имени администратора и пробуем проверить ваши системные файлы на предмет повреждения, данный метод, ток же будет актуален, если у вас ошибка 1053 возникает на системных служебных, например DNS или Сервер. В командной строке введите команду sfc /scannow. Обязательно дождитесь выполнения данной команды, если она вам не помогла, то есть ее продолжение в виде утилиты: Dism /Online /Cleanup-Image /ScanHealth. Затем, дождавшись завершения работы предыдущей команды, выполните команду: Dism /Online /Cleanup-Image /RestoreHealth.
- Если данный метод вам не помог, то можно попытаться удалить net framework, а затем его переустановить его. Как это проделывается, смотрите по ссылкам слева.
- Еще одним методом исправления ошибка 1053 в wWindows 10, является установка всех свежих обновлений системы, для других версий аналогично
- Еще одним из источников проблем, может выступать поврежденность реестра и его замусоренность, в таких случаях, вам его нужно очистить и оптимизировать, могу вам посоветовать утилиты ccleaner и PrivaZer.
- Редкий случай, но то же возможный, и это проблема с оборудованием. В момент, когда ваш жесткий диск или SSD находятся в предсмертном состоянии, они перестают справляться с обычной нагрузкой и попросту тормозят, создавая тем самым огромные очереди к диску. В следствии чего, операционная система просто не способна запустить нужную службу, так как диск не справляется с этим, и как следствие вы видите, что сервис своевременно не ответил на запрос. Обязательно проверьте дисковые очереди и состояние здоровья ваших дисков.
- Бывает еще ситуации, когда разные программы конфликтуют друг с другом, мешая запускаться конкуренту. В таких случаях необходимо смотреть логи и журналы «Система» и «Приложения»
- Если ошибка возникает у стороннего софта, например, Skype, iTunes, то обязательно убедитесь, что вы используете последнюю версию данного программного обеспечения. Если нет, то удалите старую версию, почистите реестр утилитой cccleaner, перезагрузите компьютер и заново установите свежую версию утилиты. С iTunes видел да же такой момент, что приходилось скачивать exe файл с последним релизом, разархивировать его с помощью 7-zip в папку, где получался набор MSI пакетов, потом все это устанавливалось последовательно, Предпоследним ставился пакет AppleSoftwareUpdate и после него ужеiTunes64. Потом перезагружался, в итоге удавалось исправить ошибку 1053.
- Как вариант еще можно рассмотреть вирусную атаку, загрузите вашу систему в безопасном режиме, без использования сетевых драйверов и каким-нибудь диском Live-CD от Касперского или dr. Web, проведите сканирование вашей системы на вирусы.
- Если у вас служба не ответила на запрос у QEMU Guest Agent, то вам необходимо установить драйвер vioserial (https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html)
Ошибка 1053 в техэксперт из-за нехватки дискового пространства (Обновление 17.01.2023)
Недавно поступила заявка от техподдержки, что перестал работать сервер ИС Техэксперт: 6 поколение. Выглядело это вот так:
Windows could not start ИС Техэксперт: 6 поколение. Интернет 6.4-7555_109709 service on Local Computer. Error 1053: The service did not respond to the start or control request in a timele fashion
В результате служба не могла запуститься, в виду отсутствия дискового пространства на диске.
Надеюсь, что я вам слегка помог в устранении предупреждения с кодом 1053 и вам удалось запустить необходимую службу. С вами был Иван Семин, автор и создатель портала Pyatilistnik.org.
If you continue down the road of trying to make your service interact with the user’s desktop directly, you’ll lose: even under the best of circumstances (i.e. «before Vista»), this is extremely tricky.
Windows internally manages several window stations, each with their own desktop. The window station assigned to services running under a given account is completely different from the window station of the logged-on interactive user. Cross-window station access has always been frowned upon, as it’s a security risk, but whereas previous Windows versions allowed some exceptions, these have been mostly eliminated in Vista and later operating systems.
The most likely reason your service is hanging on startup, is because it’s trying to interact with a nonexistent desktop (or assumes Explorer is running inside the system user session, which also isn’t the case), or waiting for input from an invisible desktop.
The only reliable fix for these issues is to eliminate all UI code from your service, and move it to a separate executable that runs inside the interactive user session (the executable can be started using the global Startup group, for example).
Communication between your UI code and your service can be implemented using any RPC mechanism: Named Pipes work particularly well for this purpose. If your communications needs are minimal, using application-defined Service Control Manager commands might also do the trick.
It will take some effort to achieve this separation between UI and service code: however, it’s the only way to make things work reliably, and will serve you well in the future.
ADDENDUM, April 2010: Since this question remains pretty popular, here’s a way to fix another common scenario that causes «service did not respond…» errors, involving .NET services that don’t attempt any funny stuff like interacting with the desktop, but do use Authenticode signed assemblies: disable the verification of the Authenticode signature at load time in order to create Publisher evidence, by adding the following elements to your .exe.config file:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Publisher evidence is a little-used Code Access Security (CAS) feature: only in the unlikely event that your service actually relies on the PublisherMembershipCondition will disabling it cause issues. In all other cases, it will make the permanent or intermittent startup failures go away, by no longer requiring the runtime to do expensive certificate checks (including revocation list lookups).
If you continue down the road of trying to make your service interact with the user’s desktop directly, you’ll lose: even under the best of circumstances (i.e. «before Vista»), this is extremely tricky.
Windows internally manages several window stations, each with their own desktop. The window station assigned to services running under a given account is completely different from the window station of the logged-on interactive user. Cross-window station access has always been frowned upon, as it’s a security risk, but whereas previous Windows versions allowed some exceptions, these have been mostly eliminated in Vista and later operating systems.
The most likely reason your service is hanging on startup, is because it’s trying to interact with a nonexistent desktop (or assumes Explorer is running inside the system user session, which also isn’t the case), or waiting for input from an invisible desktop.
The only reliable fix for these issues is to eliminate all UI code from your service, and move it to a separate executable that runs inside the interactive user session (the executable can be started using the global Startup group, for example).
Communication between your UI code and your service can be implemented using any RPC mechanism: Named Pipes work particularly well for this purpose. If your communications needs are minimal, using application-defined Service Control Manager commands might also do the trick.
It will take some effort to achieve this separation between UI and service code: however, it’s the only way to make things work reliably, and will serve you well in the future.
ADDENDUM, April 2010: Since this question remains pretty popular, here’s a way to fix another common scenario that causes «service did not respond…» errors, involving .NET services that don’t attempt any funny stuff like interacting with the desktop, but do use Authenticode signed assemblies: disable the verification of the Authenticode signature at load time in order to create Publisher evidence, by adding the following elements to your .exe.config file:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Publisher evidence is a little-used Code Access Security (CAS) feature: only in the unlikely event that your service actually relies on the PublisherMembershipCondition will disabling it cause issues. In all other cases, it will make the permanent or intermittent startup failures go away, by no longer requiring the runtime to do expensive certificate checks (including revocation list lookups).