Reagentc broken, different errors with different GUIDs set for partition

[Kenjitsuka]

Hi, I have been very hard at work fixing a Windows 10 PRO install with broken Windows Update. I noticed in a log that Reangentc was broken, so I set out to fix it. The problem is I accidentally deleted the recovery partition months ago after an SSD migration, since it looked like unused space.

Anyway, I created a winre.wim file and a partition according to instructions found online. They could not agree on wheter the partition needed to be an “EFI System Partition” with GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B or a “Windows Recovery Environment partition” with GUID DE94BBA4-06D1-4D40-A16A-BFD50179D6AC. I have tried both, but whenever I followed all the steps in all guides that end with an optimistic “reagentc /enable” I am met with errors. Different ones for different GUIDs:

If the GUID is C12A7328-F81F-11D2-BA4B-00A0C93EC93B I fail at the following command:

Reagentc /setreimage /path \\?\GLOBALROOT\device\harddisk2\partition3\Recovery\WindowsRE /Target C:\Windows
REAGENTC.EXE: The Windows RE image cannot be stored in the specified volume. Use the RETAIN command in DISKPART to prepare the volume and try again.

I am afraid using “Retain” might destroy my ability to boot Windows, and official MSFT documentation is super sparse! Any guidance on how/what retain command to use?

If the GUID is DE94BBA4-06D1-4D40-A16A-BFD50179D6AC instead it gives:

Reagentc /setreimage /path \\?\GLOBALROOT\device\harddisk2\partition3\Recovery\WindowsRE /Target C:\Windows

Directory set to: \\?\GLOBALROOT\device\harddisk2\partition3\Recovery\WindowsRE
REAGENTC.EXE: Operation Successful.

Reagentc /enable
REAGENTC.EXE: Operation failed: 3bc3

Really at the end of my rope here, so hoping a hero(in) can help me out! Thanks so much in advance!!!

I looked into the log file, and this seems relevant:

RegLoadKey $OFFLINE$SYSTEM failed. Error: 0x522.
2025-09-09 14:52:48, Info [ReAgentc.exe] OEM partition, copying boot.sdi
2025-09-09 14:52:48, Info [ReAgentc.exe] boot.sdi copied
2025-09-09 14:52:48, Info [ReAgentc.exe] Creating BCD entry
2025-09-09 14:52:48, Error [ReAgentc.exe] open store failed: 0xc0000452
2025-09-09 14:52:48, Info [ReAgentc.exe] Failed to create BCD recovery entry 15299
2025-09-09 14:52:48, Info [ReAgentc.exe] SetWinRESettings return with error code 0x3bc3
2025-09-09 14:52:48, Error [ReAgentc.exe] failed to set WinRE settings, error:0x3bc3

 

[DerHabbo]

Assuming the partition is accessible and all that, before attempting to alter the partition path, shouldn't you set reagentc to /disable, set the path and then /enable?

 

[Kenjitsuka]

Thanks for the advice, DerHabbo!
The initial problem was it was disabled, probably because I deleted it's partition.
But just to be sure I tried your suggestion anyway. No luck, unfortunately:

C:\windows\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Disabled
    Windows RE location:
    Boot Configuration Data (BCD) identifier: 0dbe2759-f81b-11ea-8fa3-fccbe4d8caa1
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

REAGENTC.EXE: Operation Successful.

C:\windows\system32>reagentc /disable
REAGENTC.EXE: Windows RE is already disabled.

 

[DerHabbo]

Okay... well I know how I would... did correct this for my fleet but I'm not really proposing this for the sheer impracticality.
On background: The previous guy responsible for imaging the Win 10's couldn't get the recovery partition to work through the deployments xml answer file so he just left it out. When I had to retrofit the system instead of using WIM files in WDS I installed MDT on top of WDS and set it up for thin deployments with litetouch PE as the preboot (replaced WDS boot.wim with the litetouch pe .wim that MDT generates). I set it up in workgroup, which the documentation doesn't cover, but in short the default stored procedure has the partitions set up correctly, litetouch supports ipu by backing up the existing OS volume to the WDS server's deployment share (probably have to decrypt bit locker first? Didn't use this feature but it would allow you to preserve the dirty OS).
So if you have access to a WDS server this might make sense? When we're talking a single endpoint clean install deleting the partitions and using external media probably makes more sense than the logistical hoops to preserve the OS. If your goal is just to fix the dirty OS and the recovery partition is just a means to an end you could boot to a recovery partition on external media, but I assume you are trying to fix it "proper". Forgive my rambling train of thought cadence. Hope something there is useful.

https://learn.microsoft.com/en-us/p...s-mdt/prepare-for-windows-deployment-with-mdt

 

[Kenjitsuka]

Thanks so much for your help, DerHabbo! I really appreciate it!
Unfortunately I don't have access to a WDS server, nor experience with MDT and WDS.
I've looked into it, but decided I'll just ignore the fact that Reagentc is broken and focus on my other problem.

The main issue was and is that Windows Update is broken, and log files revealed two problems:
Reagentc broken AND no System Partition.
Since the Reagentc seemed less dangerous to mess with I focused on fixing it first.
But I suspect the real issue is "no space on SRP, since the SRP got deleted".

I'm going to remake the SRP, and I hope these are the correct commands.
The system is currently booting from this drive, so messing with it could be a disaster...

select vol 2 'where #2 is your EFI partition 100 MB FAT32
assign letter=Y
format quick fs=fat32 label=EFI
set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
exit
bcdboot C:\Windows /s Y: /f UEFI

 

[Kenjitsuka]

SRP didn't do anything useful either!
But the below solution fixed EVERYTHING for me!!!
I'll include it here in case anyone ever stumbles on it, with the same issues:

You do not need to rebuild WinRE or touch DiskPart RETAIN to fix 0x800f0905. That code is almost always a servicing stack or component store problem. Try to do a repair install of Windows 10 in place using the latest 22H2 ISO. It keeps your apps, files, and settings, and it rebuilds the servicing stack, component store, and boot files.

On the affected PC, sign in with an admin account, free up at least 20 GB on C:, and disconnect non-essential USB devices and any secondary drives so Setup cannot place boot files on the wrong disk. If you run third-party antivirus, disable it temporarily.

Get the current Windows 10 ISO from Microsoft using Media Creation Tool on this same machine so edition and language match. Right-click the ISO in File Explorer and select Mount, then run setup.exe from the mounted drive. When asked about updates, choose "Change how Setup downloads updates", then pick "Not right now". Accept the license, when prompted choose "Keep personal files and apps", and continue. The machine will reboot several times. You will land back on the desktop with your programs intact.

After the first sign-in, let services settle for a minute, then open Windows Update and install the pending cumulative update again. If you want to double-check the health of the component store, you can run DISM /Online /Cleanup-Image /RestoreHealth followed by sfc /scannow, but in most cases the in-place repair already fixed what DISM could not. If WinRE matters to you later, run reagentc /info. If it is Disabled, leave it for now.

Note: Windows Update does not require WinRE to be enabled, and trying to force RETAIN or juggling GUIDs on recovery partitions is both unnecessary for updates and easy to get wrong. If you eventually want WinRE back, we can do that cleanly in a separate pass with the correct DE94BBA4 GUID and attributes, once updates are working.

 

[DerHabbo]

SRP didn't do anything useful either!
But the below solution fixed EVERYTHING for me!!!
I'll include it here in case anyone ever stumbles on it, with the same issues:

D'oh. Classic example of overthinking the problem when the simplest solution is probably the correct one. TBF, It did throw a bit of a red herring as to what the actual cause was.