Built a self-healing WinRE manager for Windows 11 — sharing the failure modes and what I learned about the recovery partition lifecycle

ArthurDurand, thanks for separating the field results from the untested paths. The post-deletion failure on encrypted C: is the part I’d prioritize before broader deployment, ahead of adding more OEM recipes.
I don’t have personal fleet results to contribute, and this isn’t a code audit, but here’s how I’d approach the failure modes you described.

Diagnose separately; repair minimally​

1. Establish the actual failure first: capture the failing KB, reagentc /info, partition layout and free space, target-volume encryption state, and servicing logs. I wouldn’t authorize repartitioning from the update error alone.
2. Separate registration, capacity, and driver remedies. I’d prefer an insufficient-space repair not to trigger driver replacement unless driver validation independently fails.
3. Require a recovery plan before partition changes: a verified backup, accessible BitLocker recovery key, and external recovery media tested on that machine. Given your acknowledged failure window, I’d make destructive paths explicitly opt-in and subject to review.
4. Validate beyond registration: my acceptance test would include booting into WinRE, confirming that it sees the OS disk, and checking that the next run makes no changes—not just accepting reagentc /enable exit 0.

Points worth tightening​

• KB5034441 is a Windows 10 example, not a Windows 11-specific failure. Microsoft retired it and moved its content to KB5042320 in August 2024. That update explicitly requires 250 MB of free space, rather than a particular total partition size. It’s a useful analogy, but I’d distinguish it from your Windows 11 cases.
• Driver completeness matters more than a zero-driver baseline. Microsoft’s guidance is to include the third-party drivers required to boot. My concern with stripping everything is whether the replacement recipe proves that coverage for each machine; I’d make an image containing pre-existing OEM drivers a release-gating test.
• Keep the encryption observation scoped to the tested systems. Your ASUS results are useful evidence, but I’d want timestamped partition-type and encryption-state observations before treating the “claimed before GUID assignment” explanation as a general 24H2+ mechanism.

Two implementation questions interest me most: what exact size/headroom calculation rejected 1,000 MiB but accepted 1,100 MiB, and does the race detector compare image content or just path, size, and timestamps? I’d also distinguish “detects a change during preparation” from “prevents a change after the final check.”

ArthurDurand said:

Hi all,

I've been reading the recovery partition threads here for a while and wanted to share something I built. It's a PowerShell script that manages the Windows Recovery Environment — it repairs broken WinRE registrations, rebuilds winre.wim with the correct drivers, and resizes recovery partitions that have been outgrown by Windows Updates. MIT-licensed, single file.

I built it because three Windows 11-specific failure modes kept breaking machines:

1. 0x80070643 after KB updates. Windows pushes a WinRE update that requires more space than the OEM's recovery partition has. The update fails, and the partition is technically present but undersized by 50–200 MiB. This is the one that generates the most "Windows Update broke my recovery" threads here.

2. Device Encryption on 24H2+. The encryption service claims a newly created partition before the recovery type GUID can be applied. reagentc /enable then refuses with "Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled." The machine has a recovery partition, but WinRE cannot use it.

3. VMD storage drivers missing from WinRE. On 12th-gen Intel and later, the recovery image needs the Intel VMD driver to see the OS disk. Without it, Startup Repair and Reset this PC fail with INACCESSIBLE_BOOT_DEVICE.

The script runs idempotently. On a healthy machine it takes a fast path — no WIM mount, no partition touch, no reagentc call. On a broken machine it does a full rebuild: strips the image to zero third-party drivers, injects the correct OEM/VMD recipe, resizes the recovery partition, and re-registers WinRE.

What took the longest to get right:

• The reagentc /disable → /enable window. Everything that doesn't require a disabled WinRE runs before the disable. A race detector re-reads the registered image immediately before /disable and aborts if Windows Update serviced it during preparation.
• Target-volume BitLocker policy. reagentc checks the target volume, not C:. The dedicated-partition and enable-only paths don't care about C:'s encryption state. Only the OS-fallback route does.
• Driver strip normalization. Every rebuild strips the mounted image to zero third-party drivers, proven by re-enumeration, before injecting the current recipe. Otherwise drivers accumulate across rebuild cycles.

Field-verified on:

• Dell Pro Max 16 (Core Ultra 7) — full rebuild, 64 drivers injected, 1,000 MiB partition rejected as undersized, new 1,100 MiB partition created, reagentc /enable exit 0
• Two ASUS Vivobooks (both mid-encryption at 91%) — dedicated-partition path completed, new partition not re-claimed by Device Encryption
• ASUS PRIME H510M-D — fast path, DEDICATED, exit 0

