WinRE Manager v49 — open-source PowerShell tool for WinRE repair and recovery-partition rebuilds

The problem

Windows' recovery environment breaks in ways that don't announce themselves. KB5034441 and its successors needed a larger recovery partition than most OEMs shipped — the update fails, and the machine is left with a recovery partition that's 50–200 MiB short. On Windows 11 24H2+, Device Encryption can grab a newly created partition before the recovery type GUID lands, and reagentc /enable then refuses with "Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled." And on 12th-gen Intel and later, the recovery image needs the Intel VMD driver just to see the OS disk — miss it, and Startup Repair fails with INACCESSIBLE_BOOT_DEVICE.

None of these are obvious until the machine is already in trouble, and none of them are fixed by the usual "just run reagentc /enable" advice.

What WinRE Manager is

A single PowerShell 5.1 script that repairs all three classes of failure idempotently. On a healthy machine it takes a fast path — no WIM mount, no partition touch, no reagentc call. On a broken machine it runs the full pipeline: source selection, image servicing, driver injection, partition work, deployment, and registration repair. MIT-licensed. No dependencies beyond PowerShell and 7-Zip.

It supports Windows 10 and 11, dedicated recovery partitions and OS-fallback registrations, GPT and MBR disks.

What v49 patch 1 adds — the safety work

The earlier versions of this tool did the job, but they trusted their own inputs more than they should have. v49 is the release where that changed. Every one of the following is a refusal path — the tool stops before touching the machine rather than proceed on an unverified assumption:

- Source-ownership classification. Before stripping and re-injecting drivers, the tool classifies the source WIM. A WIM that a vendor populated with its own drivers is preserved as-is rather than normalized. This came from a real incident on an ASUS machine whose storage controller wasn't in the manifest's VMD patterns — an unconditional strip would have removed the only working driver.
- Never-downgrade storage-driver check. If injecting the current recipe would replace a storage driver with an older version than the source already had, the whole candidate is discarded and the source is preserved. No partial fixes.
- Pre-deployment storage-applicability gate. Before the new WIM is written to the active recovery route, every present SCSIAdapter-class device must have at least one matching INF in the candidate image. This is the last refusal before deployment.
- Native-boot VHDX fail-closed gate. If the running OS disk is a file-backed virtual disk and any other disk is on a physical bus — the native-boot VHD/VHDX topology — the tool refuses destructive partition operations. Without this, the host's recovery partition could be mistaken for a stray.
- Transactional WIM replacement. Replacing the WIM on the active route now preserves the previous WIM as a rollback copy until the new one is verified in place. A failed copy restores the old one instead of leaving the machine with no usable WIM.
- Temporary crash-recovery task. Every Repair or Restore run registers a "WinRE Manager - Resume" task that fires at boot+1m and T+1h. It's deleted on clean completion and preserved on interruption — including Ctrl+C, which required a compiled ConsoleCancelKeyPress delegate because PowerShell's finally runs but catch doesn't on that interruption.

Two other v49 additions for operators who run this across a fleet:

- Backup and restore actions. -Action Backup captures a byte-for-byte copy of the registered WinRE WIM plus sidecar metadata. -Action Restore writes it back transactionally. Neither touches the repair pipeline.
- Run summary and narration. A structured summary (Result, Decision, Why, Work performed, Changes made, Changes NOT made, Operating mode, Next action) alongside the technical log.

Design invariants the tool is built around

The parts that took the longest to get right aren't the features — they're the constraints:

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

What the tool does not claim

The applicability gate has never fired in the field. The never-downgrade check hasn't been exercised against a machine with a genuinely newer WU-delivered driver. The provenance-marker survival across a real Windows Update WinRE servicing event is unproven. The strip stage has been validated against clean images but not against a source that already contains vendor drivers. These are documented residuals in the CHANGELOG, not hidden gaps — if you run it and hit one, that's exactly the kind of thing worth posting about.

Where to get it


The README has a plain-English walkthrough for anyone who's never run a partition-modifying script before. The docs/ folder is for the crowd that wants to know exactly which failure paths are gated, which are VM-tested versus physical-hardware-tested, and which are still open. Both audiences are the point.

Comments on the new WinRE-Manager.cmd wrapper:
- appearance is informative and good
- tested option 1-4, and 7
- thought that option 3 should pause at the end so the steps could be reviewed, but these are all logged and available in option 4
- suggest adding a cleanup option to remove winre backup and logs (which I do manually when testing is completed)

The UI is good and the safety feature seem reasonable, but I cannot prove a negative that everything is in place. The version corrected an error that the previous version had on this PC. NO problems experienced on other PC using the previous version.

The documentation is thorough and excellent.

Quandary said:

Comments on the new WinRE-Manager.cmd wrapper:
- appearance is informative and good
- tested option 1-4, and 7
- thought that option 3 should pause at the end so the steps could be reviewed, but these are all logged and available in option 4
- suggest adding a cleanup option to remove winre backup and logs (which I do manually when testing is completed)

The UI is good and the safety feature seem reasonable, but I cannot prove a negative that everything is in place. The version corrected an error that the previous version had on this PC. NO problems experienced on other PC using the previous version.

The documentation is thorough and excellent.

Click to expand...

Thank you for testing again and for your feedback. I will most certainly add an option to cleanup or remove backups. I will figure out if I can have option 3 pause without editing WinRE.ps1 since WinRE.ps1 is designed to be also run as a scheduled task, but perhaps I can make the wrapper pause the WinE.ps1 script... I'm also contemplating adding an update feature where the wrapper automatically checks for new release on GitHub if possible...

I've released v50.1 aka v50 patch 1, please check it out at --> WinRE Manager — Repair Windows Recovery Environment <--

The wrapper aka WinRE-Manager.cmd gained a few additional features like auto update checking, cleaning up backups. The wrapper can also be used to create a monthly scheduled task for the main script to run if you want to set and forget automatic maintenance on Windows RE... The wrapper can also delete the scheduled task.

Excellent. Great additions.
I have not tested the creation of a scheduled task but have tested everything else.
The wrapper has an impressive, almost intimidating look now, but all is well explained.
Thanks again.