Параметры сборки: NET 6.0, целевая ОС — Win7.
Рабочая ОС: Microsoft Windows Server 2016 Standard (Version 10.0.14393 Build 14393)
Есть несколько Win-сервисов на NET 6.0, они условно раз в сутки перезапускаются через Task scheduler.
Перезапуск реализован через батник: net stop + timeout 5 + net start.
То есть вся обвязка под сервисы почти одинакова везде.
Однако один компонент постоянно ломается на перезапуске с плавающей периодичностью: переходит в состояние
"Error 1061, which states "The service cannot accept control messages at this time," is a system error that usually occurs in the context of Windows Se".
То есть его можно только уничтожить через end task. Код ошибки планировщика — 0x2.
В обработчиках OnStop/OnShutdown при провальном рестарте я не вижу каких-либо ошибок.
Более того, я вообще не вижу попытку перезапустить сервис, хотя там есть логирование.
В Win-логах вижу ошибку:
"
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{D63B10C5-BB46-4990-A94F-E40B9D520160}
and APPID
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
to the user WIN-YUYSRIH2LMK\Administrator SID (S-1-5-21-2960480191-828629351-3710621330-500) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
"
Гугл выдал поправить реестр, но тоже не очень помогло.
Никто не сталкивался с подобными вещами ?
Возможно проблема лежит в Win — плоскости , не связана с NET.
Конкретно с таким не сталкивался, поэтому могу высказать только свои предположения.
Судя по GUIDs, которые вы привели (при условии, что имеет отношение к )
CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} and APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
Это доступ к компоненту, связанному с RuntimeBroker (процесс поддержки UWP-приложений, который).
Поэтому моя гипотеза такова (хотя по ней есть сомнения):
— в том сервисе, с которым проблема, используется какое-то API из группы UWP/Store API (вот тут у меня сразу вопрос — а на сколько это реально???)
— при запуске процесса сервиса еще до того, как запустился обработчик событий SCM, делается попытка что-то проинициализировать (не факт что явно в вашем коде — это может делать некая инфраструктура)
— соответственно процесс или падает или зависает еще на этапе инициализации и до SCM дело просто не доходит.
Что бы я попробовал сделать:
— поискал бы в EventLog (System) события от Event Source: Service Control Manager (я точные коды не помню, и с ходу справочника не нашел, но можно посмотреть в EventLog — причем в 10-ке, похоже всё поменялось) — чтобы убедиться, что попытка остановки/запуска всё же происходила и что именно было (может, например, зависать остановка, и повторный запуск потом не происходит).
— там же, но в Application поискать ошибки от .Net Runtime — возможно, что-то найдете.
Что-то более конкретное по такому описанию, увы, предложить не могу.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Sazon, Вы писали:
МР>Конкретно с таким не сталкивался, поэтому могу высказать только свои предположения.
МР>Судя по GUIDs, которые вы привели (при условии, что имеет отношение к ) МР>
CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} and APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
МР>Это доступ к компоненту, связанному с RuntimeBroker (процесс поддержки UWP-приложений, который).
МР>Поэтому моя гипотеза такова (хотя по ней есть сомнения): МР>- в том сервисе, с которым проблема, используется какое-то API из группы UWP/Store API (вот тут у меня сразу вопрос — а на сколько это реально???) МР>- при запуске процесса сервиса еще до того, как запустился обработчик событий SCM, делается попытка что-то проинициализировать (не факт что явно в вашем коде — это может делать некая инфраструктура) МР>- соответственно процесс или падает или зависает еще на этапе инициализации и до SCM дело просто не доходит.
МР>Что бы я попробовал сделать: МР>- поискал бы в EventLog (System) события от Event Source: Service Control Manager (я точные коды не помню, и с ходу справочника не нашел, но можно посмотреть в EventLog — причем в 10-ке, похоже всё поменялось) — чтобы убедиться, что попытка остановки/запуска всё же происходила и что именно было (может, например, зависать остановка, и повторный запуск потом не происходит). МР>- там же, но в Application поискать ошибки от .Net Runtime — возможно, что-то найдете.
МР>Что-то более конкретное по такому описанию, увы, предложить не могу.
Ну и несколько offtop моментов:
1) А действительно ли оправданы такие действия, как регулярный рестарт?
2) Как вариант, попробовать поменять саму процедуру рестарта
S>Однако один компонент постоянно ломается на перезапуске с плавающей периодичностью: переходит в состояние S>"Error 1061, which states "The service cannot accept control messages at this time," is a system error that usually occurs in the context of Windows Se". S>То есть его можно только уничтожить через end task. Код ошибки планировщика — 0x2.
Предлагаю добавить в батник запрос статуса (sc queryex) и трассировку перед и после каждой команды.
S>В обработчиках OnStop/OnShutdown при провальном рестарте я не вижу каких-либо ошибок. S>Более того, я вообще не вижу попытку перезапустить сервис, хотя там есть логирование. S>В Win-логах вижу ошибку:
Я бы проверил события успешных остановки/запуска, предшествующих неудачным. Вдруг он действительно "криво" запустился прошлый раз.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Sazon, Вы писали:
МР>Ну и несколько offtop моментов: МР>1) А действительно ли оправданы такие действия, как регулярный рестарт? МР>2) Как вариант, попробовать поменять саму процедуру рестарта
МР>По второму пункту идея в том, что, возможно, проблема возникает из-за того, что приложение не успевает завершиться (т.е. не всегда успевает), а у вас стоит фиксированный таймаут 5 секунд между отправками команд. МР>Из вариантов навскидку МР>- попробовать готовый cmdlet https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service МР>- написать свою утилиту, используя, например https://learn.microsoft.com/en-us/dotnet/api/system.serviceprocess.servicecontroller (или на что сейчас поменялось в .Net 6)
timeout уже менял, повысил до 20 секунд. Просто ситуация в том, что даже на уровне логирования в OnStop при провалах не вижу соответствующего сообщения, которое на входе в OnStop.
Здравствуйте, Sazon, Вы писали:
S>timeout уже менял, повысил до 20 секунд. Просто ситуация в том, что даже на уровне логирования в OnStop при провалах не вижу соответствующего сообщения, которое на входе в OnStop.
Самое печальное — я не могу найти куда теперь SCM пишет события старта/завершения сервисов.
То что есть в Internet актуально для Windows 7 (может 8 — уже не уверен).
А что нужно сделать, чтобы залогировать отправку управляющих команд от SCM к службе в Windows 10+ — никто не знает...
Я уже час пытаюсь хоть что-то найти (в Internet и глазами в реестре...) — но тщетно.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Sazon, Вы писали:
S>>timeout уже менял, повысил до 20 секунд. Просто ситуация в том, что даже на уровне логирования в OnStop при провалах не вижу соответствующего сообщения, которое на входе в OnStop. МР>Самое печальное — я не могу найти куда теперь SCM пишет события старта/завершения сервисов. МР>То что есть в Internet актуально для Windows 7 (может 8 — уже не уверен). МР>А что нужно сделать, чтобы залогировать отправку управляющих команд от SCM к службе в Windows 10+ — никто не знает...
МР>Я уже час пытаюсь хоть что-то найти (в Internet и глазами в реестре...) — но тщетно.
EventViewer->WindowsLog->Application: Service stopped/started successfully — вот такое вижу.
S>timeout уже менял, повысил до 20 секунд. Просто ситуация в том, что даже на уровне логирования в OnStop при провалах не вижу соответствующего сообщения, которое на входе в OnStop.
Как консоль запускать не пробовали?
Может зависит от входа пользователя в систему?
Здравствуйте, Разраб, Вы писали:
Р>Здравствуйте, Sazon, Вы писали:
S>>timeout уже менял, повысил до 20 секунд. Просто ситуация в том, что даже на уровне логирования в OnStop при провалах не вижу соответствующего сообщения, которое на входе в OnStop. Р>Как консоль запускать не пробовали? Р>Может зависит от входа пользователя в систему?
Вот есть предположение, что может быть связано с входом пользователя. Но планировщик задач настроил. Попробую через самописный рестартер поверх ServiceController, как выше посоветовали. Вероятно, получится что-то детальное узнать.
Здравствуйте, Sazon, Вы писали:
S>EventViewer->WindowsLog->Application: Service stopped/started successfully — вот такое вижу.
Интнрсно.
На моей Windows 10 ничего подобного я не нахожу.
Специально сейчас попробовал — остановил/запустил службу Windows Time. Вижу в System событbе от самой службы, вижу от Kernel (о том что время подкорректировалось), что-то еще, но событий запуска/остановки службы нет ни в одном из системных логов (а расширенные логи, которые в "Application and Service Logs" я вчера полвечера перерывал в надежде увидеть что-то похожее на то, что нужно — но, как я писал, не нашел).
Похоже, между серверными и десктопными версиями несколько больше разницы, чем я думал ранее.
Знать бы еще, как такое поведение (т.е. запись в логи событий служб) включить на десктопе... (не то что бы мне это прямо сильно нужно сейчас, но привычка докапываться до сути теперь не даст успокоиться долго)
МР>Знать бы еще, как такое поведение (т.е. запись в логи событий служб) включить на десктопе... (не то что бы мне это прямо сильно нужно сейчас, но привычка докапываться до сути теперь не даст успокоиться долго)
Это специфика .NET сервисов, регулируется через System.ServiceProcess.ServiceBase.AutoLog.
Здравствуйте, m2user, Вы писали:
M>Это специфика .NET сервисов, регулируется через System.ServiceProcess.ServiceBase.AutoLog.
Аааа... Т.е. речь не о SCM-ых событиях...
Тогда это не совсем то, о чем я говорил — я предлагал посмотреть именно что пишет не сам сервис, а SCM.
Типа: шлются ли реально команды остановки и запуска, и отвечает ли на них сервис.
И если, например, SCM послал Start а в ответ ошибка или ответа не получил в течение таймаута — то уже есть за что зацепиться.
P.S. Я вот про эти события Service Start Operations
Аналогичного раздела для новой Windows я не нашел...
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Sazon, Вы писали:
МР>Ну и несколько offtop моментов: МР>1) А действительно ли оправданы такие действия, как регулярный рестарт? МР>2) Как вариант, попробовать поменять саму процедуру рестарта
МР>По второму пункту идея в том, что, возможно, проблема возникает из-за того, что приложение не успевает завершиться (т.е. не всегда успевает), а у вас стоит фиксированный таймаут 5 секунд между отправками команд. МР>Из вариантов навскидку МР>- попробовать готовый cmdlet https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service МР>- написать свою утилиту, используя, например https://learn.microsoft.com/en-us/dotnet/api/system.serviceprocess.servicecontroller (или на что сейчас поменялось в .Net 6)
В общем написал через данное API свою консоль, с отладкой всего и вся, пока рестарт не сбоит. Посмотрю дальше.
Здравствуйте, Sazon, Вы писали:
S>В общем написал через данное API свою консоль, с отладкой всего и вся, пока рестарт не сбоит. Посмотрю дальше.
Если будет не сложно, отпишите потом по результатам — удалось ли побороть, или что накопали еще, ...
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Sazon, Вы писали:
S>>В общем написал через данное API свою консоль, с отладкой всего и вся, пока рестарт не сбоит. Посмотрю дальше. МР>Если будет не сложно, отпишите потом по результатам — удалось ли побороть, или что накопали еще, ...
