• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jtalbot35

Profile Information

  • OS
    Windows 7 x64
  1. jaclaz Thanks for all of your help. Not sure why the original issue happens (BCD file changed on boot) but I'm going to work around it with the NoAutoMount setting. Thanks again.
  2. jaclaz With SanPolicy=3, I could never get the disk writeable. Here is the output of my DISKPART session
  3. jaclaz I did the test with SanPolicy=3. That worked as far as not changing the BCD hive but I could not get the fixed drive to remove the readonly bit. All the drives (including the PE drive came up "offline" as expected. I used diskpart to mark the disk "online" which was successful and did the "attributes" command. It failed with the "Diskpart failed to clear disk attributes" msg. I repeated the steps on the PE drive and the "attributes" command was successful. From that, since I may need to fix a problem on a users drive, I think the SanPolicy=3 won't work. Of course I may just be doing something dumb but at this point I'm going to go down the "NoAutoMount" path and see what happens. I can try other things if you would like. BTW, if you have VMWare, you can build a Win 7 VM normally and then configure the boot sequence in the VM BIOS to first try booting from CD then hard drive. You can then build an ISO from you PE USB drive using: "oscdimg -n -betfsboot.com "drive_where_your_PE_DISK_IS" name.iso. You can then attach your iso to your VM and boot it and your WinPE will be in control. I used this method to initially look at the hibernated state issue (I hibernated my Win 7 VM image and then attached my WinPE iso to it and rebooted. All of my above test where done on real hardware though. Never know when VMWare is not telling you the truth.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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