Windows 8 Is my MBR really 'broke'?

IrvSp

Extraordinary Member
OK, it seems my W8 system is possibly in a bit of trouble...

I ran CHKDSK on my C: drive, and at the end saw this :

=============
Errors detected in the Boot File.
Windows has checked the file system and found problems.
Please run chkdsk /scan to find the problems and queue them for repair.
==============

Hmm, system boots just fine and I appear to have NO errors. I am on an SSD and it is quite possible that I did 'mess up' something in the boot record when I migrated a large partition that was bootable into the much smaller SSD.

So I ran CHKDSK /SCAN... BIG MISTAKE...

At the end it asked to cue it up to check the disk on boot. I allowed it. It ran and then started a troubleshooter, which ran PC Diagnostics and then a message that it could take up to 1 hour to fix. Almost instantly the system rebooted, AND ran chkdsk again. Off it went to the troubleshooter... and it just continued in this loop.

OK, I did break the loop and got an screen with options... one was to go into W8 directly, and again, the loop started up again. Argh... broke into it and I had other options, REFRESH, RESTORE, or shutdown. OK, Shutdown.... nope, power on started the loop again...

UGLY... so I did a REFRESH basically losing installed non-MS store programs. No problem, I've got an IMAGE.

When it was restored, it was OK on CHKDSK... and the few Store apps (Live Tiles) that didn't run before did... good.

I restored my image, and poof, CHKDSK shows the error again. However, this system has been booting for months with no problem and I assume the 'corruption' was present, and will now too with the 'problem'. I just can't run CHKDSK on it?

CAN NOT find anything about this on the web?

Thinking the MBR could be 'damaged'? There are programs to fix that and the boot record, but I'm not about to try this as it could break me?

HELP and SUGGESTIONS appreciated...

Windows 8 remember. Ran CHKNTFS and the FS is OK and the disk is NOT dirty....

I ran a program to check the MBR (MBRCheck.exe), it seems OK?

