процесс «windows modules installer worker» что то устанавливает. как узнать что?

процессы «windows modules installer worker» и «System» что то устанавливают. длится уже больше полтора часа. скачивание из интернета не заметил. грузит в основном процессор, жесткий диск. смотрел через диспетчер задач. открывал центр обновления windows, там все норм, компьютер в обновлении не нуждается.

как узнать что именно устанавливается?

windows 10. ноутбук dell inspiron 5520. i5 3210M. radeon hd 7670M. 8 гб ram.

Ответы (1) 

Добрый день, Albert_906!

В большинстве случаев то, что TiWorker.exe грузит процессор — это штатная работа Windows Modules Installer. Как правило, это происходит при автоматическом или ручном поиске обновлений Windows 10 или их установке. Иногда — при проведении обслуживания компьютера или ноутбука.

При этом обычно достаточно просто подождать, когда установщик модулей завершит свою работу, что на медленных ноутбуках с медленными жесткими дисками, а также в тех случаях, когда обновления давно не проверялись и не скачивались, может занять продолжительное время (вплоть до часов).Если ждать нет желания, а также нет уверенности, что дело в вышеописанном, начать следует со следующих шагов:

1. Зайдите в Параметры (клавиши Win+I) — Обновление и восстановление — Центр обновления Windows.
2. Проверьте наличие обновлений и дождитесь их загрузки и установки.

3. Перезагрузите компьютер для окончания установки обновлений.

Е ще попробуйте для проверки временно отключить/удалить сторонний антивирус/брэндмауер.

Пожалуйста, сообщите о результатах.

Если данная информация была полезена, пожалуйста, отметьте её как ответ.

Что делать, если Windows 10 виснет из-за процесса «Modules Installer Worker»

Пользователи ПК с установленной Windows 10 время от времени наблюдают, как система начинает сильно тормозить. А заглянув в диспетчер задач, видят, что виновником подвисаний компьютера является процесс TiWorker.exe (полное наименование модуля – Windows Modules Installer Worker). Сегодня мы рассмотрим, что это за служба, почему она иногда потребляет несоизмеримо много ресурсов ПК, и как поступать в таких случаях.

За что отвечает штатный процесс «Modules Installer Worker» в «десятой» Windows

Есть в «десятке» такая служба TrustedInstaller. Она представляет собой установщик модулей во флагманской операционной системе от Microsoft, а TiWorker.exe, который висит в Диспетчере задач постоянно – процесс, являющийся компонентой службы. Он активизируется, когда Виндовс начинает искать и загружать обновления, а также во время включения/отключения некоторых компонентов ОС.

Поскольку обновления в автоматическом режиме устанавливаются не так уж часто, в большинстве случаев работа процесса остаётся незамеченной. Но бывают случаи, когда WMIW начинает усиленно потреблять ресурсы компьютера – процессора, памяти, дисковой подсистемы.

Наиболее показательный пример – когда компьютер длительное время был выключен или не имел доступа к интернету. Получив его при очередном включении, он начал навёрстывать упущенное, усиленно скачивая и устанавливая кумулятивные обновления. Разумеется, в этот момент пользоваться компьютером будет весьма затруднительно – придётся ждать, когда процесс завершит свои дела. И иногда такое ожидание затягивается на десятки минут.

Но служба может грузить систему и в не слишком активном состоянии – например, когда в систему были добавлены новые устройства с «кривыми» драйверами. Например, такое явление часто наблюдалось в отношении HP Support Assistant, а также аналогичных сервисных программ для принтеров других брендов. После удаления этого ПО проблема исчезала.

Среди причин зверского аппетита TiWorker.exe можно назвать и сбои в функционировании Update Center. Все эти проблемы – решаемы, причём щадящим способом, без необходимости отключения службы Modules Installer Worker. Но и эту возможность мы обсудим, поскольку иногда без неё не обойтись.

Если «тормоза» наблюдаются редко и спустя некоторое время работоспособность компьютера восстанавливается, такую ситуацию можно считать нормой, и чтобы снизить нагрузку на память процессора, можно выставить процессу низкий приоритет в том же диспетчере задач. Он будет выполнять свои функции намного дольше, но незаметнее для пользователя ПК.

Что делать, если модуль «Modules Installer Worker» критически грузит систему

Рассмотрим наиболее эффективные способы решения проблемы. Один из возможных методов снижения нагрузки на процессор – увеличение скорости поиска пакетов обновлений. Осуществить это можно следующим способом:

• кликаем на «Пуск», затем жмём на шестерёнку;
• в окне установок выбираем вкладку обновлений (Windows Update);
• кликаем на подраздел Update Center, давим на кнопку Check For Updates;
• после выполнения последнего действия появится запрос на перезагрузку системы, соглашаемся.

