INACCESSIBLE_BOOT_DEVICE

  • Thread starter Thread starter Bob
  • Start date Start date
B

Bob

Here is a simple procedure for getting out of trouble if you get a
BSOD because of a corrupt Master Boot Record.

Most of the time when the MBR becomes corrupted, Windows will schedule
CHKDSK to run next time you boot, which usually fixes the problem. But
sometimes you can't get far enough into the boot process because you
get a BSOD before CHKDSK can run. You can try to restore the last
known good configuration with F8 but that is not reliable.

Assuming the disk can be salvaged at all, you can mount it as a second
device. You will need another disk from which to boot - an ealier
clone for example. It also helps to have removeable drive bays so you
can put the correct drives in the proper place. Otherwise you may have
to tell the BIOS to boot from a different drive.

Once you get Windows running on the second drive, see if your bad
drive shows up as a device (look in My Computer). If it is alive, go
to the Start button and select Run. Type the command

chkdsk d: /f

where d: is the bad drive. CHKDSK will nowattempt to reconstruct the
MBR and some other stuff like security file descripters and whatnot.
If CHKDSK goes to completion with no residual errors, then the
corrupted disk has likely been fixed.

There are other ways to get around BSODs but this one is simple and
does not require any third-party software.
 
Bob said:
Here is a simple procedure for getting out of trouble if you get a
BSOD because of a corrupt Master Boot Record.

Most of the time when the MBR becomes corrupted, Windows will schedule
CHKDSK to run next time you boot, which usually fixes the problem. But
sometimes you can't get far enough into the boot process because you
get a BSOD before CHKDSK can run. You can try to restore the last
known good configuration with F8 but that is not reliable.

Assuming the disk can be salvaged at all, you can mount it as a second
device. You will need another disk from which to boot - an ealier
clone for example. It also helps to have removeable drive bays so you
can put the correct drives in the proper place. Otherwise you may have
to tell the BIOS to boot from a different drive.

Once you get Windows running on the second drive, see if your bad
drive shows up as a device (look in My Computer). If it is alive, go
to the Start button and select Run. Type the command

chkdsk d: /f

where d: is the bad drive. CHKDSK will nowattempt to reconstruct the
MBR and some other stuff like security file descripters and whatnot.
If CHKDSK goes to completion with no residual errors, then the
corrupted disk has likely been fixed.

There are other ways to get around BSODs but this one is simple and
does not require any third-party software.
Click to expand...


Boot using the Windows 2000/XP install CD and go into Recovery Console mode
to run FIXMBR. You can also use a DOS/Win9x bootable floppy that has the
FDISK program to run "FDISK /MBR". The bootstrap programs are slightly
different in size but both function equivalently and reside within the boot
program area of the MBR.

I wasn't aware that CHKDSK ever touched the boot program area of the MBR.
In fact, it would be very hazardous for CHKDSK to touch anything in the MBR.
If, for example, the user had Windows in one primary partition and Linux in
another primary partition and was using a non-standard boot manager in the
MBR's boot program area to let the user select which OS to load, then CHKDSK
would corrupt the entire setup. I've used CHKDSK while using a boot manager
in the MBR and it did *not* alter the boot program code there.

There are hazards in overwriting the boot program in the MBR. If it
contained a boot manager, drive overlay manager, encryption security
product, file recovery, or other utility then you end up destroying that
functionality. If you got nailed by a boot virus (that occupies the MBR's
boot code area and NOT the boot sector of a partition), it is also possible
that the virus moved the partition table so it as a different offset or
somewhere completely different, so overwriting the MBR boot code area with
the standard bootstrap program that expects to see the partition table at
its standard offset in the MBR results in losing all your partitions (i.e.,
the MBR boot program cannot find the partition table). See:

From my posts in a Google copy of a thread:
http://snipurl.com/m8cv
http://snipurl.com/m8cz
http://snipurl.com/m8d4
 
Boot using the Windows 2000/XP install CD and go into Recovery Console mode
to run FIXMBR. You can also use a DOS/Win9x bootable floppy that has the
FDISK program to run "FDISK /MBR". The bootstrap programs are slightly
different in size but both function equivalently and reside within the boot
program area of the MBR.
Click to expand...

I tried that first. I have a diskette with Win98 FDISK. I use it to
bugger the signature on cloned drives. But it did not work. There was
too much corruption in other parts of the file structure.
 
Boot using the Windows 2000/XP install CD and go into Recovery Console mode
to run FIXMBR. You can also use a DOS/Win9x bootable floppy that has the
FDISK program to run "FDISK /MBR". The bootstrap programs are slightly
different in size but both function equivalently and reside within the boot
program area of the MBR.

I wasn't aware that CHKDSK ever touched the boot program area of the MBR.
In fact, it would be very hazardous for CHKDSK to touch anything in the MBR.
If, for example, the user had Windows in one primary partition and Linux in
another primary partition and was using a non-standard boot manager in the
MBR's boot program area to let the user select which OS to load, then CHKDSK
would corrupt the entire setup. I've used CHKDSK while using a boot manager
in the MBR and it did *not* alter the boot program code there.

There are hazards in overwriting the boot program in the MBR. If it
contained a boot manager, drive overlay manager, encryption security
product, file recovery, or other utility then you end up destroying that
functionality. If you got nailed by a boot virus (that occupies the MBR's
boot code area and NOT the boot sector of a partition), it is also possible
that the virus moved the partition table so it as a different offset or
somewhere completely different, so overwriting the MBR boot code area with
the standard bootstrap program that expects to see the partition table at
its standard offset in the MBR results in losing all your partitions (i.e.,
the MBR boot program cannot find the partition table). See:

From my posts in a Google copy of a thread:
http://snipurl.com/m8cv
http://snipurl.com/m8cz
http://snipurl.com/m8d4
Click to expand...

This time I captured what CHKDSK was doing and I discovered that I had
read it wrong. It's not the MBR, it's the "Master File Table" (MFT)
that was corrupted.

I have started another thread on this forum entitled "Corrupt NTFS
Filesystem" where I describe the same problem in more detail,
including presenting the actual output of CHKDSK.
 
Bob said:
I tried that first. I have a diskette with Win98 FDISK. I use it to
bugger the signature on cloned drives. But it did not work. There was
too much corruption in other parts of the file structure.
Click to expand...

Well, FIXMBR won't ever fix your corrupted file system. It has no clue nor
give a gnat's fart about what file system you use. A file system is used
ONLY within a partition, not in the MBR. The FIXMBR program only overwrites
the first 446 bytes of the first physical sector of the first hard drive,
and it doesn't use a file system to do so. By the time the MBR bootstrap
program loads and transfers control to the boot program in the *partition's*
boot sector, the MBR bootstrap isn't even running anymore so it never knows
what file system is in use.

If you have problems with your file system then use utilities to fix your
file system. They will do nothing to fix your MBR's boot program. If you
need to replace or fix the MBR, that has nothing to do with your file system
in a partition.
 
Back
Top