MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically.

WINPE 4.0 boot modifes BCD hive on C drive

Recommended Posts

When I use my WinPE 4.0 based USB drive to boot a machine, the existing file C:\Boot\BCD file is modified. I have no idea why the bootmgr would be accessing that file since I'm booting into ram. I know the C drive is marked as active. WinPE 3.0 did not do this. I noticed this when i booted a hibernated box using my WinPE 4.0 USB. After I shutdown and tried to resume from hibernate, it showed the "..not shutdown properly..." display. Upon further investigation, the BCD entry in {bootmgr} for resume (resume yes) was gone. If I manually edit the BCD file (bcdedit /set {bootmgr} resume yes), the box came out of hiberate as expected. To ensure hibernate wasn't causing an issue, I booted a shutdown box. At the command line, I checked the modified date of the BCD on the C drive and it inidcated it was changed during the boot on WinPE.

Why is the BCD being used and how can I stop it from happening? Thanks for any advice.

Share this post

Link to post

Share on other sites

Like you I didn't plan on booting a hibernated box with PE and can't imagine why you would but it did point to the fact that the BCD hive is being modified during the boot process even if not hibernated. I have tried using a PE CD with the same result. I have not tried not auto mounting the drives (via SanPolicy) but I would then have to go mount them to fix whatever issue the box is having. Just seemed like a pain. I'm sure I'm screwing something up but I can't figure out what it is. Again, WinPE 3.x did not work this way so there maybe some new setting I should be making in my build process I just don't know what it is.

Share this post

Link to post

Share on other sites

Yes, I have normal Win 7 on a box. I hibernated the machine. Some boxes (like Dell) allow you to change the boot order (F12) and boot from USB even though the box is hibernated. Then PE will boot. With WinPE, after I shutdown WinPE, I could boot normally and the old hibernated Win 7 box would resume. Of course, you can screw up everything if you change the disk while in hibernate state so be careful.

All

I think we should take hibernate out of the issue. If I boot a normally shutdown box with a WinPE 4.0, and then , once booted, navigate to the location of the normal BCD file (typically c:\Boot\BCD) and check the modified date of the file. It will have a time that is consistent with when the WinPE was booted. That is what I don't understand.

Link to post

Share on other sites

No, I think it is perfectly valid. Even if you had done it by accident or unknowingly, it is a clear way to see that the BCD is being modified. Otherwise it should have resumed normally!

Also I don't think I have anything that lets me boot from something else on hibernate. Most of the systems I use seem "aware" at the BIOS level that the HDD is in hibernate, and none of the function keys "work" except maybe going into the BIOS. Even so, I wouldn't only be able to confirm that it does indeed do that or not, and not really be able to offer any other thoughts on the subject like a fix or whatever else. Truthfully, the BCD still kinda scares me.

Share this post

Link to post

Share on other sites

Some boxes (like Dell) allow you to change the boot order (F12) and boot from USB even though the box is hibernated. Then PE will boot. With WinPE, after I shutdown WinPE, I could boot normally and the old hibernated Win 7 box would resume. Of course, you can screw up everything if you change the disk while in hibernate state so be careful.

Thanks , did not know that, of course it sounds like a perfect recipe for disaster, if (as often happens) you have USB devices connected, and you are distracted by something, etc.

All

I think we should take hibernate out of the issue. If I boot a normally shutdown box with a WinPE 4.0, and then , once booted, navigate to the location of the normal BCD file (typically c:\Boot\BCD) and check the modified date of the file. It will have a time that is consistent with when the WinPE was booted. That is what I don't understand.

So, the \boot\BCD on the active partition on the disk (which is not first in boot sequence) is accessed anyway by a WinPE 4 (and this is not an issue by itself, but it can be if the PC was in hibernate state and "boot from other device" via F12 is allowed).

Are you talking of a WinPE 4.0 made:

from AIK/WAIK

from "recovery.exe"

other (please specify)

some reference/background for the above question:

Additionally, is the USB drive booting as "hard disk" or as "super floppy"?

And is it a USB stick or a USB hard disk drive?

Can you try setting in your WinPE the keys to prevent automount (as WinFE uses):

It is possible that the access is done by the BOOTMGR of the WinPE because the internal disk is the only "fixed disk" (if the WinPE is on a USB stick, which is normally "removable") or it is possible that it is done by the mount manager when the volume is mounted.

This way we could maybe understand what actually accesses the \boot\BCD on the intenal disk.

jaclaz

Share this post

Link to post

Share on other sites

WinPE 4.0 is made from AIK/WAIK. As for your "hard dirve/super floppy" question, you've gone beyond my level. How do I tell? I will try the WinFE method listed (but with the SanPolicy=4 as stated by other sites). I would think that the answer is the BCD will not be changed.

Share this post

Link to post

Share on other sites

WinPE 4.0 is made from AIK/WAIK. As for your "hard dirve/super floppy" question, you've gone beyond my level. How do I tell? I will try the WinFE method listed (but with the SanPolicy=4 as stated by other sites). I would think that the answer is the BCD will not be changed.

If the USB device is a hard disk, then it is partitioned.

If it is a USB sttck it may be partitioned (even if only one partition) or be "directly" a violume (i.e. a super-floppy).