После старта Windows иногда процесс идёт не по плану: экран длительное время остаётся пустым, в то время как жёсткий диск шумит больше обычного. Пугаться не нужно – рано или поздно процесс загрузки войдёт в нормальное русло, появится рабочий стол, винчестер перестанет жужжать.

Но чаще всего TiWorker.exe грузит CPU и память периодически, со временем ослабляя хватку. Но именно в эти минуты работать за компом практически невозможно. На ситуацию можно повлиять, снизив приоритет нестабильного процесса. Для этого вызываем диспетчер задач комбинацией Ctrl+Alt+Del, находим наш процесс, кликаем на нём правой кнопкой и устанавливаем самый низкий приоритет.

Если проблема не исчезла, и Modules Installer Worker продолжает сильно грузить процессор, можно предпринять другие небесполезные шаги. Для начала – выполнить очистку кэша:

• отключаем интернет-соединение;
• запускаем командную строку, обладая правами администратора системы;
• набираем команду «net stop wuauserv», подтверждаем;
• набираем «net stop bits», снова подтверждаем;
• щёлкаем по пиктограмме «Мой компьютер», выбираем системный диск (обычно это C);
• выбираем папку Windows, а затем каталог SoftwareDistribution;
• очищаем эту папку от содержимого;
• снова переходим в командную строку, набираем две команды, выполняющие противоположные действия – «net start bits», а затем «net start wuauserv».

Если зависания компьютера происходят не из-за забитого кэша, можно попробовать отключить брандмауэр установленной на ПК антивирусной программы – некоторые антивирусы действительно подозрительно относятся к файлам обновлений, длительной проверкой провоцируя зависание компьютера.

Если не помогло и это, нужно выполнить проверку состояния ОС, и если обнаружатся ошибки, исправить их.

• снова вызываем командную строку;
• набираем «dism /restorehealth /cleanup-image /online», подтверждаем;
• перегружаем комп в ответ на запрос;
• проверяем, стал ли компьютер работать стабильнее.

Стоит проверить, не грузят ли жёсткий диск и процессор сторонние программы, влияющие на работу «Центра обновлений» (обычно тормоза появляются после инсталляции нового ПО). Для этого необходимо перезагрузиться в безопасном режиме, нажав F8 до момента загрузки BIOS и выбрав соответствующую опцию из списка. В этом случае запустится «чистая» система, без сторонних программ, и если обновления установятся без замедления работы компьютера, то причина – именно в этом пользовательском ПО. Его нужно удалить, и проблема исчезнет.

Наконец, критическая загрузка процессора службой Windows Modules Installer Worker может происходить из-за криво установленных драйверов, например, если оборудование, за интеграцию которого в ОС они отвечают, физически отсутствует. Исправить ситуацию можно через «Диспетчер устройств», где нужно найти эти устройства и удалить их.

Как отключить запуск службы Modules Installer Worker

Бывает, что причина тормозов компьютера, вызванная процессом TiWorker.exe, так и остаётся невыясненной, и все предыдущие шаги ситуацию не исправили. Значит, единственным способом решения проблемы остаётся отключение службы, о которой мы упоминали в начале статьи.

Для этого выполняем следующие шаги:

• вызываем диспетчер задач;
• находим процесс TiWorker.exe;
• снимаем его, это должно восстановить работоспособность ПК, но мы хотим избежать тормозов и в будущем;
• поэтому запускаем командную строку;
• набираем команду «services.msc»;
• щёлкаем на заставке «Установщик модулей Windows», прерываем работу службы, одновременно отключив её автоматический запуск при старте системы.

Если после этого работа Windows станет нестабильной, придётся переустанавливать систему или включать службу и мириться с зависаниями компьютера.

Как вы боретесь с удалением папок node_modules в Windows?

С недавнего времени использую gulp с его замечательными способностями, но время от времени в папке виртуального сервера накапливается куча папок, которые от завершенных проектов, 5-6 в месяц, которые уже лежат на репозитории и смысла хранить их локально нет.

Возникает вопрос об необходимости удаления: ну не люблю я не нужные файлы.
И тут засада файлы которые лежат в папке node_modules не удаляются, потому что очень гигантское вложение папок одной в другую и Windows не может справится с удалением выбрасывая error о том что слишком длинное имя файла.

Кто и как с этим борется?

Или это только у меня проблема?

PS: Window 8 юзаю.

Вот такой путь получается до конечного файла:

Остальное тупо даже не открывается.

• Вопрос задан более трёх лет назад
• 8768 просмотров

После установки зависимостей в проект делаете

