If you've ever stared at a progress bar stuck at 67% for what feels like forever, you're not alone. Security updates on Windows are notorious for their sluggish installation times, and the reasons behind this are more technically layered than most users realize. This article breaks down the core factors that contribute to the delay — and what, if anything, you can do about it.
Designed as a Background Task
One of the core design philosophies behind modern Windows Update is that it should be as unobtrusive as possible. Microsoft has engineered the update process to handle the majority of installation work while the system is still running — so that the offline reboot phase (the part where the screen shows "Installing updates...") is kept as short as feasible.
The trade-off of this approach is that the background installation process is intentionally throttled to avoid interfering with active user tasks. This means that while your machine may appear idle, a substantial amount of file writing, patching, and preparation is happening quietly in the background — and it simply takes time.
Cumulative Updates and Their Trade-offs
Starting with Windows 10, Microsoft shifted to a cumulative update model. Rather than shipping dozens of small individual patches, each update package now contains all previous patches bundled together. The practical benefit is significant: a freshly installed Windows machine only needs the latest cumulative update to be fully patched, rather than having to apply hundreds of historical fixes in sequence.
The downside is size and complexity. Because each cumulative update carries the full history of changes, the packages are considerably larger than the individual patches of the Windows XP or Windows 7 era. More data to decompress, verify, and write to disk translates directly into longer installation times.
.NET Framework and Assembly Processing
A significant portion of the longest-running updates involve the .NET Framework and the Windows component ecosystem that depends on it. Unlike native binary executables, .NET assemblies are distributed in an intermediate compiled format that must be further processed (via a tool called ngen — the Native Image Generator) to generate optimized, machine-specific cached versions.
When a .NET-related update arrives, the system may need to regenerate cached native images for a large number of assemblies. Observers monitoring update activity with tools like Sysinternals Process Monitor have noted tens of thousands of file write operations occurring inside .NET runtime folders during these updates, along with log entries referencing "updating assemblies." The WinSxS folder — which stores multiple versions of system components — can grow by several gigabytes as a result.
It is worth noting that ngen operations are typically scheduled during idle time rather than during the active installation phase. However, a large portion of assembly-related processing does appear to occur within the update window itself, which contributes to the overall duration.
File System and Hardware Bottlenecks
The nature of Windows updates involves writing a very large number of small files scattered across various system directories. This access pattern is particularly taxing on traditional spinning hard disk drives (HDDs), which must physically seek to different locations on the platter for each file write. Users still running HDDs as their primary system drive will experience noticeably longer update times compared to those on solid-state drives (SSDs or NVMe drives).
This is one reason why disk activity can spike to 100% during updates — not because the processor is working hard, but because the storage device is being pushed to its limits handling thousands of small, scattered I/O operations. On an SSD, the same workload completes dramatically faster due to the absence of mechanical seek time.
| Storage Type | Update Speed | Notes |
|---|---|---|
| NVMe SSD | Fastest | Handles small random writes efficiently |
| SATA SSD | Fast | Significant improvement over HDD |
| HDD (7200 RPM) | Slow | Mechanical seek overhead adds up quickly |
| HDD (5400 RPM) | Very Slow | Common in budget laptops; update stalls are frequent |
The WinSxS Folder and Version Management
Windows maintains a folder called WinSxS (Windows Side-by-Side) that stores multiple versions of system components simultaneously. This architecture exists to ensure backward compatibility — applications that were built against older versions of system libraries can continue to function even after those libraries are updated.
The practical consequence is that the WinSxS folder can grow very large over time, sometimes occupying tens of gigabytes. Each update may add new component versions while retaining older ones for compatibility purposes. The "Windows Update Cleanup" option in Disk Cleanup (cleanmgr) exists specifically to remove superseded component versions — though this process itself can take a considerable amount of time for the same reasons updates do.
Can You Use Your PC While Updates Install?
In most cases, yes. The background installation phase is designed to run alongside normal usage. The phase that requires your machine to be unavailable is the reboot phase, during which offline component swapping takes place — and on modern hardware with an SSD, this offline phase typically completes within a few minutes.
However, there are exceptions. Heavy updates — particularly those involving .NET components or large cumulative packages — can cause noticeable disk contention and system sluggishness during background installation. Users on older hardware or spinning hard drives may find their machines effectively unusable during these periods, as disk activity saturates the drive's I/O capacity.
Practical Considerations for Users
- Upgrading to an SSD is the single most impactful hardware change for reducing update times on older machines. The difference between an HDD and an SSD for this specific workload can be measured in hours versus minutes.
- Defender signature updates (security definitions) can be applied separately and quickly via PowerShell using Update-MpSignature, which avoids the heavier cumulative update process entirely when only signature freshness is needed.
- Manually downloading .msu files from the Microsoft Update Catalog and running them directly is reported by some users to install faster than the standard Windows Update delivery mechanism.
- Waiting a few days after a major update release before installing is a reasonable practice for non-critical systems, as early adopters sometimes encounter installation failures or post-update regressions that are subsequently patched.
Note: The behaviors described in this article reflect general patterns observed across a range of hardware configurations and Windows versions. Individual experiences may vary significantly depending on system specifications, installed software, and the specific update package involved.
Post a Comment