In this blog, we’ll walk through a remote wipe issue that leaves devices in a lingering, unmanaged state, where the Intune object is removed, the device appears to remain fully usable, but the reset itself fails with the error There was a problem resetting your PC (0x800f0991) We traced it all back to one broken servicing package, which is related to the Recall feature…. Yes, you heard it right, Recall
There was a problem resetting your PC
We initially stumbled on the “There was a problem resetting your PC” issue after someone on Reddit reported that a remote wipe from Intune appeared to succeed, but the device stayed active and disappeared from Intune. The original poster mentioned it only occurred when using a fully updated custom-built image.
We tried to reproduce the issue using a standard ISO. Before enrolling the device, we manually updated it using the latest Windows Update, but the remote wipe was still successful. Then the same issue was raised again in the Microsoft Commercial Community Program Teams channel.
This time, someone shared both the updated WIM file from the Volume Licensing Center and a Dell recovery ISO. After performing the remote wipe using this custom WIM image, the failure occurred consistently. And that was the breakthrough we needed. As we often say, if we can reproduce it, we can probably fix it. Now that the issue was reproducible, we could finally investigate what was really happening.
The Symptom: A Device No Longer Managed
A remote wipe is typically used to securely reset a device, whether it has been lost, retired, is being repurposed, or is simply broken and no longer functioning as expected. The Remote wipe will remove the organizational data, delete the Intune object, and restore the system to its original state, ready for re-enrollment. But in this case, that didn’t happen.
The remote wipe was triggered from Intune. The device object disappeared from the portal as expected. The BitLocker recovery keys? Gone. LAPS password? Gone. But the device itself remained fully operational. Well, aside from losing all communication with Intune and any ability to actually manage it anymore. There was no real reset. No clean start. Just a reboot followed by a familiar message:
“There was a problem resetting your PC. No changes were made.”
After dismissing the message, the system returned to the login screen, as if nothing had happened. From the IT admin’s point of view, the device was now unmanaged, no longer syncing, and completely orphaned. Still joined to Entra ID, but disconnected from Intune. A zombie machine.
Our first suspicion was storage configuration, maybe RAID or AHCI mode was interfering with the reset process. That’s a scenario we had seen before and documented in a Patch My PC blog. But after confirming with multiple affected users, it became clear: storage wasn’t the issue. So, we dug deeper.
Local Reset vs Remote Wipe
Interestingly, a local reset (using the “Remove everything” option) from the OOBE worked just fine.
That hinted at a critical difference. A local reset is self-contained and reuses the installed recovery image. But a remote wipe leans on the reset engine and the servicing stack in a different way, especially when it comes to validating components and rebuilding. That was our first real lead.
Time to Dive into Logs
We headed straight for the $SysReset\Logs folder to find out why the wipe was failing with the error: There was a problem resetting your PC.
This is where all push-button reset-related activity is logged (read this blog to learn more about the Push-button reset). We pulled in the ETL trace and parsed it with the WPA Tool. If you’re unfamiliar with analyzing ETL traces, this video is a great place to start:
Once opened, the trace revealed a great deal. The ETL trace clearly showed that an SxS (Side-by-Side) corruption had occurred, and the root cause was a missing or corrupt payload file. Time to find out which file that was.
In parallel, we also examined the Component-Based Servicing (CBS) setup logs, which are an important location where servicing failures are logged, particularly during reset or wipe operations. A few things quickly stood out:
- SXS Hydration back to baseline failed for UserExperience-AIX…
- Filename: AIX\zlib1.dll
- Error: 800f0991
Scrolling down the setuperr log, it became very clear that the zlib1.dll file was missing in the userexperience-aix component folder.
It was now obvious that Windows had tried to hydrate that SxS component, to reconstruct the OS from its servicing baseline, but failed when it couldn’t locate a required payload. With no valid zlib1.dll, the servicing engine gave up and aborted the reset process, and showed us the There was a problem resetting your PC error.
We checked the corresponding amd64_userexperience-aix folder inside the c:\windows\winsxs folder, and sure enough, the zlib1.dll file was indeed missing.
That explained the “There was a problem resetting your PC. No changes were made.” error. Reset failed because the required zlib1.dll file wasn’t present. Simple, but buried deep.
See the Issue in Action
If you want to see (instead of reading) how to debug this issue from start to finish, I also recorded a video that walks through the failure. It shows what happens during the remote wipe, how the device drops out of Intune, and where to look in the logs when the reset doesn’t work.
Remote Wipe Failed
But Why That UserExperience-AIX Component?
This raised a bigger question: Why did Windows try to hydrate userexperience-aix at all? What makes that specific package part of the reset process? And how is Windows determining which components to restore in the first place?
That led us into the internals of the servicing stack and how C:\Windows\servicing\Packages and the CBS registry tracks installed packages.
Understanding the Servicing\Packages Folder
When a remote wipe is triggered, Windows relies on the Component-Based Servicing (CBS) engine to determine which components need to be reinstalled or validated. It does this by referencing metadata stored in C:\Windows\Servicing\packages
This folder contains the .mum and .cat files that describe every package registered with the system including version, payload structure, and whether it should be included during reset or servicing operations.
During a reset, Windows:
- Scans this folder to find out which components are present.
- Uses these definitions to verify payloads in WinSxS.
- Rehydrates those components based on their stored metadata.
If a component is listed here, Windows assumes it must be accounted for during reset. And if the matching payload in WinSxS is corrupt or missing (as we saw with zlib1.dll in the userexperience-aix component), the reset fails. Windows has no fallback mechanism for this. It doesn’t skip missing components. The servicing stack halts the entire operation, often with vague or misleading errors like:
“There was a problem resetting your PC. No changes were made.”
That’s why this folder became a critical point of investigation. But before digging too deep into those .mum and .cat files, we also needed to look at what Windows itself believed was installed, and for that, we turned to the Component-Based Servicing registry.
Investigating the Registry and Component State
We checked the Component-Based Servicing registry keys to trace what Windows thought was still installed:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex
- HKLM\…\Packages\UserExperience-AIX-…
In both keys, UserExperience-AIX was still registered. Digging deeper, the Owners subkey showed it was linked to another package: UserExperience-Recall.
That brought back some memories. We remembered how the May 2025 cumulative update introduced early components related to Recall. So naturally, we opened the .mum and manifest files for UserExperience-AIX to see what was inside. Sure enough, there it was:
That confirmed the user experience package was indeed tied to Recall. Even though Recall wasn’t explicitly enabled or used on the system, the servicing engine treated this package as present and required. And because zlib1.dll, was missing from the payload, hydration failed, and so did the remote wipe.
We confirmed that the .mum and .cat files for UserExperience-AIX still existed in the servicing\Packages folder, but the matching WinSxS directory was incomplete. Windows attempted to hydrate the package but was unable to locate the necessary files.
DISM didn’t Help Either to fix it
Before diving into manual cleanup, we tried every standard repair method available. We tried to run the obvious DISM commands:
- dism /online /cleanup-image /restorehealth
And followed it with:
- dism /online /cleanup-image /scanhealth
- dism /online /cleanup-image /checkhealth
Unfortunately, none of the DISM commands made a difference. The system image passed basic checks, but the hydration failure persisted.
DISM wasn’t aware that the payload for UserExperience-AIX was missing. It didn’t flag the package as broken, and it didn’t attempt to reacquire or repair the missing files. From DISM’s perspective, everything looked fine, but the reset engine disagreed.
The end result was the same: every attempt to wipe the device still failed with the error: There was a problem resetting your PC
UserExperience-AIX and Error 0x800f0991
At this point, we fully turned our attention back to the missing UserExperience-AIX package. It was clearly the common thread in every failure. All references to hydration failures, missing payloads, and corrupt file errors pointed to this component. And every time the reset was attempted, the logs would end with:
0x800f0991 PSFX_E_MISSING_PAYLOAD_FILE
A broken zlib1.dll inside the AIX payload was the last straw for the reset process. Windows couldn’t continue unless it could verify and restore that component.
Manual Cleanup: A Risky but Effective Fix
We tried a few conservative options first. The first thing we did was try to export the healthy components, specifically the WinSxS\amd64_userexperience_aix folder, from a clean machine. We attempted to manually restore the missing files and rebuild ownership and permissions where needed. Well… that failed….
We also attempted to delete the registry entries for UserExperience_AIX and UserExperience_Recall in the components registry key, but these edits proved to be unnecessary.
The actual fix was simpler.
Editing Servicing Metadata… Not Recommended, But Justified
As we explained earlier, the reset process uses metadata in the C:\Windows\servicing\Packages folder to determine which components to hydrate. So, we focused there. We took ownership of the .mum and the .cat files for the UserExperience_AIX package and deleted them.
Now, to be perfectly clear, manually removing files from this directory is not something you’d normally recommend. It’s a protected part of the servicing stack. Modifying or removing files from this folder can disrupt update rollbacks or future servicing operations.
But in this case, the device was stuck in a non-resettable state. The choice was either to leave the machine unmanaged and broken or to remove the broken reference and allow Windows to rebuild itself. That made the decision easy.
Once the component metadata was gone, Windows no longer treated the package as required. The reset process was free to continue, and the OS was rebuilt from scratch
Aftermath: The Reset Worked
After removing the .mum and .cat files for the UserExperience_AIX package, we triggered another remote wipe. This time, as hoped and somehow expected, it worked. The There was a problem resetting your PC error was no longer showing!
No error. No rollback. The device rebooted, completed the reset, and returned to the out-of-box experience.
That confirmed it. The corrupted servicing metadata had been blocking the reset. Once those files were removed, Windows no longer attempted to hydrate the broken component, and the wipe was finally completed successfully. From there, we pushed a PowerShell script to those broken devices to ensure that the broken component was removed during the rebuild.
https://patchmypc.com/app/uploads/2025/07/fix-remotewipe.zip
This script above will find the proper userexperience-aix mum and cat files. From then on, it would delete them after taking ownership of those files. So, my advice is don’t blindly deploy this script to all of your devices, but send it out to the device before performing the remote wipe using the “Run Remediation on Demand” Feature first!
The Real Fix: Update the WinRE accordingly
If deleting mum and cat Files feels like a desperate move… well, it probably is. Let me show you what happened (or maybe didn’t happen) with the winre.wim image in the first place.
When you’re building a custom WIM or servicing an image offline, it’s easy to focus only on the main Windows image. But Windows also includes a separate recovery environment (WinRE), and if that recovery image isn’t patched to match the OS version, things can break. Badly. As shown below, the WinRE was still on 1710, while the device itself was on 4648
That mismatch can cause reset operations to fail in strange and frustrating ways. Even if the OS image is fully patched, the reset engine might boot into WinRE and choke because it’s still using outdated components or missing something critical. And yes, this will give you the “There was a problem resetting your PC” error.
In this case, the main Windows image was updated, but WinRE was left behind. When the remote wipe triggered a reset, Windows launched into an outdated recovery environment that didn’t contain the necessary components. That’s what really caused the failure. As shown below, the WinRE was now patched to 4648. With the WinRE being patched, we could now successfully wipe the device
Microsoft is clear on this in their documentation; if you update the OS image, you need to update the recovery environment as well. The steps for that are outlined here.
To automate this process, I wrote this PowerShell script, which downloads the latest Safe OS patch (KB5062688), mounts the WinRE, and patches it.
Update Windows During OOBE, Not by Updating the WIM
Maybe an even better and much safer approach, instead of injecting updates manually into the WIM, is to use the Quality Update during the OOBE feature. This allows Windows to apply the latest cumulative update during the out-of-box experience, after Autopilot enrollment has completed, but before the user reaches the desktop.
The update is downloaded and installed as part of provisioning. It avoids the mess that comes with offline servicing. There is no need to inject updates into the image and risk breaking something later.
Update (August 2025):
Microsoft has officially confirmed this issue after the August 2025 Windows security update. Attempts to reset or recover a device may fail across multiple versions of Windows 10 and 11 when using “Reset this PC,” “Fix problems using Windows Update,” or the RemoteWipe CSP in Intune.
Well, that’s sounds exactly the same as we discussed above, I would say?
Microsoft is preparing an out-of-band update to address this. Until then, the remediation steps we outlined earlier in this blog remain essential.
Final Thoughts
Missing drivers or corrupted system files did not cause this reset failure, it was caused by an outdated WinRE image that was never updated after servicing the main WIM. The faulty component? Servicing components related to Recall!
A system reset/wipe depends on both the system image and the recovery image being in sync. Windows rebuilds itself using a mix of what is defined in the servicing packages folder and what exists in the component store. If the recovery environment does not contain the files needed to hydrate a listed component, the reset fails.
That is what happened here. The UserExperience AIX (Recall) package was listed in the servicing metadata, but the required payload was not present in the WinSxS. Windows had no way to recover, and the result was the “There was a problem resetting your PC” error and a broken, unmanaged device.
This issue also shows why blindly injecting updates into a WIM can be risky. If you are not updating WinRE along with it, you are leaving the system in an inconsistent state that may only break later, during reset or provisioning.