Reset this PC: cloud download versus local reinstall, and why the local one keeps failing

Reset this PC is the button everyone reaches for when a Windows device has gone strange in a way nobody can explain. It looks like one button. It is actually two completely different operations wearing the same label, and the faster of the two is the one most likely to fail on the exact machine you are trying to save.

The problem: two reset sources, and the fast one fails where you need it

Start with what the feature actually is, because the marketing name hides the mechanism.

When a user opens the reset experience they make two separate choices, and it matters that they are separate. The first choice is what happens to their data. The second choice is where the fresh copy of Windows comes from.

So there are four combinations, not two options. Keep my files plus Cloud download is a perfectly normal choice, and it is usually the right one on a machine that is misbehaving.

Here is the failure that sends people in circles. A device is unstable. An admin runs Reset this PC, picks Local reinstall because the site has bad bandwidth, waits through a reboot into a blue recovery screen, and gets back "There was a problem resetting your PC. No changes were made." There is no error code on screen. Nothing in the obvious event logs. The device is exactly as broken as it was an hour ago, minus an hour.

That is the whole thesis of this post. Local reinstall is not a separate, pristine copy of Windows. It is the same Windows you are trying to escape, reassembled.

Why it happens: the engine rebuilds Windows from files that are already broken

Follow the chain from the click to the result. One step at a time.

1. The user opens Settings > System > Recovery and starts the reset. On current Windows 11 builds the Settings admin flow host SystemSettingsAdminFlows.exe launches the experience. On Windows 10 and earlier Windows 11 builds there was also a standalone launcher, SystemReset.exe.
2. The reset engine creates a session. It writes a log folder at C:\$SysReset\Logs and records ResetCreateSession: Succeeded. It loads the SOFTWARE hive from the online OS to read the machine's configuration.
3. The user picks Keep my files or Remove everything, then picks Cloud download or Local reinstall. If Cloud download is chosen, the payload lands in C:\$SysReset\CloudImage.
4. The device reboots into the Windows Recovery Environment. Everything destructive happens there, because you cannot replace the running operating system from inside the running operating system.
5. In WinRE, the engine constructs a new copy of Windows. For Local reinstall, Microsoft states it plainly: push-button reset "restores Windows 10 or Windows 11 by constructing a new copy of the OS using runtime system files located in the Windows Component Store (C:\Windows\WinSxS)".
6. Drivers currently installed on the PC are restored the same way, from the device, not from a factory image. Preinstalled Store apps come back from an automatic backup taken at provisioning time, in their updated state.
7. The old contents are staged aside, then the device boots into the new OS and finishes up. If the reset is interrupted, current builds support a limited rollback while the PC is still in WinRE - older versions of Windows usually just died.

Step 5 is where local reinstall breaks. The component store is not a backup. It is the live servicing database that Windows Update, DISM and SFC all operate on. If a bad update, a failing disk, or an interrupted servicing operation has damaged it, then the source of the rebuild is damaged too. Cloud download exists precisely to break that dependency, and Microsoft says so most bluntly in the documentation for the newer Cloud rebuild feature, which describes downloading the image and drivers from Windows Update so the device comes back "without depending on the integrity of the installed operating system".

Cloud download has its own dependency, and it is one almost nobody tests until the day they need it: networking inside WinRE. The WinRE technical reference is explicit that this is not a normal Windows network stack. "WinRE doesn't maintain general-purpose network connectivity by default. Networking is on only when a recovery workflow requires connectivity." When it is required, WinRE tries Ethernet first, then a Wi-Fi profile pre-configured for WinRE, then eligible saved Windows profiles, then manual selection.

Two more documented constraints shape the choice. Cloud download "isn't supported on LTSC editions", so a kiosk or medical device on the Long-Term Servicing Channel only ever has the local path. And there is a disk-space floor: the FAQ gives the Keep my files requirement as 4GB + size_of_ppkg*0.2 when installed customisations have been converted to file pointers, and 4GB + size_of_ppkg*2 otherwise, where ppkg is the OEM customisations provisioning package. On a 128 GB tablet with 3 GB free, reset fails late, inside WinRE, where the user cannot read the reason.

