На виртуальной машине с двумя ядрами это выглядит как «сервер тормозит без причины». Процесс TiWorker.exe, он же «Установщик модулей Windows», грузит процессор часами, хотя обновления вроде бы не ставятся.
Что было. На нескольких машинах с Windows 10 и 11 процесс держал до 70 процентов процессора именно в рабочее время. Тот же механизм и процесс живут в Windows Server, поэтому разбор применим к серверным редакциям.
Что рекомендовали и что принял автор.
- Убедиться, что это не борьба с чем-то ещё: чистая загрузка с отключёнными сторонними службами (
msconfig→ выборочный запуск). Если нагрузка пропала, виноват сторонний агент, а не Windows. - Проверить память диагностикой
mdsched.exe: сбои памяти дают странные циклы установщика. - Сброс компонентов Windows Update, самый действенный шаг. От имени администратора остановить службы
wuauserv,cryptSvc,bits,msiserver, переименоватьC:\Windows\SoftwareDistributionиC:\Windows\System32\catroot2в*.old, запустить службы обратно. Кэш обновлений пересоберётся, зависшее обновление перестанет мучить установщик. - Перевести службу «Установщик модулей Windows» в ручной запуск, чтобы она не стартовала сама в неудобное время.
- Если ничего не помогло, обновление системы «поверх» с сохранением файлов и программ. Автор принял ответ через неделю.
Что добавить для виртуальной машины.
- Задайте «Период активности» и время обслуживания: установщик и очистка компонентов запускаются по расписанию обслуживания, его можно сдвинуть на ночь.
- После установки обновлений дайте машине перезагрузиться. Незавершённая установка это самая частая причина многочасовой работы
TiWorker. - Понижать приоритет процесса в диспетчере задач можно, но это косметика: нагрузка не исчезает, а растягивается.
Как отличить норму от проблемы. Час-два высокой нагрузки после обновлений это норма. Ежедневные многочасовые циклы без новых обновлений это застрявшее обновление или повреждённый кэш, и лечится шагом 3.
Диагностика Windows Update описана в документации Microsoft.