Как оказалось, это было связано с общим подключением к Интернету (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 выглядело подозрительно высоким:
Развернувшись вниз, svchost.exe брандмауэра Защитника Windows часто обнаруживал на стороне сервера win:Start и win:Stop events:
Следующим шагом было выяснение, кто послал эти вызовы RPC. При просмотре на стороне клиента другой экземпляр svchost.exe выглядел подозрительно:
Действительно, Process Hacker не смог обнаружить службу, запущенную внутри этого процесса, что также постоянно вызывало нагрузку на процессор:
В этом случае диспетчеру задач Windows удалось определить службу:
Действительно, служба застряла в начальном состоянии. Я отключил его, так как он мне не нужен, и загрузка процессора нормализовалась после следующей перезагрузки.
Я хотел бы выразить свою благодарность @HelpingHand и @ magicandre1981, чья помощь в комментариях сделала это возможным.
Как позже было обнаружено в посте TenForums, сброс брандмауэра Защитника Windows устраняет эту проблему.
