Recovery\BCD Error

[scorchpc]

I am back with this Recovery\BCD Error:

I have tried several times, and the issue repeats.

Attached is the file from the error: BCD.zip

Let me know any information you need or anything you would like to try.

[jpz4085]

The attached file appears to have no issues.

I have to ask, before going any further, are you certain this is the correct BCD file from the correct computer?

During our last attempt to identify the cause of this issue the only corrupt BCD provided was the very first one which was empty for an unknown reason. All other examples contain normal entries. The only identifiable configuration issue was the very last pair of Recovery hives (with one repaired by Windows) where the disk and partition GUIDs had apparently changed after my script completed. The GUID situation must be a deployment issue because my scripts only read that data.

If you can confirm the provided file is the correct one and that the partition configuration of that system has not changed in ANY way since the error then manually run bcd-sys with the -c option to recreate the files and confirm the new ones work without issues. The following will only be valid if the partitions are still identical. If successful then provide the new BCD for comparison and have your engineer/technical lead compare them too if desired. If the GUID values are the issue and not a corrupted file then the appropriate person will need to determine why the deployment/imaging process is modifying this data.

[scorchpc]

I can confirm this is the correct file.

I will try bcd-sys with -c and report back.

Thanks!

[scorchpc]

Question; Do you think it would be good to add GUID validation? Like, once the process is done, verify it matches?

I absolutely agree the GUID should not change.

[scorchpc]

Attached are the Recovery\BCD files “before” and “after”. The unit I am working on is a 7773 model, so that is where the name comes from.

“Recovery-BCD-before” is the original “Recovery-BCD-after” is after I did: 7773.zip

mkdir /tmp/sda4 mount /dev/sda4 /tmp/sda4

bcd-sys -c /tmp/sda4

Here are the UUIDs:

sfdisk -l -o+uuid /dev/sda Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors Disk model: 120GB SATA Flash Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BAAE8DF8-BA8E-444C-9E58-0ECB616DB65E

Device Start End Sectors Size Type UUID /dev/sda1 2048 34815 32768 16M Microsoft reserved 5C80E502-0FA9-1648-9FC1-6BEAADA19D11 /dev/sda2 34816 567295 532480 260M EFI System 2A81D20B-C193-354D-B382-E0E12BAEEE72 /dev/sda3 567296 600063 32768 16M Microsoft reserved 9759967A-8710-8545-99B7-13B82698FEB4 /dev/sda4 600064 234440703 233840640 111.5G Microsoft basic data 414C1611-CB34-4E48-A716-7F2C7A761596

The files are identical.

Now, just to make sure I did this right. I removed the Recovery\BCD file and did the process again. I verified the file was re-created (it was!) and again I checked against the attached, and they are identical.

Please advise.

[jpz4085]

Yes the files are identical, they contain the GUIDs displayed in the sfdisk output and have no formatting errors or corruption. I tested them by editing the GUIDs to match one of my virtual machines and was able to boot successfully. If neither file works on the system from which the partition information above was provided I can't identify any reason and can't offer any suggestions.

If there is a comprehensive log covering the entire deployment process (not just bcd-sys) from beginning to end that can be compared between success and failure preferably on the same machine and shows any identifiable differences that is probably our last option.

[scorchpc]

Here is what I decided to do. I got the site to image this same unit using Windows PE, verified that that would boot, then I grabbed the Recovery\BCD file from there, and here that is:

BCD.zip

I also grabbed the UUID's:

sfdisk -l -o+uuid /dev/sda Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors Disk model: 120GB SATA Flash Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 715C53C5-F918-4CFA-84FF-8504489C9A35

Device Start End Sectors Size Type UUID /dev/sda1 2048 206847 204800 100M EFI System DCF5B40C-16B4-4797-8932-D73AE0809747 /dev/sda2 206848 223346687 223139840 106.4G Microsoft basic data 8CCC652E-63E6-42A3-B82E-CC0EEA6CBB61 /dev/sda3 223346688 234440703 11094016 5.3G Microsoft basic data 136C1033-8885-42C5-BB25-F446C64277D9

I see that the Windows PE process made 3 partitions, whereas our process made 4. Not sure if that is an issue, but I noticed the difference.

