Post actualizado el día octubre 17, 2026 by DeiviSanzPlay
You open Task Manager and there it is again: Windows Modules Installer Worker eating half your CPU for no obvious reason. Fans spinning like a jet engine, everything laggy, and you haven’t installed anything new. Annoying, right? The thing is, this process (also known as TiWorker.exe, not msi.dll as many folks repeat) is legit Windows. It handles servicing tasks: installing modules, applying updates, cleaning up component store stuff. When it goes rogue, it’s telling you something.
What Windows Modules Installer Worker actually does (and why it spikes)
The real executable behind the Windows Modules Installer Worker is TiWorker.exe, launched by the Windows Modules Installer service (TrustedInstaller). It’s the worker that applies CBS packages, cumulative updates, .NET patches and component store cleanup. If you see it at 30-60% CPU for a few minutes, that’s normal — it’s working.
The problem starts when Windows Modules Installer Worker high CPU usage lasts hours, or comes back every single day at the same time. That’s not normal maintenance. That’s a loop, a corrupted component store, or a pending update that refuses to finish.
Most guides tell you to just wait. That’s lazy advice. Waiting is only valid if you confirmed an update is genuinely in progress. Otherwise you’re just letting a broken process burn your battery and CPU cycles for nothing.
First: verify it’s really an update and not a stuck loop
Before touching anything, open Settings > Windows Update and look at the status. If you see «Updates in progress» or a percentage moving, leave it alone for 30-60 minutes. The Windows Modules Installer Worker needs that time to finish servicing.
If the update screen says «You’re up to date» and TiWorker.exe is still hammering the CPU, you’ve got a stuck task. That’s your actual problem.
You can confirm it with Resource Monitor (type resmon in Start). Look at the Disk tab, sort by «Total (B/sec)». If TiWorker.exe is reading/writing the WinSxS folder constantly with no progress, it’s looping. Time to intervene.
Fix #1: Repair the component store (the real fix, not the placebo)
Everyone recommends sfc /scannow. Fine, run it, but it won’t fix TiWorker loops. The actual culprit is usually the component store. Run these commands in an elevated Command Prompt, in this order:
- DISM /Online /Cleanup-Image /CheckHealth — quick check.
- DISM /Online /Cleanup-Image /ScanHealth — full scan, can take 10-20 minutes.
- DISM /Online /Cleanup-Image /RestoreHealth — repairs corruption using Windows Update as source.
If RestoreHealth fails with error 0x800f081f, point it to a mounted ISO of your Windows version using /Source:install.wim. This is the step 90% of tutorials skip, and it’s exactly where the Windows Modules Installer Worker high CPU problem actually gets solved.
After DISM finishes, reboot. Then run sfc /scannow to confirm no integrity violations remain.
Fix #2: Kill the update loop with the Windows Update troubleshooter
If the component store is clean and TiWorker still spikes, the update pipeline itself is broken. Go to Settings > System > Troubleshoot > Other troubleshooters and run the Windows Update one. It resets BITS, the update cache, and re-registers the update DLLs.
Want to do it manually? Stop the wuauserv, bits and cryptsvc services, delete the contents of C:WindowsSoftwareDistributionDownload and C:WindowsSystem32catroot2, then restart the services. This forces Windows to redownload everything from scratch instead of choking on a half-broken package.
This is the cure for the classic scenario: an update that downloads to 100%, fails silently, and retries forever, keeping Windows Modules Installer Worker busy 24/7.
Fix #3: Check for pending updates and uninstall the bad one
Sometimes a specific cumulative update is the problem — usually the one installed right before the CPU spikes started. Go to Settings > Windows Update > Update history > Uninstall updates and remove the most recent ones. Reboot and watch Task Manager.
If CPU drops back to normal, you found the culprit. Pause updates for a week (Windows Update > Pause updates) so the same broken package doesn’t reinstall before Microsoft ships a fix.
Don’t disable Windows Update permanently. That’s the advice you’ll read in forums, and it’s terrible. You’ll end up with an unpatched machine and a much bigger problem than high CPU.
Fix #4: Clean boot to rule out third-party interference
Antivirus suites, driver updaters, «optimizers» — many of them hook into Windows servicing and cause conflicts that push Windows Modules Installer Worker CPU usage through the roof. To test this, open msconfig, go to the Services tab, check «Hide all Microsoft services», disable the rest. Then in Startup, open Task Manager and disable all startup apps. Reboot.
If TiWorker behaves normally in clean boot, re-enable services in batches of five and reboot after each batch. When the spike returns, the last batch you enabled contains the offender. Usually it’s a third-party AV or an OEM update tool.
Fix #5: When nothing works — reset Windows Update components or restore
In extreme cases, the update stack is so damaged that even DISM can’t save it. At that point, re-registering the update DLLs manually (wuaueng.dll, wuapi.dll, wups.dll and friends with regsvr32) is worth a shot. It’s tedious but it works more often than people admit.
If that fails, do a system restore to a point before the problem started. Settings > System > Recovery > Open System Restore. Pick a date, restore, done. It’s a sledgehammer, but for a machine that’s unusable because of a servicing loop, it’s faster than chasing ghosts for a week.
Last resort: an in-place upgrade with the Media Creation Tool. It reinstalls Windows over itself, keeps your files and apps, and rebuilds the entire servicing stack. That fixes virtually every Windows Modules Installer Worker issue that survives everything above.
Quick reality check before you panic
Not every CPU spike from this process is a bug. After Patch Tuesday, after a feature update, or after installing a big .NET package, TiWorker.exe can legitimately run at high CPU for 20-40 minutes. Let it finish.
The rule of thumb: if it runs longer than two hours with no update progress visible, treat it as broken. Then follow the DISM-then-WU-reset order. That sequence solves the vast majority of real Windows Modules Installer Worker problems without nuking your system.
