There is error in System event log like this one: "The device, \Device\Harddisk1\DR1, has a bad block."

Because of above I created Raid 1 on this disk and other one. I'm using Windows Server 2008 R2 software RAID volumes.

Volume in Disk Manager is marked as "Failed Redundancy" and "At Risk". I could command to "Reactivate Disk" and it's starts to re-sync, but after a while it stops and returns to previous state. It stops re-sync on bad block on old disk and creates same error in System event log.

Old disk status is Errors, new disk status is Online.

How can I check that there is exact copy of the old disk on new one ? It is server machine so I would prefer to keep it running during this check.

I just want to get rid of this faulty disk and keep it as it is on new one. I do not care about bad sectors as I have data backups. I just do not want to reinstall whole thing.

Disk management screen

3 Answers 3


First of all:

  1. Creating a RAID 1 volume after the fact is not a useful way to deal with a disk error.

  2. Because the creation of the RAID 1 mirror fails at the point where the bad block is reached, you can safely assume that you do not have a complete copy of the original disk with the bad block. There is no need to verify this assumption.

  3. After you unmount Disk 1, running chkdsk /r on drives C: and G: should mark the bad sectors, move any readable data to other areas of the drive, and prevent future read errors pertaining to the same bad sectors. It will not prevent further deterioration of the (potentially failing) disk with bad sectors.

If chkdsk /r doesn't fix the problem, here's one method for moving all recoverable data to a new disk, avoiding a failure due to the bad blocks:

  1. If you haven't already done so, make sure you have a current and full backup.
  2. In Windows Disk Management, unmount and reformat Disk 1.
  3. Shut down the computer properly.
  4. Boot into Linux using a live CD or live USB stick, e.g. PartedMagic. Even an Ubuntu installation disc will work.
  5. Mount both disks. Figure out which physical volume is the new disk and which one is the old disk. (Looking at the output of the mount command, run without any parameters, may help.)
  6. Copy from the the old hard drive to the new hard drive using the dd command. Be sure to specify the noerror and sync options so that the bad blocks will be ignored. Their contents (which are already lost) will be replaced with zeroes on the new drive, so any files spanning the bad blocks will be corrupted. However, these files are already unreadable, so no additional harm will be done:

    dd if=/dev/<Disk0> of=/dev/<Disk1> bs=512 conv=noerror,sync

Substitute the actual device identifiers (e.g. sd0, sd1, etc.) in place of <Disk0> and <Disk1> above. Do not accidentally copy from the new disk to the old disk, as this would be catastrophic. Additionally, be forewarned that this operation will run slowly (i.e. much slower than the sequential read/write speeds of the disks) due to the small block size. However, I don't think it will work to use noerror and sync together (to ignore bad sectors and pad them out with zeroes on the new drive, without losing any recoverable data) unless dd has its block size set to the actual size of a disk sector.

  • Are the dashes in the dd arguments typos or some specific dd version? It only works with dd if=/dev/... (no dash before if=) on all versions of dd I have access to.
    – chutz
    Nov 4, 2012 at 5:07
  • Definitely typos. (Removed.)
    – Skyhawk
    Nov 4, 2012 at 5:16
  • @ Miles Erickson : +1 useful advice, but I cannot fully agree with You.
    – rumburak
    Nov 6, 2012 at 13:54
  • @ Miles Erickson : Creating RAID 1 volume after the fact can be useful when damage is not significant and You want to keep the server running.
    – rumburak
    Nov 6, 2012 at 14:00
  • @ Miles Erickson : Disk 1 (the one with errors) is the only disk with proper data. So I think You should swap disk 1 with disk 0 in Your answer.
    – rumburak
    Nov 6, 2012 at 14:08

Conceptually for the creation of the mirror to succeed all data from the source volume must be readable so that the destination disk contains an exact copy of the source.

All modern SATA drives have internal machinary to automatically remap bad blocks to an alternate location. Drives can do this remapping automatically under certain conditions such as on a write failure to a certain location. Drives cannot however remap on a subsequent read failure as the contents of the disk can't be read to remap the data. Thus leaving the error be is the least destructive behavior possible for the disk drive.

With todays massive multi-TB drives this happens even to an otherwise perfectly health disk. Just because a few blocks are not readable does not automatically follow by itself the disk is bad or needs to be replaced.

chkdsk commands to detect and repair bad blocks are meaningless when you setup a mirror in windows and most other operating systems. Chkdsk will not correct these problems. The reason is chkdsk works at the file system level and stores bad blocks in the filesystems structure. RAID works at the disk level below the file system and thus is totally oblivious to both the existance of NTFS and NTFS's bad block list.

The way to fix read errors on disks with internal remapping is simply to write to blocks that can't be read. If the area is defective the disk will remap the area transparently and subsquent reads to it will then succeed. This is quickest and least effort path to correcting a read error so the disk can be synced up but perhaps not the safest as the act of writing seals all hope of recovering the unreadable data. Also if applicable writing to a disk you may otherwise suspect to be faulty is not a winning policy.

Unfortunatly I do not know of the existance of a utility that will read and overwrite bad blocks if they cannot be read after a reasonable number of read attempts have exhasted. Previously I've had to use 'dd' to do this manually by scanning for unreadable locations and writing over them.

A much safer way is to make a copy of the disk using a tool such as ddrescue (Boot with g4l (Ghost4Linux) iso image available from sourceforge) dd rescuse starts by copying as much data as it can then finally retries those blocks with read errors until all retries have been exhausted. If you suspect the drive may be failing this is a much safer approach.


Update: This is not the correct answer according to Microsoft.

You can run a filesystem check for bad blocks which will tell you if there is any unreadable data on the disks. Right click on each disk (C: and G:), select Tools, Error-checking. And make sure you select "Scan for and attempt recovery of bad sectors".

If there is some unreadable data on Disk 0, you will know about it as Windows will end up marking Disk 0 as bad, too.

For the command line users:

chkdsk /R G:
chkdsk /R C:

Not sure what to do about the 100MB boot partition, but my bet is you can check it as well (it does say it is NTFS).

  • This is chkdsk command. Was thinking about that as well.
    – rumburak
    Oct 31, 2012 at 3:50
  • Good one. I updated the answer.
    – chutz
    Oct 31, 2012 at 4:34
  • "When it establishes software mirrors on dynamic disks, DMIO does a sector-by-sector copy of the source disk to the destination disk. DMIO does not know or care which sectors contain data or which sectors may have been marked "bad" by Chkdsk. Chkdsk marks those bad sectors only in the file system (FAT, FAT32, or NTFS), so that the file system does not try to use them. DMIO operates below the file system, and if it finds I/O errors while reading from a sector on the source disk or while trying to write the data to the destination disk, it aborts the mirroring operation."
    – rumburak
    Oct 31, 2012 at 22:25
  • support.microsoft.com/kb/325615/en-us
    – rumburak
    Oct 31, 2012 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.