I learned that uninstalling a Windows update does not restore every file back to its original version before the update and can cause other issues if not removed properly - also as Windows Update are a very complex process you need to monitor to the log files before "assuming" the process has hung!
The checklist I use to remove updates involves several steps, but the key limitation remains: Windows doesn't maintain complete backups of all modified files, so an uninstall will not restore all files.
WinSxS Backup System
When I investigated how Windows handles update rollbacks, I discovered that the WinSxS folder serves as a component store where previous versions of some components are kept. However, this system has significant limitations:
- Time-based cleanup: The system automatically removes backup components after approximately 30 days
- Selective backup: Only core Windows components are typically backed up, not every file an update touches
- Cleanup commands break rollback: Running certain DISM cleanup commands prevents future update uninstallation
How-To : Update Removal
When I need to remove a Windows update, I follow this procedure:
Step 1: Disable Windows Update Service
First, I disable the Windows Update service to prevent automatic reinstallation:
# Open services.msc
# Set Windows Update service to "Disabled"
# Apply changes
Step 2: Uninstall the Update
I use either WUSA or DISM depending on the situation:
# Using WUSA
wusa /uninstall /kb:XXXXXXX /norestart
# Or using DISM for more persistent removal
dism /online /get-packages
dism /online /remove-package /packagename:Package_for_KBxxxxxx~31bf3856ad364e35~amd64~~x.x.x.x /norestart
Step 3: Clean Update Components
I then clean the update infrastructure to prevent reinstallation:
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
Important Limitations
The checklist works for removing the update, but I had to accept that some files might not return to their exact pre-update state. This happens because:
- Not all files are backed up - The WinSxS system primarily backs up core Windows components
- Automatic cleanup removes backups - After 30 days, backup components are automatically deleted
- Manual cleanup breaks rollback - Running component cleanup commands prevents proper uninstallation
The Real Way to Tell If Your System Is Actually Hung
When I first encountered a Windows system hanging at 100% after uninstalling an update, I did what most admins do - I waited, got impatient, and eventually forced a restart. That was a mistake. After years of dealing with these situations, I learned there's a proper technical way to determine if your system is genuinely stuck or just taking its sweet time processing in the background.
Here's the thing about Windows update processes - the progress bar is essentially lying to you. I've seen systems sit at 62.3% for hours during DISM operations, and admins (including myself) assumed they were hung. But they weren't. The system was actively working, just not updating that useless percentage display.
Monitor the Logs
Instead of staring at a stuck progress bar like a deer in headlights, I learned to watch what actually matters - the log files. Here's the command that changed everything for me:
Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 20
This PowerShell command becomes your window into what Windows is actually doing. When I run this during a stuck update process, I can see in real-time whether the system is working or genuinely hung.
What Active Processing Looks Like
When I monitor the CBS.log with this command, active processing shows up as new lines continuously appearing at the bottom of the PowerShell window. The system might be checking files, downloading components, applying changes, or validating integrity - all while that progress bar sits motionless at some arbitrary percentage.
I learned that the system is genuinely busy with "checking, downloading (Only with the /Online switch), applying, checking etc." Even though it looks stuck to the naked eye, the log entries tell the real story.
Key Files to monitor
When troubleshooting these hangs, I focus on two critical log files:
- CBS.log: Located at
%windir%\Logs\CBS\CBS.log- This tracks Component-Based Servicing operations - DISM.log: Found at
%windir%\Logs\DISM\dism.log- This logs DISM operations specifically
The CBS.log is usually the most revealing when dealing with update hangs.
When has it actually Finished?
The definitive indicator I look for is this entry in the logs: "Ending TrustedInstaller finalization." When I see that, I know the process is genuinely complete, regardless of what the GUI is showing.
Terminating Process : Bad Idea
Terminating processes prematurely doesn't help. When you kill a DISM operation that's actually working, it just has to start the entire process over again the next time - checking, downloading, applying, checking. All that time you "saved" by killing it gets wasted when it restarts from scratch.
Hanging Process Checklist
When I encounter a system hanging at 100% after an update operation:
- First, I open PowerShell as Administrator
- Then, I run the tail command on CBS.log to see real activity
- If I see regular log entries, I let it continue regardless of the visual progress
- If no new entries appear for extended periods, I check for timeout errors
- Only then do I consider intervention
Conclusion
I learned that Windows update uninstallation is not the complete restoration process I initially thought it was. The checklist I use can successfully remove updates and prevent them from reinstalling, but it cannot guarantee that every file returns to its exact pre-update version.
For any system administrator dealing with problematic updates, I recommend combining the removal checklist with comprehensive backup strategies. This approach provides the best protection against update-related issues while acknowledging the technical limitations of the Windows update system itself.