ТС
А создаёт процесс, в итоге, служба DcomLaunch, в любом варианте.
Значит так:
1. Читаем MicrosoftWindows Internals Seventh Edition Part 1 Русиновича — там все отлично разобрано с картинками
2. Доки
Size: a a a
2021 November 25
ТС
1. Читал
2. Нужно углубляться в эту тему будет, но согласен.
2. Нужно углубляться в эту тему будет, но согласен.
ТС
Подозреваю, что какой-то процесс просто оставил задание через IPC, чтобы DcomLaunch сама запустила этот процесс. Такое очень тяжело мониторить без отладчика ядра
ТС
Далеко ходить не надо — всякие шелл-расширения запускаются проводником, хостятся в dllhost. Здесь же аналогичным способом запускаются UWP.
m
ТС
Это да. Но решение хоть какое-то нашлось, пусть и вопрос "кто запускает" - всё ещё тайна природы UWP.
m
Для меня это не тайна :)
S
Так изначальный вопрос был как сделать так чтобы оно не запускалось с системой ?
ТС
я хотел понять, где отключить его "автозапуск" (даже с учётом того, что у него есть какой-то ланчер).
В итоге, его вроде как "убивает" та опция энергосбережения. Это хоть и не ответ на истинный вопрос, но хотя бы решение вопроса "висячего" процесса.
В итоге, его вроде как "убивает" та опция энергосбережения. Это хоть и не ответ на истинный вопрос, но хотя бы решение вопроса "висячего" процесса.
S
this
ТС
была мысль отключить старт этого процесса (вроде как логично). Но его можно "автоматически убивать", чего я не знал.
ТС
Но как бы вопрос решён, но вот эти в силе:
"откуда Dcomlaunch запускает yourphone?
А главное - зачем?"
"откуда Dcomlaunch запускает yourphone?
А главное - зачем?"
m
Не читали вы русиновича, не читали (с)
ТС
там немало деталей про ядро NT, но мало деталей про контейнеры (в основном, про безопасность) и ещё меньше про природу UWP в целом. Лишь общие сведения.
ТС
меня всё ещё очень заботит вопрос определения родительского процесса UWP (настоящего)
S
была же какая то команда, чтобы задачу нормально ставили или я ошибаюсь ?
S
а то эти 10000 часов мучений чтобы тумблер переключить
