Windows-службы зависают нерегулярно

Question

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

У нас странное поведение, соответствующее нашим самореализованным windows-сервисам. Они замерзают случайно. Иногда они продолжают работать неделями, а иногда замирают несколько раз в неделю. Я уверен, что нет проблем с плохим кодом или необработанными исключениями. На мой взгляд, это какая-то проблема администрирования Windows / управления правами в сочетании с хронологическим совпадением.

Но сначала давайте начнем с некоторой информации:

• Все службы Windows работают на одном сервере.
• Все службы Windows выполняются одним и тем же пользователем Windows.
• Сервер является виртуальной машиной. (VMWare, Windows Server 2008 R2) (я знаю...)
• Сервисы реализованы с использованием VB.Net с.Net 4.0. (Я знаю... не было моего решения;-))
• У нас есть 2 различных вида услуг (называемых A, B).
• Оба вида сервисов читают файлы из каталога и записывают некоторую информацию в базу данных. Вероятно, не важно, что именно они делают, потому что это какая-то стандартная задача.
• Каждый вид сервиса существует в 3 вариантах, которые являются копиями друг друга, но используют разные SQL-серверы для хранения данных (называемые 1, 2, 3).
• С нерегулярными интервалами один или два из шести сервисов, кажется, зависают
• В диспетчере служб Windows замороженные службы помечены как "работающие". С помощью команды Powershell сервисы также помечаются как работающие.
• Там нет шаблона, который вы можете увидеть, какие услуги замораживаются. Иногда, например, сервис A вариант 2 заморожен, тогда как варианты 1 и 3 работают нормально. Важно: за этими 3 вариантами стоит один и тот же код.
• Каждый сервис записывает один файл журнала в день. Заглянув в журнал замороженного сервиса, вы увидите, что в журнале нет исключений или ошибок. Службы просто перестали делать свою работу.
• Там нет соответствующей информации, которую я могу найти в событиях Windows.
• Перезапуск замороженных сервисов всегда помогает. Иногда вы не можете просто перезапустить их. Вместо этого вы должны остановить их сначала и запустить их после этого. В этом случае вы видите "ошибка 1061: служба не может принять управляющие сообщения в это время". Это также происходит нерегулярно.

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

[12.06.2017 01:04:05]
  Thread created. New thread - System ID: 17372
[12.06.2017 01:04:29]
  Thread exited. Exiting thread - System ID: 7152. Exit code - 0x00000000
[12.06.2017 06:55:25]
  Thread created. New thread - System ID: 13252
  Thread exited. Exiting thread - System ID: 31012. Exit code - 0x00000000
  C:\Windows\System32\wship6.dll Unloaded from 0xfcee0000
  C:\Windows\System32\wshtcpip.dll Unloaded from 0xfc650000
  C:\Windows\System32\fwpuclnt.dll Unloaded from 0xfb1c0000
  C:\Windows\system32\security.dll Unloaded from 0x6f9e0000
  Thread exited. Exiting thread - System ID: 25912. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 17372. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 27412. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 13252. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 31768. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 27540. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 12252. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 29336. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 5620. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 8248. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 4340. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 18056. Exit code - 0x00000000
  Thread exited. Exiting thread - System ID: 34164. Exit code - 0x00000000
  Process exited. Exit code - 0x00000000

Последний признак жизни службы (скажем, это был вариант службы 2), который был снова заморожен в это время, был в 01:04:29, где был завершен один поток. В 06:55:25 сервис был перезапущен одним из наших администраторов, потому что он увидел, что сервис, казалось, был заморожен. DebugDiag не записал дамп, поэтому я снова предполагаю, что служба не аварийно завершает работу.

Для меня было странно, что wship6.dll, wshtcpip.dll, fwpuclnt.dll и security.dll были выгружены при перезапуске сервиса, потому что я этого еще не видел. Я несколько раз пытался перезапустить другой вариант обслуживания А, который не был заморожен. Я видел те же записи, но они были написаны только после первого перезапуска. Даже после остановки и повторного запуска службы я не мог видеть, что библиотеки были выгружены.

Итак, после большого количества информации:

• Можете ли вы сказать мне примерно задачу этих библиотек Windows?
• Есть ли намеки на то, что на серверах могут возникнуть проблемы, связанные с управлением правами пользователя / групповыми политиками? Я знаю, что у нас были проблемы с групповой политикой в ​​прошлом. Локальные права пользователя, который выполнял службы, были перезаписаны некоторыми недействительными глобальными групповыми политиками. По крайней мере, я так понял. Я развиваюсь и не делаю административных задач.
• Что еще я могу проверить, чтобы убедиться, что с кодом действительно нет проблем / помочь нашим администраторам решить эту надоедливую проблему?

Редактировать 16.06.2017: Прошлой ночью это была другая служба Windows, которая перестала работать с тем же поведением. Некоторые варианты службы Windows заморожены, а некоторые все еще работают. Но на этот раз вы не можете видеть, что упомянутые DLL были выгружены при перезапуске сервиса. Возможно, первое подозрение по поводу выгруженных DLL не поможет для дальнейшей диагностики. Один интересный факт: эта служба перестала работать одновременно с первой. Может быть, есть проблема с резервными копиями виртуальных машин или что-то подобное? Я предполагаю, что есть регулярная задача, которая вызывает проблему. У вас есть какие-нибудь намеки?

Редактировать 19.06.2017: Думаю, мы нашли что-то интересное. Все службы замораживания имеют один общий компонент.Net: файловую систему-наблюдатель. Это никогда не было проблемой в прошлом, потому что мы расширили.Net-filesystemwatcher с функцией самоподключения. Файловый сервер, который содержит путь, относящийся к нашему файловому системному наблюдателю, резервируется каждую ночь. Наша функция переподключения файловой системы проверяет каждую секунду, если этот сетевой путь недоступен. Если это так, то файловая система будет снова подключена после того, как путь снова станет доступен. Хост-сервер, который управляет всеми нашими виртуальными серверами, был обновлен несколько дней назад. Поэтому у нас есть следующие подозрения: предположим, что наша служба Windows проверяет сетевой путь в моменты времени t_1000 и t_2000. Резервная копия виртуального сервера отключает виртуальный файловый сервер, который содержит сетевой путь, отслеживаемый файловой системой-наблюдателем, в момент времени t_1200 и повторно соединяет путь в момент времени t_1500. В этом случае наша функция повторного подключения не может работать должным образом, потому что в t_1000 и t_2000 был доступен сетевой путь. Файловая система-наблюдатель, тем не менее, потеряла соединение и не реагирует на входящие файлы в указанном сетевом пути. Это не было проблемой раньше, потому что переподключение, запускаемое нашим программным обеспечением для резервного копирования, занимало несколько миллисекунд дольше из-за более медленного оборудования, используемого на этом сервере. Так что наша функция переподключения работала нормально.

Так что мы можем сделать?

• Вариант 1. Обратитесь к поставщику нашего программного обеспечения для резервного копирования. Может быть, это ошибка в его программном обеспечении?
• Вариант 2: Никогда больше не используйте наблюдатель файловой системы, потому что мы всегда работаем над сетевыми путями.
• Вариант 3: Может быть, есть способ оптимизировать файловую систему еще больше? Может ли файловая система наблюдать за такими событиями, поэтому нам не нужно использовать нашу функцию повторного подключения, которая работает с таймером? Как вы думаете?

Спасибо заранее.

Answer 1

Вот наше решение для всех, кто заинтересован:

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

Я не нашел способа дальнейшего улучшения нашей файловой системы, поэтому я думаю, что это наш единственный шанс решить эту проблему.