Jump to content

How to repair the BOOTSECTOR of a FAT32X active partition?

DiracDeBroglie
 Share

Recommended Posts

DiracDeBroglie

DiracDeBroglie

Posted
Posted

Hi,

My FAT32X Recovery (R:\) partition fails to boot. Note that in the past and until recent, exactly the same recovery(reinstall) partition used to boot and reinstall my OEM Win7 several times without any problem.

Luckily I took a backup of my Win7HP on 5 DVDs (long time ago) and I still got several copies of the 5 ISO files too. However, although I could do without the corrupted recovery partition, I still would like to fix the problem and get the recovery partition back up and running so that I can invoke it at boot time by just tapping F9, as before.

The recovery partitioin is about 20GB and contains only my Window7HP OEM installation.

In the root directory, the recovery partition contains the bootmgr.exe, boot\BCD and sources\BOOT.WIM.

I've rebuild the BCD file with EasyBCD (and with the BCDedit commands in the cmd prompt too) several times and tried out all possibilities concerning repairing and rebuilding from scratch, but no bootable recovery partition yet.

I've then also removed the entire \boot directory and the bootmgr.exe, followed by rebuilding the boot directory and bootmgr.exe using EasyBCD (BCD Deployment); still the recovery partition does not reboot.

Finally I introduced a recovery partition boot option into the boot menu of my active system partition (normal Win7) by putting the R:\sources\BOOT.WIM into the C:\boot\BCD using EasyBCD. And that worked just fine. I could boot into my recovery partition and reinstall Win7HP. So the content of the recovery partition is still intact.

I'm starting to think the problem must be in the BOOTSECTOR (or maybe in the MBR??) of the recovery partition. Upon booting the recovery partition, I just get a blinking "_" for an infinitely long time; to get out I need to poweroff the notebook. I have the impression that the bootsector is not even calling the bootmgr. I had a look at the first sector (sector 0) with Tiny Hexer and compared it (using the compare facility in the menu) with the backup sector (sector 6): There was no difference --- it could be that the copy is already overwritten by the corrupted version of the bootsector, I'm not sure.

I noticed some text in the bootsector: the word "BOOTMGR" and the text "Remove disks or other media.ÿ Disk errorÿ Press any key to restart" appeared. So, if something would be wrong with the bootmgr, I think I should see some readable text on the screen, but that is not the case; the only thing I see is a blinking "_" .

I would like to get more insight in how the bootsector calls the bootmgr. Does the bootsector look for a file by name, so the name "bootmgr", or does the bootsector jumps to a particular sector in the partition, which would be the first sector of the file "bootmgr"?

Could it be that it is not the bootsector after all causing the problem but rathter the MBR, somehow?

Thanks in advance,

johan


jaclaz

jaclaz

Posted
Posted (edited)

I'm starting to think the problem must be in the BOOTSECTOR (or maybe in the MBR??) of the recovery partition. Upon booting the recovery partition, I just get a blinking "_" for an infinitely long time; to get out I need to poweroff the notebook. I have the impression that the bootsector is not even calling the bootmgr. I had a look at the first sector (sector 0) with Tiny Hexer and compared it (using the compare facility in the menu) with the backup sector (sector 6): There was no difference --- it could be that the copy is already overwritten by the corrupted version of the bootsector, I'm not sure.

I noticed some text in the bootsector: the word "BOOTMGR" and the text "Remove disks or other media.ÿ Disk errorÿ Press any key to restart" appeared. So, if something would be wrong with the bootmgr, I think I should see some readable text on the screen, but that is not the case; the only thing I see is a blinking "_" .

I would like to get more insight in how the bootsector calls the bootmgr. Does the bootsector look for a file by name, so the name "bootmgr", or does the bootsector jumps to a particular sector in the partition, which would be the first sector of the file "bootmgr"?

Could it be that it is not the bootsector after all causing the problem but rathter the MBR, somehow?

You need some "basics" before anything else :ph34r: .

The MBR (Master Boot Record) is part of the DISK (WHOLE disk) i.e. there is one (and ONLY one) MBR for each disk drive device.