Let me know what you think.

[jpz4085]

The attached file is a typical recovery hive with entries that match the previous ones from the prior post and eariler except for the GUIDs as one would expect. The file length is shorter and the binary content a little different owing to the differences between the native Windows registry tools and the hivex library/utilities. These differences aren't relevant here since they apply to all the recovery hives created including the ones that work.

I see that the Windows PE process made 3 partitions, whereas our process made 4. Not sure if that is an issue, but I noticed the difference.

I tested the the four partition layout on a virtual machine and it caused no apparent issues. Any idea why that configuration has two Microsoft Reserved (MSR) partitions? Usually there's only one following the EFI system partition (ESP). The Windows PE process looks to have created a more standard disk layout with an ESP, Windows partition and recovery partition but no MSR partition. You may want to look more closely at the section of your deployment scripts performing partitioning and formatting to see how and when that's handled.

[scorchpc]

Yes the files are identical, they contain the GUIDs displayed in the sfdisk output and have no formatting errors or corruption. I tested them by editing the GUIDs to match one of my virtual machines and was able to boot successfully. If neither file works on the system from which the partition information above was provided I can't identify any reason and can't offer any suggestions.

If there is a comprehensive log covering the entire deployment process (not just bcd-sys) from beginning to end that can be compared between success and failure preferably on the same machine and shows any identifiable differences that is probably our last option.

When you tested this in your environment, which Windows version did you use?

Here is the wiminfo from the .WIM file we used: Architecture: x86_64 Product Name: Microsoft® Windows® Operating System Edition ID: EnterpriseS Installation Type: Client HAL: acpiapic Product Type: WinNT Product Suite: Terminal Server Languages: en-US Default Language: en-US System Root: WINDOWS Major Version: 10 Minor Version: 0 Build: 17763 Service Pack Build: 3287 Service Pack Level: 0 WIMBoot compatible: no

[jpz4085]

When you tested this in your environment, which Windows version did you use?

The recovery BCDs were tested on the following system:

Windows 10 Professional 22H2 Build:19045 Service Pack Build:4651 Lang:en-US Arch:x86_64

This is the most current version of Windows 10. Additionally, when developing the scripts I also tested them successfully with Windows 11 and the last released versions of Windows 8.1 and Windows 7 so the resulting BCD files support a wide range of products.

[scorchpc]

Thanks. I have some more tests I need to try.

BTW - If it would help, I do always get the whole BCD directory and Recovery\BCD directory. Let me know if you ever need that.

[jpz4085]

BTW - If it would help, I do always get the whole BCD directory and Recovery\BCD directory. Let me know if you ever need that.

Sure, that could be helpful.

[scorchpc]

Ok here you go.

There are two folders in this zip. IssueRecovery is from the BCD-SYS process. WinPE is from the WinPE process.

7773.zip

[jpz4085]

I have been attempting to replicate this issue on a virtual machine and have an observation that may address the recovery BCD error. The screen shot in the first post indicates the Windows installation on that system failed to start (for an unknown reason) and attempted to boot into the Windows Recovery Environment unsuccessfully. This is not possible at this point because the default boot and recovery hives created by my tool as well as the Microsoft bcdboot utililty (on which bcd-sys is based) lack the WinRE RAM disk entries created automatically during installation or manually with the "reagentc /enable" command. Windows must boot successfully at least once to enable the recovery environment. This would explain why this error occurs even though the BCDs contain no identifiable issues.

If you currently have a system that was imaged with the Linux process and is experiencing this issue I would suggest deleting both BCDs from their respective folders and recreating them using bcdboot from WinPE but WITHOUT reimaging the system. Just use bcdboot to manually create new hives on the affected system. This should tell us whether the cause of the boot failure was the BCDs created by my tool or an issue with the Windows installation itself. Assuming of course you haven't already done this.

[scorchpc]

7779.zip Hi,

Attached is a new unit. The zip files are the whole Boot and Recovery folders. Folder "1" is after freshly doing the erase + image + bcd-sys (yours) before trying to boot. This unit did not boot properly. But Windows does automatically fix it, and Folder "2" contains the whole Boot and Recovery folders after Windows has automatically fixed it.

Let me know any feedback or questions.