Ошибка 1053: служба не ответила на запрос запуска или управления своевременно

Question

Я недавно унаследовал несколько приложений, которые работают как службы Windows, и у меня возникают проблемы с предоставлением графического интерфейса пользователя (доступного из контекстного меню в системном трее) для них обоих.

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

Мой код работает нормально в режиме отладки, и я получаю контекстное меню, и все работает правильно и т. Д.

Когда я устанавливаю службу через «installutil», используя именованную учетную запись (т. Е. Не локальную системную учетную запись), служба работает нормально, но не отображает значок в области уведомлений (я знаю, что это нормальное поведение, потому что я нет опции "взаимодействовать с рабочим столом").

В этом и заключается проблема - когда я выбираю опцию «LocalSystemAccount» и проверяю опцию «взаимодействовать с рабочим столом», служба запускает AGES без видимой причины, и я просто продолжаю получать

Не удалось запустить службу ... на локальном компьютере.

Ошибка 1053: служба не ответила на запрос запуска или управления своевременно.

Между прочим, я увеличил тайм-аут службы Windows с 30 секунд по умолчанию до 2 минут с помощью взлома реестра (см. http://support.microsoft.com/kb/824344, поиск TimeoutPeriod в разделе 3), однако запуск службы по-прежнему истекает.

Мой первый вопрос: почему регистрация «Локальная системная учетная запись» занимает на SOOOOO НАМНОГО БОЛЬШЕ, чем когда служба входит в систему не-LocalSystemAccount, вызывая тайм-аут службы Windows? в чем может быть разница между этими двумя, чтобы вызвать такое разное поведение при запуске?

Во-вторых, сделав шаг назад, все, чего я пытаюсь добиться, - это просто служба Windows, предоставляющая графический интерфейс для настройки, - я был бы весьма рад запустить ее с использованием учетной записи не-Local System (с именем user / pwd), если бы я мог заставить сервис взаимодействовать с рабочим столом (то есть иметь контекстное меню, доступное из системного трея). Возможно ли это, и если да, то как?

Будем благодарны за любые указатели на вышеуказанные вопросы!

Answer 1

После борьбы с этим сообщением в течение нескольких дней, друг сказал мне, что вы ДОЛЖНЫ использовать сборку Release. Когда я устанавливаю до сборки Debug, он выдает это сообщение. Сборка релиза Начинается нормально.

Answer 2

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

Windows внутренне управляет несколькими оконными станциями , каждая со своим рабочим столом. Оконная станция, назначенная службам, работающим под данной учетной записью, полностью отличается от оконной станции вошедшего в систему интерактивного пользователя. Кросс-оконный доступ к станции всегда вызывал недовольство, поскольку это угроза безопасности, но, хотя предыдущие версии Windows допускали некоторые исключения, они были в основном устранены в Vista и более поздних операционных системах.

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

Надежное исправление * для этих проблем заключается в удалении всего кода пользовательского интерфейса из вашей службы и перемещении его в отдельный исполняемый файл, который запускается в интерактивном сеансе пользователя (исполняемый файл можно запустить с помощью глобального запуска группа, например).

Связь между кодом UI и вашим сервисом может быть реализована с использованием любого механизма RPC: для этой цели особенно хорошо работают именованные каналы. Если ваши потребности в связи минимальны, использование определенных приложением команд Service Control Manager также может помочь.

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

ADDENDUM, апрель 2010 г .: Поскольку этот вопрос остается довольно популярным, есть способ исправить еще один распространенный сценарий, который вызывает ошибки «служба не отвечает ...», включая службы .NET, которые не попробуйте любые забавные вещи, такие как взаимодействие с рабочим столом, но do используйте сборки с подписью Authenticode: отключите проверку подписи Authenticode во время загрузки, чтобы создать свидетельство Publisher , добавив следующее элементов в ваш файл .exe.config:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Свидетельство издателя - это малоиспользуемая функция безопасности доступа к коду (CAS): только в маловероятном случае, если ваша служба фактически использует PublisherMembershipCondition, отключение приведет к возникновению проблем. Во всех других случаях это устранит постоянные или периодические сбои при запуске, больше не требуя от среды выполнения дорогостоящих проверок сертификатов (включая поиск в списке отзыва).

Answer 3

Я столкнулся с этой проблемой из-за отсутствия фреймворка на коробке, где запущен мой сервис. На коробке был .NET 4.0, а сервис был написан поверх .NET 4.5.

Я установил следующую загрузку на коробку, перезапустил, и служба запустилась нормально: http://www.microsoft.com/en-us/download/details.aspx?id=30653

Answer 4

Чтобы отладить запуск вашей службы, добавьте в начало метода OnStart() следующую строку:

 while(!System.Diagnostics.Debugger.IsAttached) Thread.Sleep(100);

Это приведет к остановке службы до тех пор, пока вы вручную не подключите отладчик Visual Studio с помощью команды Отладка -> Присоединить к процессу ...

Примечание: В общем, если вам нужен пользователь для взаимодействия с вашим сервисом, лучше разделить компоненты GUI в отдельное приложение Windows, которое запускается при входе пользователя в систему. Затем вы используете что-то например, именованные каналы или какая-либо другая форма IPC для установления связи между приложением с графическим интерфейсом и вашим сервисом. На самом деле это только способ, которым это возможно в Windows Vista.

Answer 5

В классе обслуживания в методе OnStart не выполняйте огромных операций, ОС ожидает короткое время для запуска службы, запустите ваш метод, используя запуск потока:

protected override void OnStart(string[] args)
{
    Thread t = new Thead(new ThreadStart(MethodName)); // e.g.
    t.Start();
}

Answer 6

Я стреляю вслепую, но очень часто обнаруживаю, что длительные задержки при запуске сервисов прямо или косвенно вызваны таймаутами сетевых функций, часто при попытке связаться с контроллером домена при поиске идентификаторов SID учетной записи - что происходит очень часто косвенно через GetMachineAccountSid(), понимаете ли вы это или нет, так как эта функция вызывается подсистемой RPC.

Пример того, как отлаживать в таких ситуациях, см. Случай задержки запуска процесса в блоге Марка Руссиновича.

Answer 7

Если вы используете код отладки, как указано ниже, в вашей службе может возникнуть проблема.

#if(!DEBUG)
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new EmailService()
};
ServiceBase.Run(ServicesToRun);
#else
//direct call function what you need to run
#endif