What survives, precisely

Keep my files is often described as "keeps your documents". The documented behaviour is more specific than that, and the specifics are what generate helpdesk tickets a week later.

One last piece of the mechanism, and it connects to a sibling article. Because the local path rebuilds from the component store, anything that prunes the component store reduces what a local reset can reconstruct. Microsoft is direct about it: because reset restores an updated state, "it's not required nor recommended to mark updates as permanent by using the DISM /Cleanup-Image command with the /ResetBase option". If your image build pipeline runs /ResetBase to shrink the WinSxS folder, you are trading disk space for recoverability. The component store corruption deep dive on this site covers what that folder is and how to check it properly.

How to verify: WinRE state, component store, and the last reset session

Before you press reset on anything, answer three questions with commands rather than hope: is WinRE there, is the local source trustworthy, and has a reset already been tried here?

Start with WinRE. ReAgentc.exe is the in-box tool that registers and reports the recovery environment, and /info is read-only. Run it from an elevated prompt; without elevation it returns nothing useful, which is worse than an error.

Now the local-reinstall dependency. DISM has two different checks and people confuse them constantly. /CheckHealth only reads a corruption flag that a previous scan recorded, so it returns in seconds. /ScanHealth actually walks the store and takes minutes. Use CheckHealth for triage and ScanHealth before you bet a rebuild on it.

System files and folders in the flow

Only these binaries and folders matter, and they live in one place. Parent directory, stated once:

Log files, and the exact strings to search for

The reset engine writes its own logs, in its own folder, which is why nobody finds them. Here is where to look and what to look for.

For the newer Cloud rebuild flow, Microsoft documents a different set to collect from within WinRE: X:\$Windows.~BT\Sources\Panther, X:\Windows\Logs\MoSetup and X:\Windows\Logs\Rebuild.

This is what a real reset session looks like when the user backed out at the option screen. The lines below are genuine, from the device used for this article, with the identifiers left as they were because there are none in this excerpt.

Event Viewer: an honest answer

Microsoft publishes no Event IDs for Reset this PC. There is no operational channel with a documented catalogue of reset events, which is why the log-file table above is the substitute. There is a channel on the box, and it is worth knowing about, with a caveat.

Registry, services and scheduled tasks

Reset state does not live in the registry. WinRE registration lives in ReAgent.xml and in the Boot Configuration Data store, which is why reagentc /info is the tool and not a registry read. There is exactly one documented policy value in this area, and it controls visibility of the Settings page rather than the reset itself. Parent key, stated once:

Services and scheduled tasks are the other honest N/A. There is no Windows service dedicated to Reset this PC and no scheduled task under \Microsoft\Windows\ that drives it - the engine is started on demand by the user or by an MDM instruction and does its work in WinRE. What does exist, on an enrolled device, is the delivery path for that MDM instruction: the enrollment client's tasks under \Microsoft\Windows\EnterpriseMgmt\{enrollment-guid}\, including PushLaunch and Schedule to run OMADMClient by server. A remote wipe or Fresh Start arrives on that channel, not through the Intune Management Extension.

The fix: pick the path the device can finish, then trigger it centrally

The decision is short once you know the dependencies.

1. Check WinRE first. If reagentc /info says Disabled, nothing else on this list works. Fix that before anything else - and if the reason is a recovery partition that is too small for a WinRE servicing update, that is a separate problem with its own article on this site.
2. If the device is broken in a way you cannot explain, choose Cloud download. It does not depend on the integrity of the installed OS. Cost: bandwidth, and a working network inside WinRE.
3. If the device is fine and you are just handing it to someone else, Local reinstall is faster and offline. Verify with /ScanHealth first, not /CheckHealth.
4. If the edition is LTSC, you have only the local path. Budget for USB media as the fallback.
5. If free space is under about 4 GB plus the customisations package, clear space first. Otherwise the failure happens in WinRE, where nobody can read it.
6. If BitLocker is on, confirm the recovery key is escrowed before you start. WinRE cannot read an encrypted volume without the key.

Doing it on the device, step by step

