On latest version of Macrium Home (v8.1.7638) I'm getting following error when trying to boot using USB Windows RE rescue media:



The PC is latest build of Windows 10.  USB PE rescue media & PE Boot Menu option both work fine.  RE rescue media on previous versions of Macrium booted without an issue so puzzled why this is now showing.  SFC & DISM commands dont find any system file corruption.

Any suggestions welcome.

Thanks for prompt response.  PE rescue build works fine.

@JasonUK  I'm seeing the same thing and have ticket #246201 open with support.   Same conditions, I think.  Let us know if there's anything different for you.

Rescue Media Builder for WRBM (boot menu) for the versions that failed with 8.1.7638 previously worked with 8.1.7544, and all show Windows 10 RE version 2004 (64-bit) while the OS is Windows 10 Pro 22H2 build 19045.3324, 

I suspected that Windows Update might have done something to the Recovery Partition for the recent spate of very complicated Security fixes, so I repeated the testing with Secure Boot turned off, but the results were the same ... error code 0xc000A004 and complaints that \Windows\System 32\ntoskernel.exe was missing or had errors.   It's not missing in the Wim in the staging area on the PC, which is where WRBM boots form.

Rebuilding RM with Win PE 10 worked for me, as did resurrecting the ISO file from the previous version of RM with Win RE 10 built under 8.1.7455 and booting it via flash drive.

The system that failed is the second one here to get 8.1.7638;  the first was my  guinea pig laptop running Reflect v8.1.7638+ on Windows 11 Home 22H2 22621.2215+ , and it works.  It uses WinRE 11 build 22621 from the Recovery partition. 


L.W. (Dan) Danz, Overland Park KS

I've narrowed the source of this problem down to a Windows Update install of KB5029331 (OS Build 19045.3393) Preview that I installed on 09/02/2023 on the problem system \\hopi running Windows 10 19045.3324 after I had tested the preview update with no problems on my guinea pig Windows 11 laptop \\apache.  The big clue was a third system, \\thimbles running Win 10 19045.3324 never had KB5029331 applied to it, and I was able to build WRBM using MR 8.1.7638 with WinRE 10 Build 2004  that successfully ran when booted.

Steps I took to recover the problem system \\hopi.

1. I used DISM to remove the package for the preview update from the online 19045.3393 installation, and that reverted the online image to 19045.3324
2. Rebuilt WRBM from WinRE 10 but removing the package from the OS apparently did not undo any changes to the recovery partition, because the rebuilt WRBM still failed to boot.
3. Rebuit WRBM from WinPE 10 and rebooted using the resulting WRBM.
4. Restored just the Recovery Partition from a backup taken prior to 09/02/2023 while the system was running 19045.3324.
   I could have just restored the whole enchilada, but didn't want to lose other activity on the system, which includes the Reflect repository for all four systems in the house.  A partial restore of C:\ and D:\ still remains an option if anything else is broken, omitting the repository from the restoration.
   
5. Rebooted this hybrid system, and rebuilt WRBM from WinRE 10 build 2004 (using that restored Recovery Partition).
6. Tested WRBM boot.  The initial try hung Analyzing Disk 4 partition 1 -- that disk is an old 80 GB SSD that used to be the main disk on this system, but when I migrated to a 500GB SSD as the main disk, I relegated the old disk to be used forTEMP files, paging file, swapfile, etc.  It does not get backed up.   Partition 1 on that disk GPT disk is not used and is not formatted with any file system. All files are on an NTFS volume in partition 2.  I think I remember a report on this forum of a similar hang, but I'm not sure it was ever fixed.  I suspect Reflect is thrown off by a raw partition that has no file system. 
   
7. Rebooted and restarted the WRBM boot.  No hang, and everything worked this time.
8. Changed the retention rules on the repository to retain 3 full backups (1 more than usual) so I could capture a full backup of this system without losing any the previous backups, including ones that had the bad system patch applied, and also the previous full and diff backups from 19045.3324.
   
9. Started a full backup on the hybrid system that resulted from steps 1-5. 
10. In a day or two, I'll destroy the backups that contain the contaminated results of applying KB5029331 19045.3393. 
    

I'll update the support ticket with these results.

Edited to add:  I confess that I failed to take my usual quick incremental backup of \\hopi before applying the KB5029331 patch, especially since it was a preview patch.  I was lulled into eschewing the safety backup because the patch had already been tested on my laptop. Unfortunately testing on Windows 11 does nothing to discover how it will run on a Win 10 system.  Lesson learned the hard way.


L.W. (Dan) Danz, Overland Park KS

Update: This week Windows update published a collection of updates to Win 10 and Win 11 but the cause of my troubles was not among them.  I was able to update all the systems to the levels as  shown in my signature without incident.  I don't know if support has been able to reproduce the original problem. Perhaps I'll hear from them after the weekend.

Edited to correct the versions shown in my signature.


L.W. (Dan) Danz, Overland Park KS

Hello –

Thanks again for the road map on how to fix the issue — it seems that macrium support will not address this issue on their end —

Looking over your 10 steps — would a simpler process be to restore the system just before kb5029331 was applied

Then let windows do updates from that point. Reflect 8.1.7638 came out around 9/4 so this patch would have to be applied

At this point the recovery environment can be built with 7638 and Win RE — would this work?

Thanks

Yes - you're on the right track. But .... How were you planning on doing the restore?  You don't have a working standalone RM which is needed to restore your system drive. You can't stage the restore from live MR because the drive is in use, so that will cause a Reflect to reboot to your current (broken) WRBM or require a working standalone RM to do the restore. Or you could start the restore from RM if you had a working RM. . 
 
There is another way to achieve a goal of always having a working standalone RM (not WRBM) -- On your current buggy system, rebuild RM with WinPE instead of WinRE.  That's what I used to restore the backup.  After you reboot with the WinPE version of RM and successfully do the restore, then update MR and rebuild RM with the new MR and WinRE and everything up to the latest.   By the way, don't clear the live drive before doing the in-place restore to it,  because doing the restore with Rapid Delta Restore enabled will save you hours of restoring time.

Hopefully, you'll be back in business without ever being without a working standalone RM. 


L.W. (Dan) Danz, Overland Park KS

Again, thanks for the info --- BTW  since Macrum support noted that this is a MS issue could future MS updates fix this issue? 

+x

 

Frank Esposito - 20 September 2023 1:42 PM

Again, thanks for the info --- BTW  since Macrum support noted that this is a MS issue could future MS updates fix this issue? 

You're welcome !!!
I haven't seen any sign of it -- and got no response to my feedback reporting the issue we had.   I have not heard what support has heard from M$S. 

L.W. (Dan) Danz, Overland Park KS