Recap and updated status:As I first posted, my first system, which had today's Win10 updates applied, and then MR updated from 4601 to 4711, and then 4711 added to the WinRE recovery code, worked without errors.
On the second system, I encountered the OP's original problem when I tried to turn off Copy USB drivers, forcing a complete rebuild of the WinRE wim. I never could do a successful rebuild of the WinRE wim with setting or resetting the Copy USB drivers switch. Matters got worse when I tried to switch the location of Macrium media from D: to C:
I gave up and I restored both c: and d: drives so that my second system status is:
Rescue Media Volume is where it was originally, on D: (to save space on C: which is an SSD). I will not try to move it back to C: because of the problem with cascading Macrium subdirs in \boot.
The original restore of C: re-established MR 4601, and build 18363.592. Today's updates, including KB4532693, have been applied.
OS Build Info shows: version 1909 - 18363.657
After the update of the OS, MR was updated to 7.2.4711. I was careful with Create Rescue Media operations so that the WIM was NOT rebuilt from scratch at any time. After MR 7.2.4601 was updated to 7.2.4711, the version of MR in the boot menu area was updated, but this did NOT rebuild the entire boot menu.
And the recovery option from the windows boot manager menu successfully loads MR 7.2.4711.
I'm going to hold on MR updates at this point, or if I do apply an update and have to rebuild the boot menu, I will very carefully do it and take snapshot backups before/after.
I believe there is a problem in the rescue builder code that led to the original problem, and I cannot say whether the problem involves KB4532693 or not.
There is also a bug in the Rescue Builder that causes the cascading \boot\macrium sub-directory problem if the media volume is changed. So my advice to anyone else is DO NOT CHANGE THE MEDIA VOLUME SELECTION until this is resolved. Unfortunately I did not save the any of the rescue builder log files before restoring from backup (my bad). But developers should be able to reproduce that issue. My running/working BCD has this for the Recovery section:
Windows Boot Loader
-------------------
identifier {3913c9eb-f338-11e8-bf8e-000272a7bd8d}
device ramdisk=[D:]\boot\macrium\WinREFiles\media\sources\boot.wim,{ramdiskoptions}
path \windows\system32\boot\winload.efi
description Macrium Reflect System Recovery
osdevice ramdisk=[D:]\boot\macrium\WinREFiles\media\sources\boot.wim,{ramdiskoptions}
systemroot \Windows
nx OptIn
detecthal Yes
winpe Yes
When it was bad because of the cascading directory problem (after a few retries going back and forth), it ended up with many \macrium repetitions and a double \\ in front of WinREFiles. so it looked like this for both the device and osdevice entries:
ramdisk=[D:]\boot\macrium\macrium\macrium\macrium\macrium\macrium\\WinREFiles\media\sources\boot.wim,{ramdiskoptions}
I strongly suspect this ramdisk is the "device" that the loader cannot find when trying to load the files for the recovery boot.
@Nick: I cannot, with certainty, say whether turning off Fast Startup helped or not. It's currently "off" for the second system (a server which seldom boots), and has never been "off" for the first system (laptop, which boots a lot). Could you give a bit more information about how it mucks things up when "on"?
I wonder if
@dbminter or
@fpefpe rebuilt the whole WinRE boot menu when doing the updates to MR
L.W. (Dan) Danz, Overland Park KS
Reflect v8.1.7469+ on Windows 11 Home 22H2-22621.1702+
Reflect v8.1.7469+ on Windows 10 Home/Pro 22H2-19045.2965+