What it doesn't do yet:

• The strip stage hasn't been exercised against a source image with third-party drivers in production
• The destructive partition paths are VM-tested but not physical-hardware-tested under the current code
• A known residual corner: a post-deletion failure on an encrypted C: can leave the machine without a dedicated recovery partition or OS-fallback

Repo is github.com/ArthurJDurand/WinRE-Manager if anyone wants to look at the code. More interested in the failure modes than the tool — if you've hit the KB5034441 class of failures, how are you handling it?

Click to expand...

One additional thing you can check is whether WinRE still works after a successful rebuild by running `reagentc /info` and testing Windows Recovery from Advanced Startup. A successful registration alone does not guarantee that recovery will work when you actually need it. You can also verify that the recovery image can access the system drive before relying on Startup Repair or Reset this PC. Since the destructive partition paths have not yet been tested on physical hardware, you should keep a verified backup before running them on your primary machine.

ArthurDurand said:

Hi all,

I've been reading the recovery partition threads here for a while and wanted to share something I built. It's a PowerShell script that manages the Windows Recovery Environment — it repairs broken WinRE registrations, rebuilds winre.wim with the correct drivers, and resizes recovery partitions that have been outgrown by Windows Updates. MIT-licensed, single file.

I built it because three Windows 11-specific failure modes kept breaking machines:

1. 0x80070643 after KB updates. Windows pushes a WinRE update that requires more space than the OEM's recovery partition has. The update fails, and the partition is technically present but undersized by 50–200 MiB. This is the one that generates the most "Windows Update broke my recovery" threads here.

2. Device Encryption on 24H2+. The encryption service claims a newly created partition before the recovery type GUID can be applied. reagentc /enable then refuses with "Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled." The machine has a recovery partition, but WinRE cannot use it.

3. VMD storage drivers missing from WinRE. On 12th-gen Intel and later, the recovery image needs the Intel VMD driver to see the OS disk. Without it, Startup Repair and Reset this PC fail with INACCESSIBLE_BOOT_DEVICE.

The script runs idempotently. On a healthy machine it takes a fast path — no WIM mount, no partition touch, no reagentc call. On a broken machine it does a full rebuild: strips the image to zero third-party drivers, injects the correct OEM/VMD recipe, resizes the recovery partition, and re-registers WinRE.

What took the longest to get right:

• The reagentc /disable → /enable window. Everything that doesn't require a disabled WinRE runs before the disable. A race detector re-reads the registered image immediately before /disable and aborts if Windows Update serviced it during preparation.
• Target-volume BitLocker policy. reagentc checks the target volume, not C:. The dedicated-partition and enable-only paths don't care about C:'s encryption state. Only the OS-fallback route does.
• Driver strip normalization. Every rebuild strips the mounted image to zero third-party drivers, proven by re-enumeration, before injecting the current recipe. Otherwise drivers accumulate across rebuild cycles.

Field-verified on:

• Dell Pro Max 16 (Core Ultra 7) — full rebuild, 64 drivers injected, 1,000 MiB partition rejected as undersized, new 1,100 MiB partition created, reagentc /enable exit 0
• Two ASUS Vivobooks (both mid-encryption at 91%) — dedicated-partition path completed, new partition not re-claimed by Device Encryption
• ASUS PRIME H510M-D — fast path, DEDICATED, exit 0

What it doesn't do yet:

• The strip stage hasn't been exercised against a source image with third-party drivers in production
• The destructive partition paths are VM-tested but not physical-hardware-tested under the current code
• A known residual corner: a post-deletion failure on an encrypted C: can leave the machine without a dedicated recovery partition or OS-fallback

Repo is github.com/ArthurJDurand/WinRE-Manager if anyone wants to look at the code. More interested in the failure modes than the tool — if you've hit the KB5034441 class of failures, how are you handling it?

Click to expand...

You can also add a warning about suspending BitLocker protection before making any recovery partition changes and verifying that you have your BitLocker recovery key saved somewhere safe. Another thing worth checking is whether Windows has pending updates or a restart waiting before rebuilding WinRE because that can interfere with the recovery image registration. I'd also recommend testing the recovery environment with reagentc /info and confirming that Startup Repair can actually detect the Windows installation after the rebuild. A successful reagentc /enable alone doesn't guarantee that recovery will work when you need it.

datawizard0103 said:

You can also add a warning about suspending BitLocker protection before making any recovery partition changes and verifying that you have your BitLocker recovery key saved somewhere safe. Another thing worth checking is whether Windows has pending updates or a restart waiting before rebuilding WinRE because that can interfere with the recovery image registration. I'd also recommend testing the recovery environment with reagentc /info and confirming that Startup Repair can actually detect the Windows installation after the rebuild. A successful reagentc /enable alone doesn't guarantee that recovery will work when you need it.

