Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

Мой первый вопрос: почему учетная запись "Локальная системная учетная запись" принимает SOOOOO MUCH LONGER, чем когда служба входит в систему с не-LocalSystemAccount, вызывая тайм-аут службы Windows? какая разница между этими двумя, чтобы вызвать такое поведение при запуске?

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Это остановит службу до тех пор, пока вы вручную не присоедините отладчик Visual Studio с помощью Debug → Attach to Process...

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 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");
}

Ответ 8

Установите конструкцию отладки службы и присоедините отладчик к сервису, чтобы узнать, что происходит.

Ответ 9

Я хочу здесь написать комментарии mdb. Не идите по этому пути. У вашей службы не должен быть пользовательский интерфейс... "Никакое взаимодействие с пользователем" не похоже на определяющую функцию службы.

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

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

Хуже всего, если вам нужно взаимодействие с пользователем, тогда у вас есть реальное отключение здесь, потому что службы не взаимодействуют с пользователем.

В твоей обуви я бы отступил и спросил , почему это должно быть услугой? И для чего требуется взаимодействие с пользователем?

Эти два требования довольно несовместимы, и это должно вызывать тревоги.

Ответ 10

Скопируйте DLL-версию релиза или вызовите dll из режима деблокирования, а не в режим отладки, и вставьте его в папку установки, он должен работать

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

У меня была эта проблема, потребовалось около дня, чтобы ее исправить. Для меня проблема заключалась в том, что мой код пропустил "основное содержимое" и эффективно выполнил пару строк, затем закончил. И это вызвало ошибку для меня. Это консольное приложение на С#, которое устанавливает службу Windows, как только оно попытается запустить его с помощью ServiceController (sc.Run()), тогда это даст мне эту ошибку.

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

ServiceBase.Run(new ServiceHost());

Затем он переставал появляться.

Как уже говорили многие люди, ошибка может быть любой, и предлагаемые решения могут или не могут ее решить. Если они не решают проблему (например, Release вместо Debug, добавив в вашу конфигурацию generatePublisherEvidence = false) и, скорее всего, проблема связана с вашим собственным кодом.

Попробуйте запустить ваш код без использования sc.Run() (т.е. запустите выполнение кода sc.Run()).

Ответ 14

Эта проблема обычно возникает, когда на вашей сборке есть какая-то ссылка, и, как правило, сбой не выполняется во время выполнения.

для отладки put Thread.Sleep(1000) в main(). и поместите точку прерывания в следующую строку выполнения.

Затем запустите процесс и приложите отладчик к процессу во время его запуска. Нажмите f5 после того, как он достигнет точки останова. Это исключает исключение сбоя или ссылки.

Надеюсь, это решит эту ошибку.

Ответ 15

В моем случае проблема отсутствовала в версии .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>

Ответ 16

У меня тоже была эта проблема. Я заставил его работать, изменив учетную запись "Вход в систему" ​​на "Локальная системная учетная запись". В моем проекте у меня была настройка для работы в качестве учетной записи Local Service. Поэтому, когда я его установил, по умолчанию он использовал Local Service. Я использую .net 2.0 и VS 2005. Поэтому установка .net 1.1 SP1 не помогла бы.

Ответ 17

Как локальная системная учетная запись, так и локальная служба не будут работать для меня, а затем установите ее в службу сети, и это сработало нормально.

Ответ 18

В моем случае у меня была эта проблема из-за подлинной ошибки. Перед вызовом конструктора службы один статический конструктор переменной-члена терпит неудачу:

    private static OracleCommand cmd;

    static SchedTasks()
    {
        try
        {
            cmd = new OracleCommand("select * from change_notification");
        }
        catch (Exception e)
        {
            Log(e.Message); 
            // "The provider is not compatible with the version of Oracle client"
        }
    }

Добавив блок try-catch, я обнаружил, что исключение произошло из-за неправильной версии oracle. Установка правильной базы данных решила проблему.

Ответ 19

Я также столкнулся с аналогичной проблемой и обнаружил, что была проблема загрузки сборок. Я сразу же получил эту ошибку при попытке запустить службу.

Чтобы быстро отладить проблему, попробуйте запустить служебный исполняемый файл в командной строке с помощью ProcDump http://technet.microsoft.com/en-us/sysinternals/dd996900. Он должен дать достаточный намек на точные ошибки.

http://bytes.com/topic/net/answers/637227-1053-error-trying-start-my-net-windows-service мне очень помогло.

Ответ 20

Добавление 127.0.0.1 crl.microsoft.com в файл "Хосты" решило нашу проблему.

Ответ 21

Это сработало для меня. В основном убедитесь, что пользователь Log on установлен вправо. Однако это зависит от того, как настроена инфраструктура учетной записи. В моем примере он использует учетные данные пользователя учетной записи AD.

В окне поиска в меню поиска найдите "Услуги",  -Инвестиции найдут требуемый сервис  щелкните правой кнопкой мыши и выберите вкладку "Вход в систему"  -Выберите "Эта учетная запись" и введите требуемый контент/учетные данные  -Откройте его и запустите сервис как обычно.

введите описание изображения здесь

Ответ 22

Если у вас есть форма окна, используемая для тестирования, убедитесь, что объект запуска по-прежнему является сервисом, а не формой окна

Ответ 23

У нас Log4Net настроен на запись в таблицу базы данных. Стол стал настолько большим, что служба тайминга пыталась протоколировать сообщения.

Ответ 24

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

Ответ 25

Попробуйте запустить exe файл. У меня была та же проблема, но когда я запустил ее напрямую, дважды щелкнув файл exe, я получил сообщение о версии .Net framework, потому что был выпущен проект службы с фреймворком, который он не был установлен на целевой машине.

Ответ 26

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

Я следил за этим руководством от Microsoft:

  • открыть редактор реестра, запустить → regedit
  • Найдите следующий подраздел реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application
  • Щелкните правой кнопкой мыши подраздел "Приложение", выберите "Создать" и нажмите "Ключ".
  • Введите имя источника события, используемое в вашей службе Windows для имени ключа.
  • Закрыть редактор реестра.

Ответ 27

введите описание изображения здесь

Взял меня за часы, должен был увидеть средство просмотра событий get_AppSettings().

Изменение конфигурации приложения вызвало проблему.

Ответ 28

Моя проблема связана с целевой структурой, упомянутой в конфигурации службы Windows, была

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

и мой сервер, на котором я пытался установить службу Windows, не поддерживался для этой версии .Net.

Изменив это, я смог решить проблему.

Ответ 29

  • Построить проект в режиме выпуска.
  • Скопировать все файлы папки выпуска в исходный путь.
  • Выполнить службу окна с помощью окна командной строки в доступе администратора.
  • Никогда не удаляйте файлы из исходного пути.

В аренду это работает для меня.