Чтобы исправить это, при сборке службы Windows удалите условие #if, потому что оно не работает как есть.

Пожалуйста, используйте аргумент для режима отладки, как показано ниже.

if (args != null && args.Length > 0)
{
_isDebug = args[0].ToLower().Contains("debug");
}

Answer 8

В моем случае проблема отсутствовала версия .net framework.

Мой сервис используется

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Но .net Framework версия сервера была 4, поэтому при изменении 4.5 на 4 проблема исправлена:

<startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>

Answer 9

У меня возникла похожая проблема со службой, которую я писал. Это работало хорошо тогда, однажды я начал получать тайм-аут на ошибках Запуска. Это происходило в одном и / или обоих Release и Debug в зависимости от того, что происходило. Я создал экземпляр EventLogger из System.Diagnostics, но какая-либо ошибка, которую я видел, должна была произойти до того, как Logger смог написать ...

Если вы не знаете, где искать EventLogs, в VS вы можете перейти на свой компьютер в обозревателе серверов. Я начал ковыряться в некоторых других EventLogs помимо тех, что для моего Сервиса. В разделе Приложение - .NETRuntime я обнаружил журналы ошибок, относящиеся к ошибке при запуске. По сути, в конструкторе моей службы было несколько исключений (одно оказалось исключением в настройке экземпляра EventLog - что объясняет, почему я не вижу никаких журналов в моей службе EventLog). В предыдущей сборке, очевидно, были и другие ошибки (из-за которых я внес изменения, приведшие к ошибке в настройке EventLog).

Короче говоря - причина тайм-аута может быть связана с различными исключениями / ошибками, но использование Runtime EventLogs может просто помочь вам понять, что происходит (особенно в случаях, когда одна сборка работает, а другая - нет ).

Надеюсь, это поможет!

Answer 10

У меня была эта проблема, и она сводила меня с ума в течение двух дней ... Если ваша проблема похожа на мою:

У меня есть настройки «Пользовательские настройки» в моей службе Windows, поэтому служба может выполнять самообслуживание без остановки и запуска службы. Ну, проблема в «пользовательских настройках», где файл конфигурации для этих настроек сохраняется в папке под профилем пользователя пользователя, который запускает службу Windows в версии файла service-exe.

Эта папка по какой-то причине была повреждена. Я удалил папку, и сервис снова начал работать снова, как обычно…