Click to expand...

Thanks — these are the right questions, and it's worth being precise about the BitLocker policy because it changed substantially in v43 patch 5.

The script does not suspend BitLocker on C: and it never has since v43 patch 5 (further revision 5). The earlier revision did suspend C:'s protection to prevent a specific failure mode; the v43 patch 5 (further revision 5) work established — via a same-machine test on 2026-09-29 — that reagentc's BitLocker check is on the target volume, not on C:. With C: in the FullyEncrypted / Protection Off state, reagentc /enable against a dedicated recovery partition succeeded; reagentc /enable against the OS volume failed on the same machine in the same session. That inverted the policy.

Consequences for the safety posture:

• C:'s BitLocker state is never modified. No manage-bde -off C:, no Suspend-BitLocker C:, no key-protector changes. The design specifically makes an encrypted C: not a reason to defer or interfere. Eight distinct physical machines have completed destructive rebuilds with C: mid-encryption and the guard-free path succeeded; CHANGELOG.md's v44 patch 7 entry records the eight-machine evidence.
• Only the target recovery partition is prepared. Set-RecoveryPartitionReadyForWinRE runs manage-bde -off <target> against the newly created or reused recovery partition if the Device Encryption service has claimed it — typically because the recovery type GUID was applied a moment too late. This is a partition the script just created (or reused as a dedicated target), not C:. Decrypting a recovery partition removes BitLocker metadata from a volume that should never have carried it; it does not touch C:'s protection state or key protectors.
• The one BitLocker-dependent route is OS-fallback. If dedicated-partition creation fails and the script falls back to C:\Recovery\WindowsRE, the target is C:. The OS-fallback gate reads C:'s VolumeStatus and defers unless it reads FullyDecrypted. That is the only case where C:'s state can block the run — and in that case, deferring is the correct outcome, because the script does not modify C:'s BitLocker state.
• Recovery-key backup. Because the script never suspends protection or alters key protectors on C:, no operation it performs triggers a recovery-key prompt or requires a key backup. "Have your recovery key saved before any disk operation" is universally good hygiene, but it is not a WinRE Manager-specific gap. If a machine has an unbacked recovery key and an unrelated disk operation goes wrong, that is a general BitLocker best-practices concern outside the manager's scope. The manager does not change C:'s key protectors or C:'s BitLocker state.
• Suspension-vs-decryption. Your note that "BitLocker resumes after a reboot if suspended" is correct for Suspend-BitLocker (it defaults to single-reboot resume). But the script uses manage-bde -off on the target, which is full decryption — the right operation for a recovery partition that should never have carried BitLocker in the first place, and one that never touches C:.

On pending Windows updates. This is a genuine concern, and the script addresses the specific failure mode. The scenario that matters is Windows Update servicing the registered WinRE between source acquisition and the deployment switch — which would silently deploy a candidate derived from a source that has since been replaced. A pre-/disable race detector re-reads the registered WinRE's location, version, and WIM SHA256 immediately before whichever reagentc /disable the execution reaches first; any change aborts the run before /disable. There is also an ImageState guard that defers on Audit Mode / OOBE / sysprep, which is the other common timing hazard. A general "pending Windows updates" check is not implemented — the failure mode that matters is Windows Update re-servicing WinRE mid-run, which the race detector catches, not pending updates in the abstract.

On Startup Repair verification. You're right, and the project's documentation says so explicitly. reagentc /info reporting Enabled, matching SHA256 on the deployed bytes, and the storage-applicability gate together establish registration and structural fitness, not recovery boot. docs/testing.md names the boot test as the acceptance step that isolated suites and registration checks do not replace. The 2026-10-24 Hyper-V validation includes a successful Startup Repair boot into WinRE with the OS disk visible to the recovery environment.

Fleet vs. interactive. The production script's daily operation is unattended — it runs as a SYSTEM scheduled task. Interactive confirmation is the wrapper's role: WinRE-Manager.cmd requires typing RUN before a live repair and RESTORE before a restore, presents backup (option 1, SAFETY section) above the live repair (option 7, REPAIR section), and documents the canary/early/broad ring model for fleet rollout in docs/deployment.md. A first-time user is guided to preview, backup, then repair. The first-run recommendation of "keep a verified backup before running on your primary machine" is precisely what the wrapper encourages.

The outstanding release gates are documented in CHANGELOG.md and docs/testing.md — they concern specific failure transitions under specific conditions, not whether the destructive path works at all.