The PBR (Partition Boot Record) or VBR (Volume Boot Record) or bootsector is part of the Partition or Volume, i.e. there are as many VBR's as there are Volumes on the disk drive device.

The HP hardware normally comes with a "specific", "proprietary" MBR CODE, that allows to press F11 to get to the Recovery partition.

If you change the MBR code (as an example by installing *any* MBR based bootmanager and or simply run a MBRFIX or on Windows 7 a bootsect with the /mbr switch) that original MBR code is gone for good and restoring it (unless you have a copy/backup of it) is/will be - to say the least a nightmare.

See:

Unless you have re-formatted the partition/volume, there is a copy of the PBR/VBR strating on sector 6, so that wouldn't be a problem to restore it, just in case:

http://thestarman.narod.ru/asm/mbr/index.html

http://thestarman.narod.ru/asm/mbr/ntFAT32BR.htm

You will need to restore not only the first sector, but also the other two (a FAT32 VBR is actually three sectors long, the "main" one being sectors 0, 1 and 12, while backup ones are sector 6, 7 and 8. (please be aware that the "third sector" is #12 only on NT based systems, in DOS/Win9x it is #2 and in ReactOS it is #14 :w00t: ):

http://www.911cd.net/forums//index.php?showtopic=23382

http://www.911cd.net/forums//index.php?showtopic=23382&st=12

The "flashing" cursor - however - is traditionally connected to a botched BPB, namely disk geometry, but not only.

If you can get the MBR, (first sector of PhysicalDrive) and the PBR (first sector of the LogicalDrive), through an hex editor or a tool like HDhacker:

http://dimio.altervista.org/eng/

zip the two files together and attach the .zip to your next post, I may be able to have a look at them and tell you if anything looks "strange" to me.

An only seemingly unrelated thread:

http://www.911cd.net/forums//index.php?showtopic=23408&hl=

jaclaz

Edited by jaclaz
DiracDeBroglie

DiracDeBroglie

Posted
  • Author
Posted

Sector 0 and 6 are identical, between sector 1 and 7 there is a slight difference, and between sector 12 and 8 there is a large difference.

I copied (Copy and Paste) sector 7 into sector 1 and tried to save it but there always seems to be an error message: "System Error." "Code: 5." "Access is denied."

However, I can open any file in the partition, edit it, and save it back. It looks like the partition is not at all locked. Any idea about the origin of the error?

j

DiracDeBroglie

DiracDeBroglie

Posted
  • Author
Posted

Here it comes. The main point is getting the error message gone so that I can move on with Tiny Hexer.

j

---------------------------------------------------------

C:\Windows\system32>bcdedit /enum all

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  boot
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {0540b4cc-c367-11e1-9849-806e6f6e6963}
displayorder            {current}
                        {500cf7cd-c423-11e1-b5b0-14dae9e74180}
                        {fec54f22-c74c-11e1-ada2-14dae9e74180}
toolsdisplayorder       {memdiag}
timeout                 10
displaybootmenu         Yes

Windows Boot Loader
-------------------
identifier              {500cf7cd-c423-11e1-b5b0-14dae9e74180}
device                  ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180}
path                    \Windows\System32\Boot\winload.exe
description             Window 7 Recovery Environment (system partition)
locale                  en-US
osdevice                ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180}
systemroot              \Windows
detecthal               Yes
winpe                   Yes
ems                     Yes

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Microsoft Windows 7
locale                  en-US
osdevice                partition=C:
systemroot              \Windows
resumeobject            {0540b4cc-c367-11e1-9849-806e6f6e6963}

Windows Boot Loader
-------------------
identifier              {fec54f22-c74c-11e1-ada2-14dae9e74180}
device                  ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180}
path                    \Windows\System32\Boot\winload.exe
description             Windows Setup
locale                  en-US
osdevice                ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180}
systemroot              \Windows
detecthal               Yes
winpe                   Yes
ems                     Yes