===============
\\.\C: --> \\.\PhysicalDrive0 at offset 0x00000000`00100000 (NTFS)
\\.\D: --> \\.\PhysicalDrive2 at offset 0x00000000`04700000 (NTFS)
\\.\K: --> \\.\PhysicalDrive2 at offset 0x0000002e`aae00000 (NTFS)
\\.\L: --> \\.\PhysicalDrive1 at offset 0x00000000`00100000 (NTFS)
\\.\X: --> \\.\PhysicalDrive2 at offset 0x00000003`c4700000 (NTFS)

PhysicalDrive0 Model Number: CorsairCSSD-F115GB2-A, Rev: 2.4
PhysicalDrive2 Model Number: WDCWD7501AALS-75J7B0, Rev: 05.00K05
PhysicalDrive1 Model Number: ST31000528AS, Rev: CC34

Size Device Name MBR Status
--------------------------------------------
107 GB \\.\PhysicalDrive0 Windows 7 MBR code detected
SHA1: 4379A3D43019B46FA357F7DD6A53B45A3CA8FB79
698 GB \\.\PhysicalDrive2 Windows 7 MBR code detected
SHA1: 4379A3D43019B46FA357F7DD6A53B45A3CA8FB79
931 GB \\.\PhysicalDrive1 Windows 98 MBR code detected
SHA1: 48F01D7E76A0F3C038D08611E3FDC0EE4EF9FD3E
==============

C: is the SSD that has the problem.
 
Could you attach a picture of your Disk Management picture on your next post. Use the Snipping tool and attach using the paperclip on the advanced reply?

I am not familiar with the utility you used to supply the info, so I cannot comment on that.

Did you modify the Windows 8 partitions prior to or during the move to the SSD?
 
Check the SSD has all it's firmware updates ect. Same with the motherboard update to the latest bios.
 
Could you attach a picture of your Disk Management picture on your next post. Use the Snipping tool and attach using the paperclip on the advanced reply?

I am not familiar with the utility you used to supply the info, so I cannot comment on that.

Did you modify the Windows 8 partitions prior to or during the move to the SSD?

Disk Management snapshot attached.

Capture.jpg

No, the X: drive on DISK 2 was the original drive that was booted. System is a Dell, and D: is Dell's recovery, useless as it really is for Vista, but I don't need the space so I've left it. X: went from Vista (as shipped) to W7 and now W8. The SSD was cloned almost 2 years ago when it was W7.

I believe W8's CHKDSK was changed to work on UEFI BIOS's and since it is different, it might be part of the problem, but on a REFRESH of W8 it works fine?
 
Check the SSD has all it's firmware updates ect. Same with the motherboard update to the latest bios.

Yeah, SSD has the lastest 2.4 firmware, first thing I checked. Computer is a Dell XPS 435T, almost 4 years old and the BIOS is the latest but hasn't been updated in a LONG time. Dell doesn't even provide W8 drivers for it. Luckily when I went to install W8 the network on the motherboard didn't work, but they had updated network drivers on the 8500 for W8 which is a follow-on XPS and that driver works fine.

No problems booting or running, just CHKDSK can't complete.
 
If I understand your post correctly, you ran chk dsk on the SSD?

This would have been a waste of time. SSDs do not have sectors, but chkdsk would see warn portions as "bad" sectors and report them as errors. The benefit of SSDs is that they automatically shut down any portions that show signs of error, so the chkdsk would be superfluous.
I understand, from experts, that it can actually be a bad idea to run chkdsk on an SSD.
For a general clean up, the Windows 8 defrag has a built in facility designed for SSDs. Have a look here:

10 hidden features in Windows 8 | ITworld
 
If I understand your post correctly, you ran chk dsk on the SSD?

This would have been a waste of time. SSDs do not have sectors, but chkdsk would see warn portions as "bad" sectors and report them as errors. The benefit of SSDs is that they automatically shut down any portions that show signs of error, so the chkdsk would be superfluous.
I understand, from experts, that it can actually be a bad idea to run chkdsk on an SSD.
For a general clean up, the Windows 8 defrag has a built in facility designed for SSDs. Have a look here:

10 hidden features in Windows 8 | ITworld

Thanks for your reply.

That reference is old and before W8 shipped. Some things might have changed?

For instance, the OPTIMIZER is different :

Capture.jpg

It does know about SSD's and DOES NOT support them. Trim is a function within the SSD.

I don't think there are any warnings about running CHKDSK on an SSD, but there are for DEFRAGMENTING one. CHKDSK repairs FILE SYSTEM errors, and they can occur on an SSD as well.
 
There were some changes to chkdsk in Windows 8, but I do not know if UEFI is related to the problem.

My system would run chkdsk all the time if I swapped the dual boot for the other OS. It did not find errors, but had some reason it wanted to run.

You might try turning off the Windows 8 Fast Startup in the Power Panel, Choose what the power buttons do, Shutdown settings, for testing.

Do you boot to anything other than the SSD?

If you want us to check, you might open an administrative command prompt and type the following:

bcdedit /enum all > %userprofile%\Desktop\bcdtext.txt

Then attach the text file from your desktop (hopefully) on your next post.

Edit: I also just noticed your Page File is on the second drive. I assume you moved it there? That might be related to the situation, but no evidence of it, so far.
 
Last edited by a moderator:
There were some changes to chkdsk in Windows 8, but I do not know if UEFI is related to the problem.

My system would run chkdsk all the time if I swapped the dual boot for the other OS. It did not find errors, but had some reason it wanted to run.

You might try turning off the Windows 8 Fast Startup in the Power Panel, Choose what the power buttons do, Shutdown settings, for testing.

Do you boot to anything other than the SSD?

If you want us to check, you might open an administrative command prompt and type the following:

bcdedit /enum all > %userprofile%\Desktop\bcdtext.txt

Then attach the text file from your desktop (hopefully) on your next post.

Edit: I also just noticed your Page File is on the second drive. I assume you moved it there? That might be related to the situation, but no evidence of it, so far.

Sorry, didn't see this post... never got notified it existed?

No need to make it a text file, just copied the output :

==========================
C:\WINDOWS\system32>bcdedit /enum all

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=C:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {7b06eafc-c4c7-11de-b580-0023aee6d1ef}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30

Windows Boot Loader
-------------------
identifier {572bcd55-ffa7-11d9-aae0-0007e994107d}
device unknown
path \Windows\System32\boot\winload.exe
description Windows Recovery Environment
osdevice unknown
systemroot \Windows
nx OptIn
detecthal Yes
winpe Yes

Windows Boot Loader
-------------------
identifier {7b06eafa-c4c7-11de-b580-0023aee6d1ef}

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.exe
description Windows 8
locale en-US
inherit {bootloadersettings}
recoverysequence {7b06eafe-c4c7-11de-b580-0023aee6d1ef}
recoveryenabled Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {7b06eafc-c4c7-11de-b580-0023aee6d1ef}
nx OptIn
bootmenupolicy Standard
hypervisorlaunchtype Auto

Windows Boot Loader
-------------------
identifier {7b06eafe-c4c7-11de-b580-0023aee6d1ef}
device ramdisk=[C:]\Recovery\7b06eafe-c4c7-11de-b580-0023aee6d1
ef\Winre.wim,{7b06eaff-c4c7-11de-b580-0023aee6d1ef}
path \windows\system32\winload.exe
description Windows Recovery Environment
locale en-US
inherit {bootloadersettings}
displaymessage Recovery
displaymessageoverride Recovery
osdevice ramdisk=[C:]\Recovery\7b06eafe-c4c7-11de-b580-0023aee6d1
ef\Winre.wim,{7b06eaff-c4c7-11de-b580-0023aee6d1ef}
systemroot \windows
nx OptIn
bootmenupolicy Standard
winpe Yes

Resume from Hibernate
---------------------
identifier {5460d9d2-d391-11dc-9d9f-aba67a8797c5}
device partition=C:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale en-US
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No

Resume from Hibernate
---------------------
identifier {7b06eafc-c4c7-11de-b580-0023aee6d1ef}
device partition=C:
path \WINDOWS\system32\winresume.exe
description Windows Resume Application
locale en-US
inherit {resumeloadersettings}
recoverysequence {7b06eafe-c4c7-11de-b580-0023aee6d1ef}
recoveryenabled Yes
allowedinmemorysettings 0x15000075
filedevice partition=C:
filepath \hiberfil.sys
bootmenupolicy Standard
debugoptionenabled No

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

Windows Legacy OS Loader
------------------------
identifier {ntldr}
device unknown
path \ntldr
description Earlier Version of Windows

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

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 {7b06eafb-c4c7-11de-b580-0023aee6d1ef}
ramdisksdidevice partition=C:
ramdisksdipath \Recovery\7b06eaf8-c4c7-11de-b580-0023aee6d1ef\boot.sdi

Device options
--------------
identifier {7b06eaff-c4c7-11de-b580-0023aee6d1ef}
description Windows Recovery
ramdisksdidevice partition=C:
ramdisksdipath \Recovery\7b06eafe-c4c7-11de-b580-0023aee6d1ef\boot.sdi

C:\WINDOWS\system32>
=======================

I don't see anything unusual in the above?

Yes, PAGEFILE moved. I've got 8GB's of RAM, never swap, so why waste space on an SSD?

Other W8 system is also on an SSD with a PAGEFILE on the mechanical drive. CHKDSK works fine there?

I've already done the disable of fast start, first thing I did?

I also looked at SECTOR 0 on the first disk. Only ONE partition defined, I was wondering if 3 were from the clone of the original drive, but only 1. Nothing in sector 0 seems odd, but I can only locate up to W7 the contents of Sector 0, not Win8, but I wouldn't have suspected a change to it anyway.

I'm on the old BIOS anyway, as is the other computer, both Dell's...
 
I agree the BCD output seems fairly normal, except for the remnants of a couple of other installs. Since they do not appear to be referenced, so they should not hurt.

You might try taking out the other two drives for testing to see if the Chkdsk stop.

You said the drive is not dirty, which I will assume you checked with the fsutil dirty query c: (or other drive letter) command?

I also looked at SECTOR 0 on the first disk. Only ONE partition defined, I was wondering if 3 were from the clone of the original drive, but only 1. Nothing in sector 0 seems odd, but I can only locate up to W7 the contents of Sector 0, not Win8, but I wouldn't have suspected a change to it anyway.
I don't know much about these comments, but I do not understand the "1 partitioned defined, what are 3" reference??

If you feel the Master Boot Record/Partition table may have erroneous data, have you tried using the Bootrec /fixmbr option? Does the utility you are using to check the MBR even know about Windows 8?
 
I agree the BCD output seems fairly normal, except for the remnants of a couple of other installs. Since they do not appear to be referenced, so they should not hurt.

You might try taking out the other two drives for testing to see if the Chkdsk stop.

You said the drive is not dirty, which I will assume you checked with the fsutil dirty query c: (or other drive letter) command?


I don't know much about these comments, but I do not understand the "1 partitioned defined, what are 3" reference??

If you feel the Master Boot Record/Partition table may have erroneous data, have you tried using the Bootrec /fixmbr option? Does the utility you are using to check the MBR even know about Windows 8?

Yes, used FSUTIL, besides, if the disk were marked dirty it would force CHKDSK on a re-boot, which is not happening.

When I cloned the SSD, it came from the X: partition (which was C: at the time) on the 3rd hard disk. It had 3 partitions on it. I was wondering if that partition data was copied over, hence the 3, but it wasn't.

BOOTREC /FIXMBR is basically when you can't boot as the MBR is damaged. Mine doesn't appear to stop booting. I have a program called HxD which can read and save disk sectors, that is how I read sector 0. Before I use BOOTREC I'm considering imaging C: again, doing a W8 refresh, copy Sector 0, restore the image and restore/rewrite sector 0. However, I may just do nothing right now. I don't think this is causing me any problems. I suspect at this point an MS CHKDSK problem that may get fixed in the future (update or Blue?).

Supposedly MBRCHECK is really a virus check on the MBR, and it doesn't say it is W8 supported, but I don't think the MBR changed since probably DOS?
 
I agree the BCD output seems fairly normal, except for the remnants of a couple of other installs. Since they do not appear to be referenced, so they should not hurt.

You might try taking out the other two drives for testing to see if the Chkdsk stop.

You said the drive is not dirty, which I will assume you checked with the fsutil dirty query c: (or other drive letter) command?


I don't know much about these comments, but I do not understand the "1 partitioned defined, what are 3" reference??

If you feel the Master Boot Record/Partition table may have erroneous data, have you tried using the Bootrec /fixmbr option? Does the utility you are using to check the MBR even know about Windows 8?

OK, bit the bullet, used the W8 Install CD and got to a COMMAND PROMPT.

Ran CHKDSK C: and got the same error, then did BOOTREC /FIXMBR and reran CHKDSK, same error, next did BOOTREC /FIXBOOT and re-ran CHKDSK, same error? Ran CHKDSK C: /SCAN and got a little more info...

Save the output from the W8 Install boot, from CHKDSK C:

=====================
Errors detected in the Boot File.
Windows has checked the file system and found problems.
Please run chkdsk /scan to find the problems and queue them for repair.
======================

From CHKDSK C: /SCAN
=================
The type of the file system is NTFS.
A function call was made when the object was in an incorrect state
for that function
A snapshot error occured while scanning this drive. Run an offline scan and fix.
Failed to transfer logged messages to the event log with status 50.
================

Note the LAST line, and I assumed it meant it put some info into the EVENT log!

So I restarted the computer and ran CHKDSK again for an elevated command prompt.

Got this tidbit,

=============
C:\WINDOWS\system32>chkdsk /scan
The type of the file system is NTFS.
Volume label is OS.
Stage 1: Examining basic file system structure ...
Stage 2: Examining file name linkage ...
Stage 3: Examining security descriptors ...
"chkdsk /scan" is aborting due to corruption found in the $Boot file.
"chkdsk /f" will be required to repair the volume.
================

$BOOT file!!! That is a backup one of the Meta NTFS files I think? Can't find much info on it though on the web nor these 'error' messages? None in the Event Viewer either?

Confused?
 
Hard to say what $Boot is referring to. There is a Boot folder that contains the BCD store, so it might be something in that, or possibly the old boot folder on what you have set as X:

If you are still running your system with all hard drives connected, you might think about removing the active status from X: just in case it is confusing the system.

Do you know for sure the SSD is set as the primary drive in the bios?

Since you must have assigned the drive letter X: to the old Windows partition, was that for some reason? It should also be noted that the Recovery environment uses X: drive designation for the RamDisk, but it probably does not see the designation you added so it might be OK.

If you want to remove the extra entries in the BCD store, we can do that.
 
Thanks for the reply, answers :

Hard to say what $Boot is referring to. There is a Boot folder that contains the BCD store, so it might be something in that, or possibly the old boot folder on what you have set as X:

SYSINTERNALS (NTFSInfo) NTFSINFO talks about $BOOT

=======
You might also be surprised to know that like the MFT, all NTFS meta-data are managed in files. For instance, there is a file called $Boot that is mapped to cover the drive's boot sector. The volume's cluster map is maintained in another file named $Bitmap. These files reside right in the NTFS root directory, but you can't see them unless you know they are there. Try typing "dir /ah $boot" at the root directory of an NTFS volume and you'll actually see the $boot file. NTFSInfo performs the equivalent of the "dir /ah" to show you the names and sizes of all of NTFS (3.51 and 4.0) meta-data files.
=====

Of course the DIR doesn't find it. I also looked on my wife's W8 computer which CHKDSK does work and DIR didn't find it either? Guess W8 is different.

The NTFSINFO output from my computer :

==================
NTFS Information Dump V1.01
Copyright (C) 1997 Mark Russinovich
Windows Sysinternals: Documentation, downloads and additional resources

Volume Size
-----------
Volume size : 109702 MB
Total sectors : 224669696
Total clusters : 28083712
Free clusters : 11327909
Free space : 44249 MB (40% of drive)

Allocation Size
----------------
Bytes per sector : 512
Bytes per cluster : 4096
Bytes per MFT record : 1024
Clusters per MFT record: 0

MFT Information
---------------
MFT size : 407 MB (0% of drive)
MFT start cluster : 786432
MFT zone clusters : 627840 - 630400
MFT zone size : 10 MB (0% of drive)
MFT mirror start : 9331757

Meta-Data files
---------------
<--- yes, it is a blank line, but the same on my wife's computer.
===================

Wife's data from her machine is similar as she has a larger SSD... only real difference, this line,

MFT mirror start : 2

but I'm not sure that is significant as long as it is on the drive?

If you are still running your system with all hard drives connected, you might think about removing the active status from X: just in case it is confusing the system.

Yes, I need the drive X: is on, that is where my data resides (K:).

Don't think it is confusing it at all? I also ran BOOTREC /SCANOS and it reported E: (during the install CD boot drive letters get allocated differently as it is X: and it goes sequentially as the drives are plugged into the motherboard).


Do you know for sure the SSD is set as the primary drive in the bios?

Yes

Since you must have assigned the drive letter X: to the old Windows partition, was that for some reason? It should also be noted that the Recovery environment uses X: drive designation for the RamDisk, but it probably does not see the designation you added so it might be OK.

Yeah, that 3rd physical drive became E: Not a problem.

If you want to remove the extra entries in the BCD store, we can do that.

Which one are you referring too?

By the way, after doing what I did and running CHKDSK /SCAN after the re-boot, it set something and the Action Center said I had to re-boot to fix the drive. I had NO choice so I did it, FULLY expecting to be in that loop again. I was, sort of, but this time when it re-booted after the CHKDSK ran and said it was repairing, W8 booted. Did NOT go into Troubleshooting. However, CHKDSK still says I have an error and need to run with /SCAN... sigh...
 
Something you might consider is whether the utilities you are running may actually be causing the problem. The article from SysInternals is dated 2006..I think that is even before Vista came out.

Dir /a should show any files in a directory, which is about the same as setting Explorer to show hidden and system files.... It will show the Recovery folder and boot folder if they are there, but your comments about the meta data files are over my head.

There is another utility you might try, if you have not, chkntfs.exe. It seems to have options for changing some of the disk checking parameters.

Is your system looking at a specific drive/partition? Since the utility you use to check the system show remnants of Win 98, I am guessing you have not cleaned the drive in a while. :)

Your BCD store entries which are not relevant are the following. Again, as far as I know, since they are not referenced they should not be involved...but who knows for sure. If you were to decide to remove them, I would strongly suggest you export the store so you can recover if something goes wrong. Using the bootrec /rebuildbcd command might get rid of them, but not sure. This process is covered in the Microsoft Link.

Use the Bootrec.exe tool in the Windows Recovery Environment to troubleshoot and repair startup issues in Windows

Windows Boot Loader
-------------------
identifier {572bcd55-ffa7-11d9-aae0-0007e994107d}
device unknown
path \Windows\System32\boot\winload.exe
description Windows Recovery Environment
osdevice unknown
systemroot \Windows
nx OptIn
detecthal Yes
winpe Yes

Windows Boot Loader
-------------------
identifier {7b06eafa-c4c7-11de-b580-0023aee6d1ef}

Resume from Hibernate
---------------------
identifier {5460d9d2-d391-11dc-9d9f-aba67a8797c5}
device partition=C:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale en-US
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No

Windows Legacy OS Loader
------------------------
identifier {ntldr}
device unknown
path \ntldr
description Earlier Version of Windows

Device options
--------------
identifier {7b06eafb-c4c7-11de-b580-0023aee6d1ef}
ramdisksdidevice partition=C:
ramdisksdipath \Recovery\7b06eaf8-c4c7-11de-b580-0023aee6d1ef\boot.sdi
 
Sorry to butt in here, but a few quick comments (I'm at work now, so it won't be much)

The $boot file is not visible by enabling viewing hidden files/folders.
Some quick research suggests that it's metadata included in the NTFS file system - and not easily viewable.
I'll be doing more research on this throughout the day (as knowledge of it is applicable to my job).

But, frankly, if chkdsk can't fix it - then the NTFS file system is damaged beyond repair (IMO) - although I suspect that there are ways to manually edit this file/metadata. As such, I'd suggest wiping the drive in question (after backing up the data). I'd also suggest TEMPORARILY removing any other drives (unplugging them) to ensure that they aren't a part of the problem. One the boot drive is up and running properly - then add the other drives back in to see if they cause problems.

Good luck!
 
Saltgrass, all the 'fix' stuff for booting all are for instance when you can't boot it seems.

As for some of the data collected, W98 has never been on this system. Same tools run on the other W8 system that has no problem with CHKDSK for instance shows Vista when MBRCHECK is run, and that system started life as a W7 computer.

CHKDSK does not indicate problems with the NTFS but the boot data, yet the system boots. I've dumped sector 0 and looked at the boot sector comparing it to what info I found on the web and it seems OK...

I did find this though, TestDisk - CGSecurity, and ran it. It might have the REAL reason for the problem...Capture.jpg

According to it, the partition sizes do not match?

I don't think this will do any harm? I can always run CHKDSK from a CD that is W7 PE if need be.
 
Sorry to butt in here, but a few quick comments (I'm at work now, so it won't be much)

The $boot file is not visible by enabling viewing hidden files/folders.
Some quick research suggests that it's metadata included in the NTFS file system - and not easily viewable.
I'll be doing more research on this throughout the day (as knowledge of it is applicable to my job).

But, frankly, if chkdsk can't fix it - then the NTFS file system is damaged beyond repair (IMO) - although I suspect that there are ways to manually edit this file/metadata. As such, I'd suggest wiping the drive in question (after backing up the data). I'd also suggest TEMPORARILY removing any other drives (unplugging them) to ensure that they aren't a part of the problem. One the boot drive is up and running properly - then add the other drives back in to see if they cause problems.

Good luck!

John, I really don't think the FS is damaged? See my last message... it could be a partition size setting. On my other W8 system most tools have similar results, and some don't make sense either?

The only think I've not done it seems is rebuild the BCD, see Steps to fix Windows 8 Master Boot record, as all other options I've already done.

Maybe that will do it, reset the partition size? Don't know?

I don't think the other drives are a problem either. The BOOTREC /SCANOS did find that the other bootable drive, X: was NOT in the boot record, which is what it should be.

In my last post, the one above this, with TESTDISK, I'm not even sure it is correct?
 
I found some stuff about $Boot. If it is accurate and you are using a hex editor, it mentions it is 426 bytes with an offset of 0x54 and contains bootstrap code.

The MFT mirror start you mention is also 2 on both of my systems. One with only the one partition for Windows 7 and one a UEFI install for Windows 8. I was checking c: on both systems, but on Windows 8, C: is not the bootable one.

Do you believe the info about the boot sector number being different from the actual partition size is a factor? I am not familiar with something to change just that number, but I believe something like the bootable home version of Partition Wizard can rewrite/repair the records for partitions.
 
Back
Top