Jump to content

WINPE 4.0 boot modifes BCD hive on C drive


jtalbot35

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.

Josh

Link to comment
Share on other sites


May I ask some clarifications?

You have a normal install of (say) Windows 7 or 8 on a machine.

You hibernate that machine.

Then how can you boot to the PE (WinPE4 in your case)?

What do you do exactly to be able to boot to the (I presume added) USB thingy from a hibernated state?

jaclaz

Edited by jaclaz
Link to comment
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.

Link to comment
Share on other sites

jaclaz,

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 comment
Share on other sites

I think we should take hibernate out of the issue.

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. ;)

Link to comment
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. :unsure:

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:

  1. from AIK/WAIK
  2. from "recovery.exe"
  3. 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):

http://www.forensicswiki.org/wiki/WinFE

and try again?

Explanation:

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

Link to comment
Share on other sites

jaclaz

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.

Link to comment
Share on other sites

jaclaz

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 :ph34r: 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 :w00t: ; 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):

http://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/

jaclaz

Link to comment
Share on other sites

jaclaz

I do the following to make my WinPE USB:

diskpart

select disk "some disk number"

clean

create partition primary

select partition 1

active

format fs=FAT32 quick Label=WINPE

assign

bootsect /nt60 "drive letter assigned"

copy all files toWinPE usb

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.

Link to comment
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 :thumbup simply not the "only" way.

The possible issues, briefly, are as follows:

  1. 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.
  2. 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)
  3. by partitioning the USB stick, you make it *resemble* a "hard disk" (but the "removable" bit of the device is still set)
  4. 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
  5. 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

Link to comment
Share on other sites

jaclaz

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.

Link to comment
Share on other sites

jaclaz

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.

Try again :w00t:

The "WinFE settings" are two distinct keys:

"HKEY_LOCAL_MACHINE\system\ControlSet001\Services\MountMgr

NoAutoMount=1

and

HKEY_LOCAL_MACHINE\system\ControlSet001\Services\partmgr\Parameters

SanPolicy=3

BTW the one you probably set as "4", which is seemingly :

http://technet.microsoft.com/en-us/library/dd799290(WS.10).aspx

the new setting used for Windowstogo:

http://social.technet.microsoft.com/wiki/contents/articles/6991.windows-to-go-step-by-step.aspx

Apply the new SAN policy setting OFFLINE_INTERNAL - “4” to prevent the operating system from automatically bringing online any internally connected disk.

Try only with the first one, and/or try with the 3 one.

Also it is possible that Windows 8 (and conversely WinPE 4.0) has "inherited" this feature of Server 2008 :unsure:

http://support.microsoft.com/kb/971436

You can then try to do this from the PE "as is" when you manually mount the volume:

http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2012/01/23/when-deploying-windows-server-2008-using-an-configuration-manager-osd-task-sequence-additional-disks-may-show-as-offline-when-the-task-sequence-completes.aspx

select disk <disk#>

online disk noerr

attribute disk clear readonly noerr

jaclaz

Link to comment
Share on other sites

jaclaz

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.

Link to comment
Share on other sites

jaclaz

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 :unsure: .

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 :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.

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...