I'm developing an automated XP deployment using WinPE 2.0 and WIM image files. I'm using the Vista boot loader configured with bcdedit to launch a custom PE WIM on C: into RAM, and a legacy ntldr pointing at D:. The problem I'm encountering is that I can get everything configured as desired, apply the XP WIM to D:, ready to boot into Sysprep, but after Sysprep completes, my BCD entry for booting PE has been cleared of everything but the identifier and subsequently is no longer bootable!

While in the initial PE boot from CD the hard disk is partitioned and formatted NTFS with diskpart, then the boot loader configured with bcdedit, including "bootsect /nt60 c:". Then NTLDR, NTDETECT.COM, and boot.ini are copied to C:\ and the OS image applied to D:\ with D:\Sysprep\sysprep.inf getting customized. The reboot after that is able to load the PE WIM on C:, but if the Sysprep mini-install runs, the details for the PE WIM magically disappear.

Here's the command used to get Sysprep ready: Sysprep -pnp -reboot -mini -activated -reseal

Here's what's in Sysprep.inf:


Here are the commands used to configure the BCD:



Here's what bcdedit shows before Sysprep:



...and after Sysprep:



Does anyone have any thoughts on this? My initial C:\boot.ini has "timeout=5", but after Sysprep runs it has "timeout=30", so Sysprep is obviously doing something to modify the boot process, I just can't wrap my head around what it could do to my BCD.

For what it's worth, I can't even export / import my BCD. Here's what I've tried:

1) Boot PE from CD, partition, format, extract WIMs, reboot
2) Boot PE from C:\ via the boot loader, export the BCD via "bcdedit /export FILE_NAME", reboot
3) Boot Sysprep via the boot loader, let it do its reboot
4) Boot to PE from C:\ fails via the boot loader, so boot PE from CD, attempt a BCD import via "bcdedit /import FILE_NAME", but the boot PE from C:\ option remains bad
5) Boot XP via the boot loader and let it complete its imaging

Perhaps this is a clue about what the problem is. Maybe the import fails because after Sysprep runs some data on C: doesn't match up with what's in the exported BCD and it refuses to acknowledge my past entry. I may have to enlist the big guns from M$ to figure this bad boy out.

What does your boot.ini look like originally?

Original boot.ini:

After Sysprep:

Windows is installed in D:\WINNT. I've tried removing the timeout line from the original but that hasn't made a difference.

Keep in mind that boot.ini isn't my issue, the problem is that Sysprep is clobbering one entry in my BCD, but not the boot loader itself. The NTLDR stuff continues to function as expected.

From M$ http://technet2.microsoft.com/windowsserve...3.mspx?mfr=true:


Seems like fixntfs.exe should do the trick. So perhaps you could add this to a script and put it in sysprep\I386\$OEM$\CmdLines.txt

Unfortunately, fixntfs is for repairing the Boot Sector, which I have no problem with. That procedure is for when you run a legacy Windows text setup and it overwrites the Boot Sector to use the legacy boot loader. My Vista boot loader works fine, the problem is that one of its entries gets cleared of everything but its GUID after Sysprep runs.

Have you tried it? Seems to me that the situation would still apply.

Yeah, I had to download fixntfs.exe since I'm not running Vista and it's not included with PE 2.0. It did nothing to the contents of my BCD. If I did "fixntfs -xp" I got the legacy loader, if I did "fixntfs -lh" I got my Vista loader configured as before. Basically, it's the same thing as doing "bootsect /nt52 c:" for legacy and "bootsect /nt60 c:" for Vista.

Is it possible to save an unaltered copy of the working BCD and then just import it back in once sysprep is done, but before the reboot?

Ok I set up a test box with you parameters and duplicated the error. I added a batch file and bcdedit to the \sysprep\i386\$OEM$ directory to add the correct entries back to the bcd. Worked flawlessly, but for some reason renamed the GUID to {current}.