Resume from Hibernate
---------------------
identifier              {0540b4cc-c367-11e1-9849-806e6f6e6963}
device                  partition=C:
path                    \Windows\system32\winresume.exe
description             Microsoft Windows 7
locale                  en-US
inherit                 {resumeloadersettings}
filedevice              partition=C:
filepath                \hiberfil.sys
debugoptionenabled      No

Windows Memory Tester
---------------------
identifier              {memdiag}
device                  boot
path                    \Boot\memtest.exe
description             Windows Memory Diagnostic
locale                  en-US
inherit                 {globalsettings}
badmemoryaccess         Yes

EMS Settings
------------
identifier              {emssettings}
bootems                 Yes

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

RAM Defects
-----------
identifier              {badmemory}

Global Settings
---------------
identifier              {globalsettings}
inherit                 {dbgsettings}
                        {emssettings}
                        {badmemory}

Boot Loader Settings
--------------------
identifier              {bootloadersettings}
inherit                 {globalsettings}
                        {hypervisorsettings}

Hypervisor Settings
-------------------
identifier              {hypervisorsettings}
hypervisordebugtype     Serial
hypervisordebugport     1
hypervisorbaudrate      115200

Resume Loader Settings
----------------------
identifier              {resumeloadersettings}
inherit                 {globalsettings}

Device options
--------------
identifier              {1f8184a5-14de-11df-9734-f08c6d8c50b0}
description             Ramdisk Options
ramdisksdidevice        unknown
ramdisksdipath          \Recovery\1f8184a4-14de-11df-9734-f08c6d8c50b0\boot.sdi

Device options
--------------
identifier              {500cf7cc-c423-11e1-b5b0-14dae9e74180}
description             Window 7 Recovery Environment (system partition)
ramdisksdidevice        partition=C:
ramdisksdipath          \NST\boot.sdi

Setup Ramdisk Options
---------------------
identifier              {ramdiskoptions}
description             RamdiskOptions
ramdisksdidevice        partition=C:
ramdisksdipath          \NST\boot.sdi

Device options
--------------
identifier              {fec54f21-c74c-11e1-ada2-14dae9e74180}
description             Windows Setup
ramdisksdidevice        partition=C:
ramdisksdipath          \NST\boot.sdi

C:\Windows\system32>

---------------------------------------------------------

jaclaz

jaclaz

Posted
Posted

Sector 0 and 6 are identical, between sector 1 and 7 there is a slight difference, and between sector 12 and 8 there is a large difference.

Well, then it is likely (but not sure) that the differences in sector 7 makes you slightly NOT boot the recovery partition, whilst the difference in sector 12 may (or may not) make you largely NOT boot it. :angel

Any idea about the origin of the error?

Yes. :)

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/questions-with-yes-or-no-answers.html

If you post the requested data, I might even be able to tell you the one that is more likely to apply to your case, as well it is possible that the issue is in the \boot\BCD as Tripredacus is guessing, but without data it's impossible to say.

jaclaz

Tripredacus

Tripredacus

Posted
Posted

Quoted from above

Windows Boot Loader
-------------------
identifier              {500cf7cd-c423-11e1-b5b0-14dae9e74180}
device                  ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180}
path                    \Windows\System32\Boot\winload.exe
description             Window 7 Recovery Environment (system partition)
locale                  en-US
osdevice                ramdisk=[C:]\Recovery\8cb2d9b4-7c05-11de-842e-b4611d44fefa\Winre.wim,{500cf7cc-c423-11e1-b5b0-14dae9e74180}
systemroot              \Windows
detecthal               Yes
winpe                   Yes
ems                     Yes

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Microsoft Windows 7
locale                  en-US
osdevice                partition=C:
systemroot              \Windows
resumeobject            {0540b4cc-c367-11e1-9849-806e6f6e6963}

Windows Boot Loader
-------------------
identifier              {fec54f22-c74c-11e1-ada2-14dae9e74180}
device                  ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180}
path                    \Windows\System32\Boot\winload.exe
description             Windows Setup
locale                  en-US
osdevice                ramdisk=[F:]\sources\BOOT.WIM,{fec54f21-c74c-11e1-ada2-14dae9e74180}
systemroot              \Windows
detecthal               Yes
winpe                   Yes
ems                     Yes