1. Open Settings, then System, then Recovery.
2. Next to Reset this PC, select Reset PC.
3. Choose Keep my files or Remove everything. This is the data decision.
4. Choose Cloud download or Local reinstall. This is the source decision, and the one this article is about.
5. On Additional settings, review the choices. This is where options such as restoring preinstalled apps and, under Remove everything, cleaning the drive are confirmed.
6. Select Next, then Reset. The device restarts into WinRE and the rebuild happens there. Keep it on mains power.

To reach WinRE directly - useful when Windows still boots but the reset UI will not start - use Settings > System > Recovery > Advanced startup > Restart now, or hold Shift while selecting Restart from the sign-in screen. Microsoft also documents WinRE starting automatically after two consecutive failed boot attempts, two unexpected shutdowns within two minutes of boot completion, a Secure Boot error, or a BitLocker error on touch-only devices.

Group Policy: what exists, and what does not

1. Open the Group Policy Management Editor on a GPO linked to the target OU, or gpedit.msc for a single device.
2. Navigate to Computer Configuration > Administrative Templates > Control Panel. The same setting also exists under User Configuration.
3. Open Settings Page Visibility.
4. Select Enabled.
5. In the text box, enter hide:recovery to hide the Recovery page, or extend the list with semicolons, for example hide:recovery;windowsupdate.
6. Select OK, then run gpupdate /target:computer /force on a test device and confirm the Recovery page has gone.

Intune: the same setting, plus the three device actions

The page-visibility policy is in the Settings Catalog, and it is also available as a Policy CSP OMA-URI.

1. In the Microsoft Intune admin center, go to Devices > Configuration and select Create > New policy.
2. Platform Windows 10 and later, profile type Settings catalog, then Create.
3. Name the policy, for example WIN - Settings page visibility, and select Next.
4. In the settings picker, search for Page Visibility List and choose it from the Settings category. There is a device-scoped and a user-scoped variant.
5. Set the value to hide:recovery.
6. Assign to a pilot group, review, and create. For the CSP route instead, use OMA-URI ./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList as a String.

Now the actions that actually reset a device. All three are remote device actions, all three ultimately drive push-button reset, and they differ in what they preserve and which CSP node they exec. This site already has a full comparison of Autopilot Reset, Wipe and Fresh Start, so this is the mechanism table rather than the choose-between guide.

1. In the Intune admin center, select Devices > All devices.
2. Select the device from the list to open its overview pane.
3. In the row of action icons at the top, select Wipe.
4. Choose the behaviour: Wipe device, but keep enrollment state and associated user account for the Keep-my-files equivalent, or Wipe device, and continue to wipe even if device loses power for the protected variant. Leaving both unselected gives the plain doWipe.
5. Select Wipe to confirm. Note the documented tenant limit: 500 Wipe actions per day, cumulative across single actions, bulk actions and Graph calls.
6. Afterwards, decide separately whether to deregister the device from Autopilot and remove its record from Microsoft Entra ID. The wipe does neither.

1. For Fresh Start instead, open the same device pane and select Fresh Start.
2. Select Retain user data on this device if you want the device to stay Entra joined, re-enroll automatically at next sign-in, and keep the user's Home folder.
3. Select OK. Without the retain option, the device is restored to the completed out-of-box-experience state keeping the built-in administrator account, and BYOD devices are removed from Entra ID and MDM.

Graph and PowerShell

Both console actions have documented Graph APIs, and they are ordinary POSTs against a managed device. These change devices, so treat them the way you would treat a delete.

The documented request body for wipe in v1.0 is keepEnrollmentData, keepUserData, macOsUnlockCode, obliterationBehavior and persistEsimDataPlan. The protected-wipe switch, useProtectedWipe, is documented in the beta version of the same action, so if you need doWipeProtected from code today, check the beta contract and accept that beta APIs change more often. One caution on Autopilot Reset: no Graph action named autopilotResetDevice appears in the v1.0 or beta Intune reference, and the Wipe and Fresh Start documentation pages each name their Graph action explicitly while the Autopilot Reset guidance describes the console flow. Treat Autopilot Reset as a console and CSP contract - it lands on the AutomaticRedeployment node of the RemoteWipe CSP - and verify the current reference before you script it.

