2016-04-29 6 views
2

У нас есть служба, написанная на C++ с некоторым кодом в .NET через CLI. Из-за сторонней библиотеки, которая переопределяет память на основе данных, мы были вынуждены исключить основной код обработки в отдельный путь кода, который используется следующим образом. При запуске службы EXE с определенным параметром командной строки мы можем либо запустить весь сервис в качестве консольного приложения, минуя служебные части, либо как консольное приложение, которое выполняет только обработку. В основном режиме работы служба запускается нормально и использует createprocess для запуска собственного исполняемого файла с параметром командной строки, который пропускает инициализацию службы и переходит в сторону обработки. Затем поток службы ожидает завершения дочернего процесса и повторяет этот процесс по мере необходимости.Что может привести к тому, что процесс перестанет восстанавливаться?

Проблема, с которой мы столкнулись, заключается в том, что служба не запускает собственную версию командной строки после запуска 1700 дочерних процессов. Если нам не повезло, служба также отказывается перезапускать. Никакие релевантные процессы не хранятся в памяти, когда служба отказывается перезапускать. При запуске службы в режиме командной строки после сбоя службы она продолжается еще на 1700 прогонов дочернего процесса до тех пор, пока он также не завершится. Для восстановления работы процесса service/command line требуется перезагрузка системы. Мы также получаем ошибку 322 - «У целевого устройства недостаточно ресурсов для завершения операции». в журнале событий. Мы уже удалили объект ядра Job, который сгруппировал дочерний процесс и родительский процесс в один блок, так что, когда вы завершаете родителя, дочерний элемент также завершается. Это увеличило предел 1700 на несколько тысяч.

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

+1

У меня была своя доля с кучей рабочего стола. См. Http://geekswithblogs.net/akraus1/archive/2014/02/04/155370.aspx Возможно, вы также просачиваете выделенные объекты кучи рабочего стола. Registerwindowmessage - хорошее начало заботиться. –

ответ

3

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

Утилиты SysInternals могут помочь вам диагностировать это. HandleEx или Process Explorer для запуска, а затем выполните поиск в Process Monitor.

+1

Объекты, выделенные кучей на рабочем столе, такие как регистрация окон или оконных сообщений, обычно невидимы для этих инструментов. Вам нужно использовать отладчик ядра для мониторинга текущих кучи рабочего стола или вы вводите драйвер ядра, например, dheapmon делает http://blog.airesoft.co.uk/2009/10/desktop-heap-monitor-vista-7/ –

+0

@ AloisKraus: в этом контексте вряд ли будет объектом кучи рабочего стола. Нет причин для родителя создавать объекты кучи рабочего стола для каждого ребенка, и все, что создает ребенок, должно быть очищено как обычно. Все еще стоит проверить, но сначала я хочу проверить объекты ядра. –

Смежные вопросы