.\Patch-WinRE.ps1 -CreateWinREDrive removes c:\windows\system32\recovery\winre.wim

[l4m3us3r]

steps to reproduce: delete recovery partition (drive 0 partition 4) run .\Patch-WinRE.ps1 -CreateWinREDrive -ToConsole (fails: "No WinRE location found, can not create WinRE drive", ?? this is a vanilla windows 10 install on a vm, why isn't winre.wim in the default location??) manually copy Winre.wim to C:\Windows\System32\Recovery run .\Patch-WinRE.ps1 -CreateWinREDrive -ToConsole (succeeds) C:\Windows\System32\Recovery\Winre.wim is gone!

obviously I can just manually copy it again, but seems like a relevant bug.

cheers,

[MHimken]

Hey @l4m3us3r. If you deleted the recovery partition yourself instead of letting the script expand it (I assume you might have had a partitioning that the script doesn't support?) you need to manually disable the recovery agent first using reagentc /disable. The WinRE.wim is actively moved to the recovery partition whenever reagentc /enable is run. If the script exited successfully (provided you still have the log, you can easily see it from that) it's expected, that the WinRE.wim isn't in C:\Windows\System32\Recovery\ anymore, but on the partition that was just created. As long as reagentc /info shows 'Enabled' with a partition that is not the same as the OS partition, you're fine. Try booting into WinRE by running reagentc /boottore and see if that works if you want to test it (see)

Please don't forget to let me know the outcome!

Regards Martinm

[l4m3us3r]

Some context, we have machines in a lot of different states of winre health... some with winre broken by the ms script which ran half way, removed the winre partition, and then errored. I am trying to test Patch-WinRE.ps1 in these various states of winre brokenness.

So I am intentionally deleting the winre partition (disk 0 last partition) with diskpart to simulate a broken device copy Winre.wim to C:\Windows\System32\Recovery run .\Patch-WinRE.ps1 -CreateWinREDrive -ToConsole (succeeds, appears to have working winre again) reboot .\Patch-WinRE.ps1 -RecoveryDriveSizeInGB 1GB -PatchFilesDUorSOS ".\" -ToConsole

At this point I get the errors below and do not have a winre partition.

T:1 C:FormatWinREPartition M:Shrinking C: and re-creating recovery partition T:3 C:FormatWinREPartition M:Size Not Supported

Extended information: The specified shrink size is less than then minimum shrink size allowed.

Activity ID: {cacdac57-44fc-4ca9-a8ac-a7cdd0b794fa} T:1 C:FormatWinREPartition M:Unrecoverable error occured - this could mean there is a partition in the way to shrink the system partition T:3 C:WinREPatchCore M:Something went wrong with the recovery partition - please check the log C:\WinRE-Customization\Logs\Patch_29052024_125355.log

I made a video if it's easier to see the process: https://youtu.be/F6HKrRg3VeI

[MHimken]

Ok, watched your video. You do have a recovery partition after the reboot. Again, the tests to verify it’s actually doing what it’s supposed to is using reagent /info (as you did before rebooting) and doing a simulated boot into the recovery image by doing reagentc /boottore.

Couple of things to note:

• RecoveryDriveSizeInGB works as standalone switch. No other parameters are required (or tested)
• I don’t fully understand why you’d run the command again, if you haven’t checked (/info) and verified (/boottore) first.
• The windows update that breaks things for you also does a backup (just like my script) to a hidden System folder on C. You might be able to restore the image by using that - that would have the added benefit of you not needing to add drivers yourself.
• Running the script twice with the same GB size I haven’t tried. Usually the RE partition gets expanded - I simply don’t check for “has same size” I believe. If you must run it a second time don’t use the same size value

The testing you did is similar to what I usually do, minus outright killing the partition.

Reagrds Martin

[MHimken]

Hey @l4m3us3r, please let us know if this is working for now. I will wait until the weekend has passed and then close the issue.