Defender and security policy: an honest N/A

Nothing in this feature area is governed by Microsoft Defender, attack surface reduction rules, exploit protection, WDAC or a firewall profile. There is no Endpoint Security profile that permits or blocks a reset. The security-relevant facts are the ones already covered and they are documented properties of reset itself: Remove everything deletes files individually rather than formatting the Windows volume, its optional erasure pass does not meet government or industry standards, and WinRE on Windows 11 lets most tools run without an administrator password while noting that "encrypted files won't be accessible unless the user has the key to decrypt the volume". BitLocker, not Defender, is the control that makes a reset safe on a device you no longer physically control.

Proof it worked: real output from a live device

This is a genuine run of the companion script on a Microsoft Entra joined Windows 11 Enterprise device, build 10.0.26200.9168. Identifiers are replaced; everything else is verbatim, including the trailing warnings.

Two things in that output are worth pausing on. First, SystemReset.exe is genuinely absent while the engine binaries are present, which is why any runbook that shells out to systemreset.exe will fail silently on this build. Second, the script found a real cancelled session from 2024 - the kind of forensic breadcrumb that tells you whether a user has already tried and failed to fix this device themselves.

References

• Push-button reset - Microsoft Learn. The feature list, image-less recovery, the Keep my files and Remove everything definitions, the component store pre-scan on Settings-launched resets, the LTSC limitation on Cloud download, and the note that /ResetBase is neither required nor recommended.
• How push-button reset features work - Microsoft Learn. The C:\Windows\WinSxS rebuild source, driver and app restoration, the full preserved-settings list, the refreshed and bypassed folder lists, and the statement that the Windows volume is never formatted.
• Push-button reset frequently-asked questions - Microsoft Learn. The WinRE requirement and Winre.wim location, the 4GB + size_of_ppkg free-space formulas, and the C:\Windows\Logs\PBR log folder.
• Windows Recovery Environment (Windows RE) - Microsoft Learn. WinRE entry points, the automatic-start triggers, the Windows 11 password and encryption behaviour, and the networking section including the WPA-Enterprise and TPM-backed certificate limitations.
• RemoteWipe CSP - Microsoft Learn. Every node with its editions and OS floor: doWipe, doWipePersistUserData, doWipeProtected, the three doWipeCloud variants, and AutomaticRedeployment with its documented Status values.
• CleanPC CSP - Microsoft Learn. The two Exec nodes behind Fresh Start and the edition table showing Pro as unsupported.
• Device Action: Wipe - Microsoft Intune documentation. The console click path, the three Windows wipe behaviours mapped to CSP nodes, the unrecoverable-device warning, and the 500-actions-per-day tenant limit.
• Device Action: Fresh Start - Microsoft Intune documentation. What Retain user data preserves, the roles required, and the CSP and Graph references.
• wipe action - Microsoft Graph v1.0. The request URIs, the DeviceManagementManagedDevices.PrivilegedOperations.All scope, the documented body parameters, and the 204 response.
• cleanWindowsDevice action - Microsoft Graph. The Fresh Start equivalent, with keepUserData.
• Configure the Settings Page Visibility in Windows - Microsoft Learn. The hide: and showonly: syntax, the Settings catalog and OMA-URI paths, and the Control Panel GPO location.
• Cloud rebuild (Preview) - Microsoft Learn. The independence-from-the-installed-OS statement, the WinRE and network prerequisites, error codes 0x800704C6 and 0xc1900200, and the WinRE log collection paths.
• Repair a Windows Image - Microsoft Learn. The documented /ScanHealth, /CheckHealth and /RestoreHealth commands and what each one reports.
• Reset your PC - Microsoft Support. The end-user description of Cloud download versus Local reinstall, and the reminder to have the BitLocker recovery key ready on an encrypted device.

Two notes on scope. Microsoft publishes no data-volume figure for Cloud download on the pages checked for this article, so no number is quoted here - plan for a full OS image and size your bandwidth accordingly. And two adjacent topics are deliberately not re-explained: the recovery-partition free-space failure that blocks WinRE servicing updates, and the component store corruption repair flow, both of which have their own articles on this site.