This seems kinda strange to me (although I am no expert) ... so some guesses from me. Firstly, I know that some OEMs do things a little different and this may explain why this looks strange to me. I am going to guess that your recovery partition is not hidden? You can see it in Computer? If so, was it always this way? OR it is possible that you have a Windows 7 installation DVD inserted! :w00t:

Now some things that I do know. See the object marked as {current}, this is your OS. You are missing some information there! You are missing (at least) the recoverysequence and recoveryenabled settings. These are in place to point Windows to the GUID for your recovery partition.

Anyways, the first "identifier" is for your recovery partition, however it is pointing at your OS volume....

Try get some results if you run this command elevated:

reagentc /info

jaclaz

jaclaz

Posted
Posted

Since you are using tinyhexer, you may find my little (as always half-@§§ed ) scripts for it, handy.

Here:

http://reboot.pro/8734/

I can see a problem right away, the parition table states that the 0C partition is starting at LBA 1914456064 and extends for 39063552 sectors.

The PBR data states that there are 1900271616 sectors before and that the volume extends for 39063552 sectors.

Please note how the "previous" NTFS partition actually starts @ #1900271616 in the MBR partition table.

WHY this happened (and WHICH of the two values is the right one) is another thing :ph34r: , if I were you I would access the PhysicalDrive with tinyhexer and save sectors #1914456064 and #1900271616 and find out which one is the actual PBR of THAT volume.

jaclaz

DiracDeBroglie

DiracDeBroglie

Posted
  • Author
Posted (edited)

I can see a problem right away, the parition table states that the 0C partition is starting at LBA 1914456064 and extends for 39063552 sectors.

The PBR data states that there are 1900271616 sectors before and that the volume extends for 39063552 sectors.

Please note how the "previous" NTFS partition actually starts @ #1900271616 in the MBR partition table.

WHY this happened (and WHICH of the two values is the right one) is another thing :ph34r: , if I were you I would access the PhysicalDrive with tinyhexer and save sectors #1914456064 and #1900271616 and find out which one is the actual PBR of THAT volume.

jaclaz

Jaclaz, YOU'RE MY HERO!! I'm truely convinced that in Madame Tussauds in London they should create a new category called REAL HEROES and put a wax statue of you in that category. Or even better, they should revive the series "HEROES" (http://www.imdb.com/title/tt0813715/) and introduce a whole new hero called JACLAZ who's got the ability to control computers from distance just by "thinking"; I bet a revival or a come-back of the series with JACLAZ as hero would be a hit. You better get in touch with the producer Tim Kring --- also, get your character JACLAZ already patented or somehow intellectually protected.

When I read your response I pretty much realized right away what the problem was. I had the figures and the solution right under my nose all the time and didn't see it; I also had the tools right on top of it but litterly didn't see it; bloody hell. I opened the usual old soft: PowerQuest's Partition Table Editor (PTEDIT32.EXE) and there it was:

post-340011-0-66095700-1341871256_thumb.

The Sectors Before in the MBR and the Hidden Sectors in the bootsector (PBR) were different. I realized immediately the PBR was wrong. So I copied the Sectors Before (MBR) to the Hidden Sectors (PBR) pane, and saved it. The recovery partition booted correctly and the Win7HP re-installation application started immediately.

The recovery partition was first located on the outermost tracks of the system HDD. As I want to save the outermost (and highest data rate) tracks for the system partition, or a pagefile partition later on, I cloned/imaged/copied (with GPartEd LiveCD) the recovery partition to the innermost tracks, where I performed some tests and all was ok. After that I shrunk the partition from 25GB to 20GB, as the partition contained only 17GB of data, thereby leaving another 5GB unallocated space behind the recovery partition at the innermost tracks of the HDD. I ran again some tests and all was ok. Then, I took a clone/image/copy of the relocated/shifted recovery partition, using the GPartEd LiveCD, onto my external backup HDD.

The last operation I performed on the recovery partition on the system HDD was again a shift (GPartEd) towards the very end as to recycle the last unallocated 5GB on the innertracks of the system HDD. Although the last operation kept the Sectors Before (MBR) and the Hidden Sectors (PBR) on the system HDD consistent, the Sectors Before (MBR) on the system HDD were definitely not consistent anymore with the Hidden Sectors (PBR) of the recovery partition CLONE/IMAGE on the backup HDD because I performed the last 5GB shift after I took the clone/image.

As I continued working (fiddling actually) on the recovery partition, I decided to continue with a fresh re-start and re-imaged my clone/image from the external backup HDD back onto the system HDD, thereby making the Sector inconsistency a matter of fact.

Lesson to be learned, if you take a clone/image, do not shift the orignal partition anymore!! (Unless you got Hero behind you.)

I still have a few questions but I'll post them later. It's bed time now.

j

Edited by DiracDeBroglie
jaclaz

jaclaz

Posted
Posted

Good :).

