Как оказалось, это было связано с общим подключением к Интернету (ICS).
Далее я хотел бы описать, как я пришел к такому выводу в надежде, что он поможет другим людям с подобными проблемами.
Первым шагом является определение службы, вызывающей проблемы. Хотя собственный диспетчер задач Windows также научился делать это недавно, я использовал Process Hacker, который также может редактировать конфигурацию службы.
Двойной щелчок svchost.exeэкземпляра- нарушителя и выбор вкладки « Служба » показывает, какие службы работают внутри этого процесса:
svchost.exeможет одновременно размещать множество служб Windows, что затрудняет определение того, какая служба вызывает проблемы. Хотя последние версии Windows 10 обычно изолируют сервисы при наличии достаточного объема ОЗУ , некоторые сервисы все еще совместно используют процесс.
Это такой случай, и самый простой способ определить, какая служба вызывает проблемы, - это разделить их.
Process Hacker может сделать это. На вкладке « Сервис » его главного окна мы можем настроить, может ли сервис совместно использовать процесс:
По крайней мере, две из трех подозрительных служб должны быть настроены как собственные процессы, чтобы обеспечить их разделение в будущем.
Судя по всему, Защитнику Windows не нравится, когда пользователи вмешиваются в конфигурацию своей службы, поэтому для успешного изменения этого параметра мне нужно было
- предоставить Администраторы группы полного доступа на эту услугу,
- отключить услугу,
- перезагрузиться, чтобы служба была остановлена (ее нельзя остановить отдельно),
- измените тип службы на « Собственный процесс» и повторно включите службу (установите « Автозапуск» ) и
- перезагрузите в последний раз, чтобы применить эти изменения.
После этого нарушитель svchost.exeразмещает только один сервис, поэтому у нас есть подозрение:
Чтобы проанализировать, что происходит внутри службы брандмауэра, мы будем использовать средство записи производительности Windows и средство анализа производительности Windows, входящее в состав Windows ADK .
Мы начнем с записи некоторых данных. Пока подозреваемый svchost.exeперемещается в фоновом режиме, загрузите этот файл , добавьте его в качестве профиля, настройте Windows Performance Recorder следующим образом и начните запись:
Дайте записи поработать около 30 секунд, затем сохраните запись. После сохранения нажмите Открыть в WPA, чтобы сразу открыть его для анализа.
Это где вещи начинают становиться сложнее. В моем случае мне нужно было получить подсказку от @ magicandre1981, чтобы найти ее в нужном месте в разделе « Системная активность» → « Общие события» . Там число событий RPC выглядело подозрительно высоким:
Развернувшись, брандмауэр Защитника Windows svchost.exeобнаружил много на стороне сервераwin:Start и win:Stopсобытий:
Следующим шагом было выяснение, кто послал эти вызовы RPC. Если посмотреть на клиентскую сторону, другой svchost.exeэкземпляр выглядел подозрительно:
Действительно, Process Hacker не смог обнаружить службу, запущенную внутри этого процесса, что также постоянно вызывало загрузку процессора:
В этом случае диспетчеру задач Windows удалось определить службу:
Действительно, служба застряла в начальном состоянии. Я отключил его, так как он мне не нужен, и загрузка процессора нормализовалась после следующей перезагрузки.
Я хотел бы выразить свою благодарность @HelpingHand и @ magicandre1981, чья помощь в комментариях сделала это возможным.
Как было позже обнаружено в посте TenForums , сброс брандмауэра Защитника Windows устраняет эту проблему.
Sc config BFE type= ownSc config MpsSvc type= own