dedupe приводит дерево npm-зависимостей к максимально плоскому виду

Напишите батник себе или задачу для gulp, рекурсивно проходящую по директориям и бросающую их в корень, либо юзайте глобально установленный пакет flatten-deps. А еще, если вы пользователь Total Commander, то shift + del почти всегда нормально все удаляет.

К слову, такая проблема практически всегда бывает с imagemin у всех сборщиков.

Тема в интернетах давно и широко освещаема, народ давно прикурил, что не все так просто, как кажется на первый взгляд, и нет «серебряной пули».

`RimRaf` — хорошо, но не очень: использовать можно либо из скрипта, либо вручную на каждый проект, т.е. перед массовым бэкапом можно использовать лишь в составе некое «подготовительного» инструмента. И таки да — есть проблемы на разных конкретных конфигурациях. «Platform independence» не получился. По сути тех же результатов можно получить делая `rm -rf node_modules` в оболочке `bash` или `rmdir /S node_modules` в `cmd`, причем `rmdir` в большинстве случаев не вспомнит про длину строки, даже если для этого есть поводы.

`npm dedupe` — тоже очень хорошо, но также не очень. Это неплохо делать в каждом проекте после `install` или после каждого изменения зависимостей. В противном случае перекур на сутки — просто гарантирован.

Если доступна оболочка Bash на основе CygWin (если пользуетесь Git, скорее всего она — оболочка баша — есть, но не факт) решение, которое лежит на поверхности:

find . -name «node_modules» -exec rm -rf ‘<>‘ +

плюсик в конце — так надо: автоматом подтаскивает завершение (перевод) строки, можно заменить на \;

Попадался и такой вариант:

После запуска скрипта (можно просто скопипастить в окошко баша) можно без параметров запустить команду `delete-all-dep-folders` в нужной папке или первым параметром задать путь:

Напомню: если `bash` под cygwin, только тогда ему плевать на длину пути. Насколько это так, вы должны знать сами — где и какую версию Гита/Баша вы брали, там и надо читать: в интернетах найдется куча версий баша, скомпилированных с использованием нативных библиотек Windows, которые не используют cygwin.

PowerShell. Якобы та самая «серебрянная пуля» от МелкоСофт. Вроде бы, плевать он хотел на длину пути. Якобы.

Если видели в документациях/интернатах другое — не спешите опровергать: с виндами никогда ничего не бывает однозначно, у нее (Винды), как у любой нормальной женщины, в словаре бинарной логики (либо «да», либо «нет») есть еще и значения «может быть», «не знаю» и «это не я».

Вполне рабочий, НО версия PowerShell >4.0. Более старые версии даже с ключом `-Force` не могут удалить НЕпустые папки.

Уточню: несмотря на то, что Remove-Item (он же del, он же . ) имеет возможность обозначать фильтры и работать рекурсивно, тем не менее необходимость конвейера (знак палки между командами) все-таки есть, и на эти грабли наступало уже очень много народу еще до того, как на ms-tech и в документации была признано и отмечено, что таки да, проблема есть и в качестве решения предлагается использовать конвейер, т.е. – через палку надо делать, и не делать тупо Delete.

И таки да, я нарвался на случай, когда это не сработало — на USB диске (NTFS) лежал старый проект на `Meteor`. Актуальности никакой, для истории тоже не находка, но он единственный усиленно сопротивлялся 4 с лишним часа. После чего мне надоело доискиваться причин такой стойкости и старый (честно купленный еще в прошлом веке) добрый Total Commander справился со всем проектом полностью за 1.897s.

Победитель конкурса — Total Commander с настройками дисковых операций с помощью собственных (НЕ системных) функций. Не верьте документации: Windows, начиная с Vista, выполняет при дисковых операциях значительно больше «левых» действий для красоты, чем Commander, посему операции «его» функциями выполняются быстрее, чем «её» функциями. Совсем хорошо, если отключить в командере поддержку файлов описаний содержимого каталогов. Также, когда-то давно, мне попадался на глаза подключаемый модуль для командера, который заменял/дополнял поиск файлов на другой, в котором используется другая библиотека для работы с регулярными выражениями и дисковые операции можно выполнять сразу над результатами поиска без перекладывания во временную панель.

Или мы не программисты? Пишем свой велосипед по рекурсивному обходу каталогов и `rimraf`-им чего надо. При этом не забываем положить сей золотой ключик отдельно, чтобы мимоходом не прибить его зависимости, и делаем для него консольный вызов. Успешно выкладываем в NPM и собираем звезды на Гитхабе. Дерзайте, а я настоящий программист, мне — лень, когда все просто и понятно 🙂