If you prefer, if the first sector of the device is a MBR (and thus contains a partition table) then it is "hard disk like", if first sector of device is a bootsector, then it is a "super-floppy".

The BCD is a Registry Hive, it is normally auto-mounted in the Registry as HKEY_LOCAL_MACHINE\BCD00000\ (I am tlaking here of a "plain" installed Vista or later), but only the one used for booting (i.e. the \boot\BCD relative to the BOOTMGR actually chainloaded by the bootsector or boot manager) should, and this should happen after the first part of booting has happened, i.e. (unless I am mistaken) BOOTMGR itself should not be able (or wasn't up to 7) to write to the \boot\BCD.

This is why it is important to understand WHAT modifies it and WHEN exactly this happens.

And (OT ; but for the benefit of Tripredacus ) it is not something to be actually scared of, besides being stupidly assembled in a senselessly (and mindboggingly) complex way, it a "normal", plain Registry Hive, which is BTW a filesystem (some say a half-@§§ed one):

Share this post

Link to post

Share on other sites

Of course, this might not be the correct way to build it but it seemed to work, I will try the WinFE mode and let you know.

No, no, it is perfectly correct simply not the "only" way.

The possible issues, briefly, are as follows:

a USB stick in 99.999% (please read as 100%) of cases is set as "removable" device in factory (this can be changed in the actual controller of the stick through the appropriate Manufacturer tool but see also #4 below) and it is not partitioned.

a USB hard disk drive in 100% of cases is set as "fixed" device in factory (and any "fixed" device *needs* to be partitioned, i.e. Windows *wants* a MBR on a "fixed" device)

by partitioning the USB stick, you make it *resemble* a "hard disk" (but the "removable" bit of the device is still set)

as an alternative to "flipping the bit" in the controller it is possible to install in the windows (or in the PE) a "filter driver" that makes the "removable" bit as "fixed" to the OS

as a further peculiarity, a USB mass storage device has however some "differences" (as seen from the NT OS or the PE) when compared to an "internal" disk, (as an example you cannot normally have a pagefile on a booted from USB OS, or Windows Update will not work properly/fully) and there is one of the available "filter drivers" that, additionally to the "removable" status filters also the "external" status.

Any of these "filter drivers" are presumably loaded by the OS, i.e. they "come into play" after BOOTMGR has done whatever it is supposed to do and WINLOAD.EXE continues the booting.

So, if the access/change to the \boot\BCD of the internal disk is performed by the BOOTMGR, it is possible that it is *somehow* connected to the "removable" status of the device BUT there is NO way to prevent this behaviour through a "filter driver" (and possibly not even by the Registry settings WinFE uses), while IF the access/change to the \boot\BCD is performed by the booted OS, even in it's initial loading stage, then it is possible that the WinFE Registry settings and/or a "filter driver" can change the behaviour.

jaclaz

Share this post

Link to post

Share on other sites

I built my WinPE the "WinFE" way and repeated the test. I booted my hibernated system, used DiskPart to bring the disk online and assigned a drive letter to the volume that normally gets booted. The BCD file was not changed and resumed as normal. I could not clear the readonly attribute of the disk or volume so the WinFE method will not work for me since I need to fix (ie change) the disk to fix whatever problem the user ultimately was having.

Share this post

Link to post

Share on other sites

I built my WinPE the "WinFE" way and repeated the test. I booted my hibernated system, used DiskPart to bring the disk online and assigned a drive letter to the volume that normally gets booted. The BCD file was not changed and resumed as normal. I could not clear the readonly attribute of the disk or volume so the WinFE method will not work for me since I need to fix (ie change) the disk to fix whatever problem the user ultimately was having.

Share this post

Link to post

Share on other sites

I did the test again setting the "NoAutoMount=1" and leaving the SanPolicy=1 (default). After booting into PE, the disk was online but the volumes were offline. Using diskpart, I assigned a drive letter to the appropriate volume and verified the BCD had not been changed. BTW, the disk/volume were set to be read/write. I shutdown PE and rebooted and the hibernated system resumed as expected. I did the same test but not from a hibernated state, got the volume online and created a file at the root level. I then rebooted back into the normal system and the file was present as hoped/expected.

I will do the test again only changing the "SanPolicy=3" to see what it does including can I ever get the disk/volume to be writeable.

Share this post

Link to post

Share on other sites

I did the test again setting the "NoAutoMount=1" and leaving the SanPolicy=1 (default). After booting into PE, the disk was online but the volumes were offline. Using diskpart, I assigned a drive letter to the appropriate volume and verified the BCD had not been changed. BTW, the disk/volume were set to be read/write. I shutdown PE and rebooted and the hibernated system resumed as expected. I did the same test but not from a hibernated state, got the volume online and created a file at the root level. I then rebooted back into the normal system and the file was present as hoped/expected.

Good , so workaround #1 worked, right?

This might mean that after all the Windows 8/WinPE 4.0 BOOTMGR does check those Registry keys, there should be no differences between auto-mounting and manual mounting AFAIK, if not a timing difference, but that should not give different results anyway .

I will do the test again only changing the "SanPolicy=3" to see what it does including can I ever get the disk/volume to be writeable.

Yes , this is a good occasion to explore all the possible ways, since you have that particular machine which has the hybernate feature with Fxx keys active.