Что может привести к зависанию службы Windows, если консольное приложение, выполняющее те же действия с использованием одинаковых базовых библиотек, этого не делает?

Question

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

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

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

Проблема: Вчера и в течение последних n недель все работало нормально в нашей производственной среде с использованием службы Windows. Сегодня служба Windows будет работать в течение 20-30 минут и зависает (с интервалом таймера 30 секунд), но консольное приложение работает без проблем и работает в течение последних 4 часов. Подробная регистрация не указывает на какой-либо сбой. Как будто служба Windows просто ... тихо умирает - не останавливаясь.

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

Может ли кто-нибудь высказать соображения о том, что может вызвать зависание службы Windows, если консольное приложение, использующее те же базовые библиотеки, этого не делает; или кто-то может указать мне в направлении инструментов, которые позволят мне диагностировать, что может быть причиной этой проблемы?

Спасибо всем за помощь - продолжаю копать.

Answer 1

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

Разница в выполнении: У вас есть два приложения, выполняющие один и тот же код. Наиболее вероятное различие (и виновник) заключается в том, что служба работает с другим набором учетных данных безопасности, чем ваше консольное приложение, и может стать жертвой капризов безопасности. Проверьте это в первую очередь. В какой учетной записи Windows работает служба? Какова его роль и сфера деятельности? Есть ли на сервере какое-либо стороннее программное обеспечение для обеспечения безопасности и, возможно, приложение Killing для ошибочных приложений? Нужно ли регистрировать свою службу в сторонней службе безопасности? Ваша сборка .Net правильно подписана? Ваши сборки .Net правильно зарегистрированы и настроены на сервере? И последнее, но не менее важное: не забывайте, что пользователь-отладчик, которым вы, скорее всего, являетесь, получает гораздо больше, чем многие другие типы учетных записей.

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

Answer 2

Вы можете отладить службу Windows, запустив ее в интерактивном режиме в Visual Studio . Это может помочь вам локализовать проблему путем установки (возможно, условных) точек останова.

В качестве альтернативы, вы можете использовать диалоговое окно Visual Studio «Присоединить к процессу», чтобы найти процесс службы и подключиться к нему с включенной опцией «Debug CLR». Опять же, это позволяет вам устанавливать точки останова по мере необходимости.

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

Я часто использую «пульс», когда каждый активный поток в сервисе отправляет регулярное (скажем, каждые 30 секунд) сообщение в локальный MSMQ. Это включает ручной или автоматический мониторинг и должно дать вам некоторые подсказки, когда эти сообщения пульса перестают поступать.

Еще одна возможность - это какая-то проблема с разрешениями, потому что служба, вероятно, работает с другим локальным / доменным пользователем для консоли.

После зависания, можете ли вы использовать SCM для остановки службы? Если вы не можете, то, вероятно, существует какая-то проблема взаимоблокировки потоков. После появления зависания службы вы можете перейти в командную строку и набрать sc queryex servicename . Это должно дать вам текущее состояние службы.

Answer 3

Вы можете попробовать эти методы

• Регистрация начало регистрации потока кода в сервисе. У этого параметра на основе, чтобы у вас не было наводнения после того, как вы закончите. Вы должны регистрировать все имена функций, параметры, временные метки.

• Присоединение отладчика Локальное или удаленное подключение отладчика с кодом к работающей службе, установка соответствующих точек останова (может основываться на данных, собранных из журнала)

• PerfMon Запустите эту утилиту и соберите информацию о машине, на которой запущена служба, для любых дополнительных указаний (высокие пики ЦП, пики ввода-вывода, чрезмерные подкачки и т. Д.)

Answer 4

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

Answer 5

Пахнет для меня как нить. Есть ли какая-либо работа с потоками или асинхронная работа? Один из важнейших вопросов заключается в том, "всегда ли сервис висит на одной и той же строке кода или одном и том же методе?" Используйте свою регистрацию, чтобы выяснить, что последним происходит перед зависанием, и, если да, опубликуйте код проблемы.

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

Answer 6

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

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

Answer 7

Какой тип таймера вы используете в службе Windows? Я видел, что многие люди на SO имеют проблемы с таймерами и службами Windows. Здесь - хороший учебник, чтобы убедиться, что вы правильно его настраиваете и используете правильный тип таймера. Надеюсь, это поможет.

Answer 8

Microsoft предоставляет хороший ресурс по отладке службы Windows . По сути, это звучит как то, что вы должны сделать, учитывая, что ваш вопрос настолько общий. С учетом сказанного, были ли внесены какие-либо изменения в систему за последние несколько дней, которые могли бы негативно повлиять на обслуживание? Сделали ли вы какие-либо обновления в коде, которые могут изменить работу службы?

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