bcdfix.bat:


Cmdlines.txt:

Forget about the {current} comment. That appeared because I was in that PE environment when I ran the command. The acutal GUID didn't change.

I'm still focused on getting an answer / resolution to this that doesn't require a script to be run after the boot loader is busted. I've been struggling the last few days to get setup for M$ phone support, but I should be able to find out what they have to say in the next few days.

On a related note, I've noticed some interesting behavior around this whole scenario:

Boot PC to PE, partition and format hard disk with the following diskpart script and allow the load to complete:

After Sysprep runs on the PC, the option to boot the WIM on C: into RAM is broke. However, if I run my same routine again, but exclude partitioning the drive and simply format D: with diskpart, my boot loader works every time, even after sysprep!

So for whatever reason, it looks like after Sysprep has initially left its mark on C: and C: isn't subsequently touched, my bcdedit commands seem to stick. Hopefully this gives the M$ folks something to work with.

Did you find a solution to this issue? I'm having almost exactly the same problem.

My only solution was to run a batch file during the first boot and login after SysPrep to reconfigure my BCD entry. I decided on a static GUID so I wouldn't have to keep track of dynamic ones. Here's what I run from the batch file to re-install my entry:



It leaves my boot option in a bad state for one boot, but the user isn't present to do anything at that point, so fixing it on the first boot wasn't a problem.

Thanks for the info but unfortunately I need a solution that is completely automated. I won't be doing the installs.

Here is my setup.

Partition 1 is 10GB with Win PE 2.0 configured to restore a Ghost image to partition 2. It is type 0x27 (hidden/OEM). This is the active partition. Basically it is a homemade restore partition.

I used bcdedit to configure a dual-boot configuration according to the M$ walkthroughs as follows:

bcdedit -createstore c:\temp\bcd
bcdedit -store c:\temp\bcd -create {bootmgr} device boot
bcdedit -store c:\temp\bcd -set {bootmgr} device boot
bcdedit -store c:\temp\bcd -create /d "WINPE" -application osloader
bcdedit -import c:\temp\bcd

bcdedit -set <GUID copied from above> osdevice boot
bcdedit -set <GUID copied from above> device boot
bcdedit -set <GUID copied from above> path \windows\system32\winload.exe
bcdedit -set <GUID copied from above> systemroot \windows
bcdedit -set <GUID copied from above> winpe yes
bcdedit -set <GUID copied from above> detecthal yes
bcdedit -displayorder <GUID copied from above> -addlast

bcdedit -create {ntldr} /d "Windows XP"
bcdedit -set {ntldr} device partition=x:
bcdedit -set {ntldr} path \ntldr
bcdedit -displayorder {ntldr} -addfirst
bcdedit -timeout 10
bcdedit -default {ntldr}

Partition 2 is about 76GB with a sysprepped version of Windows XP.

I copied ntldr, boot.ini, and ntdetect.com from the XP partition to the root of the WinPE partition.

Here's the problem. At first boot it works great. XP boots and mini setup runs as expected. However after mini setup finished and it automatically reboots, XP will not boot again. When you select the option to boot XP you get the following error:

Windows failed to start. A recent hardware or software change might be the cause.

File: \ntldr
Status: 0xC000000E
Information: The selected entry could not be loaded because the application is missing or corrupt.

Booting into WinPE and running bcdedit reveals that the "device" entry for "Windows Legacy OS Loader" has changed from "partition=X:" to "unknown." Re-issuing the command "bcdedit -set {ntldr} device partition=x:" fixes the issue. However I cannot use a manual process for each system. I must either configure some sort of automated fix (e.g. a script that runs at first boot) or prevent the issue from occurring in the first place.

Thanks in advance for any help.

You don't need to specify the partition for NTLDR, C:\BOOT.INI determines what partition XP will boot from. I use the command "bcdedit -set {ntldr} device boot".

That appears to have fixed my issue. Thanks very much.