The update reset button is one of the most used - and most misunderstood - fixes in any toolkit. Here is precisely what it renames, what you lose (less than you fear), and the errors it honestly cannot cure.
Windows Update has a particular talent for getting stuck: the same update fails with the same code, day after day, and no amount of retrying changes anything. Very often the update itself is fine - the cache it is being installed from is corrupt. The fix, whether a button runs it or you type it, is to give Update a clean desk. Here is what that really involves.
Windows Update keeps its working state in two folders. C:\Windows\SoftwareDistribution holds the download cache, the update database and the history records. C:\Windows\System32\catroot2 holds the catalogue files Update uses to verify that packages are genuine. When either becomes corrupted - a download cut off mid-write, a disk error, an interrupted update - Update can get stuck retrying the same broken state forever, showing the same error code on every attempt.
The reset does not argue with the corruption. It stops the three services that hold these folders open, renames the folders out of the way, and restarts the services. Windows Update wakes up, finds its desk empty, and rebuilds everything fresh. The renamed .old folders sit harmlessly in place as your undo button until you are sure the fix worked.
The reset cures a stuck cache. It does not cure a damaged component store - if updates fail with errors that persist after a reset, the deeper repair is DISM followed by SFC (run from the same WinPE), which rebuilds the store the updates install from. It also does not cure a PC whose Windows version has left support, a full system drive (Update needs several GB free to work), or a date and time so wrong that certificate checks fail. Match the tool to the layer that is broken: cache first because it is cheap, store second because it is thorough, and check the obvious (disk space, clock, internet) before both.
One more honest note: after the reset, the first check for updates is slow - Windows rebuilds its database from scratch and may sit at "Checking for updates" far longer than usual. That is the rebuild happening, not a new failure. Give it time before concluding anything.
SoftwareDistribution.old and catroot2.old folders to reclaim the space - or keep them a few days if disk space allows. Deleting them the same minute removes your undo for no benefit.The GUI WinPE repair session in full - watch the fixes run on a real machine, in order.
▶️ Watch Full VideoNo. Installed updates live in the Windows component store, which the reset never touches. What disappears is the history list in Settings and any half-finished downloads. Your Windows stays at exactly the patch level it was - it just gets a clean cache to continue from.
You can, but wait until you have seen one full successful update cycle in the real Windows first. The renamed folders are your only undo if the reset was not the actual problem. Once updates flow again, delete them and reclaim the space - they can hold gigabytes of old downloads.
Move one layer deeper: run DISM with /restorehealth and then SFC, which repair the component store that updates install from. If the error still persists with the same code, the problem is specific - search the exact code, check free disk space and the system clock, and consider that a particular driver or security tool may be blocking that one update.