Windows patching tends to be synonymous with disaster when measured at scale. If you work in IT, you’ve seen what happens when a patch isn’t thoroughly tested before deployment. You might push your schedule back a week or two to audit patches, or you might use a small test environment, but even with all of these measures, Windows 10 (and server derivatives) tends to have more than its fair share of patches which break things and have unintended side effects.
To make it worse, the OS constantly upgrades in place to new versions. Each patch and each version upgrade runs the risk of something not going just right causing patching issues. There are also more and more patches which just plain suck.
Despite the issues being more prevalent with Windows 10, they also tend to be easier to resolve than other versions of Windows. Most issues can be resolved using a mix of sfc and dism, .NET Repair Tool, resetting store components, and resetting the Windows Update cache. Sometimes you may need to run through some of these steps several times, or involve a few outside tools.
This guide assumes you know how to revert a broken update or upgrade and have ruled this out as the issue. If you think a specific update is broken, roll back all of the new updates and try these steps if you still get issues. Research each new patch and see if there are known issues, and more importantly, known fixes for the issues first though.
SFC and DISM
SFC stands for System File Checker and DISM stands for Disk Image Servicing and Management. Both of these tools have been included in various versions of Windows, but they are more effective now than ever. These tools should be your go to for starting to diagnose any Windows issue. When automated with command line tools, they can run in the background with pretty much any RMM or a simple script.
The two main commands you’ll need are:
sfc /scannow
dism /online /cleanup-image /restorehealth
The combination of sfc and dism allow you to approach different sides of a problem in Windows. While dism is much more efficient in how it works, it’s also more fragile. When Windows Update or similar breaks, it does too. You can use sfc to fix other problems, but in a more simplistic way. Though it won’t fix everything, sfc can get a machine stable enough for dism to fix the remaining issues. Sometimes it takes a couple runs through interspersed with reboots.
Another big difference is that sfc has a log located in C:\Windows\Logs\CBS\CBS.log which details what sfc is doing. Though dism has logs, they’re virtually worthless. The CBS.log is worth learning if you work with Windows as an admin, but it’s outside the scope of this article.
.NET Repair Tool
A tool I like to use in conjunction with sfc and dism is the .NET Repair Tool (see here). It runs through some predetermined steps to fix many .NET issues, but it can also touch on certain issues which affect system stability and Windows Update. It can also be automated in a batch file using:
C:\NetFxRepairTool.exe /q /nChange the path to wherever you copy your .NET Repair Tool to. In this example, we use C:\NetFxRepairTool.exe, but you can put it wherever you want. This will run through everything necessary, but some changes will require a reboot to take effect. The tool shouldn’t cause a reboot though.
If you run it manually, just keep clicking next until you get to the collecting logs phase. This won’t really help your problem (directly), but can fix a lot of smaller issues which snowball.
Reset Store Components
This problem is rarer to have to address and can cause issues if not used correctly. Sometimes when you update, everything relying on the store appears to just break. You’ll have issues using your search bar because Cortana is broken, or the calculator won’t work. You might see a flood of DCOM events relating to a store app. If you get weird performance issues and things which depend on the newer store framework having graphical issues or just plain not working, this process may help.
This is one of the few operations I’m going to cover in this article which runs the risk of being destructive outside absurd edge cases. The destruction isn’t bad, but it can require substantial work to fix in certain cases and apps might have to be reinstalled. Don’t just run it because you don’t know what to do and you’ll probably be fine.
That being said, if you can get the OS itself mostly fixed after an update, this operation will almost always be harmless. To run it, open an admin command prompt and run powershell. Once there, run:
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
This will run through and ideally fix these components. You might have to uninstall and then reinstall them manually in some cases. This can be automated via a powershell one-liner or else as a ps1 script. You might see some errors, but most of these are safe to ignore unless you see or find something missing.
Reset Windows Update Cache
This process used to run the risk of being destructive with certain conditions on Windows 7 and older, but is now largely harmless. You might make a problem worse, but not so much worse that the system is unusable if this backfires. All you need is an admin command prompt and to run the following:
sc config wuauserv start= disabled
sc stop wuauserv
ren %windir%\softwaredistribution softwaredistribution.old
sc config wuauserv start= auto
sc start wuauservDelete the old software distribution folder when you have verified the fix works. This cache can take 10 or so minutes to rebuild. Keep in mind that if certain pieces are broken with Windows Update, this won’t do anything. You might have to reboot before or after this depending on how dism and sfc, or the .NET Repair Tool have run and whether you need to run through them again.
Putting It All Together
All of these steps can be trivially automated. I would suggest each one as a separate script and to combine them in other scripts. SFC and DISM are useful for more than just update, but are also essential for Windows Update health.
The .NET Repair Tool does more than just fix broken patches. It can be useful when a .NET update breaks, but might not help for other cases unless one of its tangential features helps. Resetting store components should only be done if something is wrong with them. Hitting the Windows Update cache can be overkill for many more simple conditions.
Scripting Considerations
Each of these makes an important standalone script, but they can be bundled up for a more aggressive system repair process. I always start with sfc and dism and run through that a time or so to see if it can’t bootstrap the repair process. From here, I run the .NET Repair Tool. None of these are destructive processes so I have no qualms running them together, or even scheduling them regularly.
If something is broken with the store or we see certain events as alerts, we can run the reset store components piece. It’s pretty much useless unless the store has or had issues. Resetting the Windows Update cache can be an intense process on older OSes but is usually pretty safe on Windows 10. That being said, it isn’t worth running constantly as the conditions for it to be the right fix are rarer than when it was more dangerous.
If you have no idea where to stop or what’s going on with a Windows 10 or Server 2016, 2019, or later server, run through sfc and dism at least once (twice actually can do more in some scenarios), run the .NET Repair Utility, then reboot when possible. You can slip in resetting the store components after the reboot if you have weird graphical issues. Then, if there are still issues, consider running through sfc and dism again. If you continue to experience issues with Windows Update, reset the Windows Update cache and reboot. You can run through sfc and dism again if paranoid, or take a different approach.
Image by Kira Hoffmann from Pixabay