That explains the different partition start address (and the flashing cursor), the initial BPB broken diagnosis was correct.

.

But I wonder about the differences in sectors 7 and 12. :unsure:

About the Madame Tussaud's idea, the wax statues tend to be mainly of dead people :ph34r: , so I would gladly pass :whistle: for an adequate number of years from now ;).

jaclaz

DiracDeBroglie

DiracDeBroglie

Posted
  • Author
Posted

Good :)..

But I wonder about the differences in sectors 7 and 12. :unsure:

About the Madame Tussaud's idea, the wax statues tend to be mainly of dead people :ph34r: , so I would gladly pass :whistle: for an adequate number of years from now ;).

jaclaz

As for Madame Tussauds in London, most folks are alive and kicking, especially the last holds for footballer David Beckham.

From the links you gave me FAT32 uses mainly sector 0, but Microsoft has started to use also sector 1 and -2, with backups in sectors, 6, 7 and 8. As far as I understood from wiki (http://en.wikipedia.org/wiki/File_Allocation_Table) sector 12 is used to put an extended bootloader in there. I'm not sure where the backup of sector 12 would reside.(?) I had a look in sectors 17, 18 and 19 hoping to find a backup of sector 12 in there, but nope, nothing, niks, nada,... At first sight, It looks like sector 12 is not being backuped, but I could be completely wrong here.

I noticed there are no differences between sector 0 and sector 6, a slight difference between sector 1 and sector 7, and no difference between sector 2 and sector 8. Attached are 4 images to support that:

post-340011-0-78551500-1341918141_thumb.

post-340011-0-44154400-1341918254_thumb.

post-340011-0-39221000-1341918282_thumb.

post-340011-0-81242900-1341918305_thumb.

I am not all too sure about the difference between sector 1 and sector 7, is it serious, should I copy sector 7 onto sector 1? I have to wait and see how the recovery partition behaves. But one thing is for sure, I'm still stuck with the error message: "System Error." "Code: 5." "Access is denied." when trying to write back an updated sector in Tiny Hexer. What could be the possible reasons for that error?

johan

jaclaz

jaclaz

Posted
Posted (edited)

No. :(

You got it wrong.

The bootsector of a FAT32 is three sectors long.

First one contains, besides CODE the BPB (filesystem DATA).

Second contains some "redundant" filesystem DATA.

Third one contains just CODE.

On DOS/Win9x/ME the three sectors are #0, #1 and #2 (quite logical).

On NT based systems they are #0, #1 and #12 <-at least up to 2K/XP/2003 :unsure:.

On ReactOS they are #0, #1 and #14.

The backup is always #6 and #7 (for #0 and #1) and #8 (for #2) , sector #12 (or #14) is not backed up.

If i give links is because you should read THOSE links:

http://thestarman.narod.ru/asm/mbr/index.html

http://thestarman.narod.ru/asm/mbr/ntFAT32BR.htm

and more on THAT site, like:

http://thestarman.narod.ru/asm/mbr/MSWIN41.htm

Wikipedia is a very nice thing :thumbup but in some cases it has incomplete, partially deceiving or plainly wrong info :ph34r: .

In this case it is simply "vague" :w00t: and doesn't take into account the differences between different MS OS's:

While many other vendors have continued to utilize a single-sector setup (logical sector 0 only) for the bootstrap loader, Microsoft's boot sector code has grown to spawn over the first three sectors 0, 1 and 2 since the introduction of FAT32, with sector 0 depending on sub-routines in sector 2. The Backup Boot Sector area at sector 6 consists of three sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader.

The "main entry" is correct for DOS/Win9x/Me, whilst the "some cases" represent any NT system that supports FAT32, i.e. from 2K onwards.

Now, be nice, get a Virtual disk of any kind, create a disk and format it with the FAT32 filesystem, and verify that:

Sector #0 = Sector #6

Sector #1 = Sector #7

Sector #12 = Sector #8

if they are not, this should mean that the Vista :ph34r: or 7 changed again something. See edit below....

I am not all too sure about the difference between sector 1 and sector 7, is it serious, should I copy sector 7 onto sector 1? I have to wait and see how the recovery partition behaves. But one thing is for sure, I'm still stuck with the error message: "System Error." "Code: 5." "Access is denied." when trying to write back an updated sector in Tiny Hexer. What could be the possible reasons for that error?

You can leave sectors #1 and #7 alone, the data in it (them) are actually almost never used.

You are falling in the "Access is denied" issue with Windows 7, right?

It is one of the "nice" protection features.

See:

http://reboot.pro/12413/

EDIT:

I take it back :blushing: .

The sector #12 is NOT backed up on sector #8 (actually it is NOT backed up anywhere) even on 2K/XP.

This is not a real problem, as it contains only CODE, so you can re-create it copying it from any other volume formatted under the same OS.

jaclaz

Edited by jaclaz
DiracDeBroglie

DiracDeBroglie

Posted
  • Author
Posted

This seems kinda strange to me (although I am no expert) ... so some guesses from me. Firstly, I know that some OEMs do things a little different and this may explain why this looks strange to me. I am going to guess that your recovery partition is not hidden? You can see it in Computer? If so, was it always this way? OR it is possible that you have a Windows 7 installation DVD inserted! :w00t:

Now some things that I do know. See the object marked as {current}, this is your OS. You are missing some information there! You are missing (at least) the recoverysequence and recoveryenabled settings. These are in place to point Windows to the GUID for your recovery partition.

Anyways, the first "identifier" is for your recovery partition, however it is pointing at your OS volume....

Try get some results if you run this command elevated:

reagentc /info

C:\Windows\system32>reagentc /info

Extended configuration for the Recovery Environment

Windows RE enabled: 1

Windows RE staged: 0e

Setup enabled: 0

Custom Recovery Tool: 0

WinRE.WIM directory:

Recovery Environment: \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\8c

b2d9b4-7c05-11de-842e-b4611d44fefa

BCD Id: 8cb2d9b4-7c05-11de-842e-b4611d44fefa

Setup Files:

Recovery Operation: 4

Operation Parameter:

Boot Key Scan Code 0x0

REAGENTC.EXE: Operation successful

C:\Windows\system32>

I got a question about the command reagentc, if I do >help in the cmd console a list of commands appears, but reagentc is not in there. I finally have found ReAgentc.exe in System32 folder. How could I see some kind of a help list of all those Apps/commands available (in the Sys32 folder) in the cmd console?

The recovery/re-install partition (20GB) is normally hidden but I switch it to unhidden (visible) and boot on-and-off with a GPartEd LiveCD. Sometimes I use the "Set ID=1C (or 0C) override" in the Diskpart console.

About your remark about the recoverysequence and recoveryenabled settings, what do you mean with "recovery"? Do you mean the re-install of Win7HP (many GBs), or do you mean the repair tools (160MB) under the folder Recovery in the root of the C:\ system HDD? The repair tools are not a problem, they pop up in the Advanced Boot Options in case there is a issue with the Win7 system partition. However, I've also put a link to the WinRE.WIM in the Windows Boot Manager (BCD editing using EasyBCD) and that allows me to enter the repair at any time.

j

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

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