Short answer: Write something new to the sector (even zeros - which a long format does).
Long Answer
Hard drives today try to hide bad sectors from the host computer. The host computer simply asks the drive to return the contents of a particular sector number. Normally the drive reads the sector, returns it to the host machine, and everything is fine.
The hard drive knows if the value it read is valid or not, because the drive uses Error-correcting code (ECC) to validate that the contents it read are correct. If the drive detects that the contents of the sector are invalid, it will retry the read. The hope is that if it simply reads it again, it might get the correct sector contents. It will keep retrying until it gets a good value, or it's reached it's time limit (formally known as the Command completion time limit, or CCTL).
During these retries, the drive will appear dead; as it is no longer responding to commands.
Spare Sectors
Most modern drives contain a number of "spare" sectors (e.g. 1,024 spare sectors). If the drive recognizes a sector as bad, it will stop using it. Any requests to read or write to that damaged sector will transparently be redirected to a spare sector. This marking off of a bad sector, and reallocating its data to a spare sector, is called a Reallocation Event. And the total number of sectors that have been reallocated (and so how many of your spare sectors have been used up) is the Reallocated Sector Count.
In this example from one of my own hard drives, 64 sectors were found to be bad. That means that 64 of the drive's spare sectors have been called into use:
ID Current Worst Threshold Raw
============================= ======= ===== ========= ===
(05) Reallocated Sector Count 192 192 140 64
On this same hard drive, there have been 4 Reallocation Events. This means that there were four occasions where the drive marked sectors as bad, and used spare sectors instead.
ID Current Worst Threshold Raw
============================= ======= ===== ========= ===
(05) Reallocated Sector Count 192 192 140 64
(C4) Reallocated Event Count 196 196 0 4
What if it can't ever read the data?
These actions of re-reading sectors, consuming spares, all behind the computer's back is a good thing. It means the host operating system doesn't have to deal with the issue of failing sectors. The drive itself can handle those details itself.
Bonus Chatter: In the olden days, your hard drive shipped with a sticker fastened to it. This sticker contained the Factory Defect List; the list of all known bad spots on the drive.
If you performed a low-level format of the drive, you had to use a tool to type in all the Cylinder-Head-Sector locations of the bad spots.
SCSI drives have a command, IOCTL_DISK_REASSIGN_BLOCKS, to tell them to reallocate a bad spot on the drive after the operating system detects it. In IDE drives this all happens automatically, without the need for operating system intervention.
Ideally the drive would recognize the sector is failing, move the data to a spare sector, and never use the original sector again. But what happens if the drive hasn't been able to read the sector successfully?
This is what Pending Sectors are. The drive has detected that a sector is failing, and needs to be remapped to a spare. But it cannot do that until it can successfully read the data. When the drive knows that a sector is bad, and needs to be remapped, but it cannot do it yet because it's waiting to get a good read from the sector: that's called the Pending Sector Count:
ID Current Worst Threshold Raw
============================= ======= ===== ========= ====
(05) Reallocated Sector Count 192 192 140 64
(C4) Reallocated Event Count 196 196 0 4
(C5) Current Pending Sector 100 100 0 2
My hard drive has 2 sectors that the drive recognizes as bad, but cannot be reallocated yet. If you were to read one of these ‘Pending sectors’, the drive would likely retry (and retry, and retry), and eventually return a read error to the host operating system:
Give up on the pending sector and it will get reallocated
There are two ways that the drive can finally reallocate the sector, and consume another spare sector:
- it finally gets a good read
- you don't care what's in the sector anymore
If the drive finally read the sector, then it knows that it can reallocate the sector.
The other way the drive can reallocate the sector is if you let it know that the contents of that sector are irrelevant; that you don't care what's in it anymore. How do you do that?
By writing something new to the sector.
Whenever you read from, or write to, a sector on a hard drive, you have to read/write the entire 512-byte sector1. You are not able to write only part of a sector. When the OS writes data to a sector, it has to specify the entire 512-bytes. If you tell the hard drive that you want these new contents to replace this bad sector, the drive then knows you don't even care what's currently in the bad sector. It can then Reallocate a bad sector to one of the spares, and the sector is no longer Pending.
This is why when people ask about having some Current Pending Sectors, the common advice is to use a tool (such as Western Digital's Data LifeGuard) to write all zero's to the drive.
By writing zeros to every sector on the drive, you are telling the drive that it can finally reallocate all those pesky pending sectors. After the wipe, all your Pending Sectors will become Reallocated Sectors:
ID Current Worst Threshold Raw
============================= ======= ===== ========= ====
(05) Reallocated Sector Count 192 192 140 66
(C4) Reallocated Event Count 196 196 0 5
(C5) Current Pending Sector 100 100 0 0
Note: It's not strictly necessary to use a "low level" tool like Western Digital's Data LifeGuard. If you instruct Windows perform a full format (i.e. non-Quick format) of a volume, it will writes zeros to every sector in the volume.
The OS filing system supports marking sectors as bad
Armed with this knowledge, we'll explore a commonly confusing scenario.
Before the advent of Integrated Drive Electronics (IDE), the host operating system was responsible for detecting bad sectors, retrying the reads, moving data to another sector, and marking old sectors as bad.
If you were to run a chkdsk /r c: using the host operating system, it would recognize that the "pending" sectors are bad, and mark them as bad itself, and never try to use them again:
> C:\Windows\system32>chkdsk /r c:
The type of the file system is NTFS.
Volume label is OS.
12 KB in bad sectors.
So assuming a 512-byte sector hard drive, 12 KB of ‘Pending Sectors’ or in this example 12KB marked by the OS as ‘bad sectors’, that would correspond to decimal 24 or hexadecimal 0x18 as would be shown by a S.M.A.R.T. disk utility such as Crystal Disk Information:
ID Attribute Name Current Worst Threshold Raw
============================= ======= ===== ========= ====
(C5) Current Pending Sector 100 100 0 18
Note: Western Digital’s Data LifeGuard v1.31 (latest as of 8/31/2017) utility does not appear to show the current S.M.A.R.T. ‘Raw’ counter values correctly.
Now if you perform a full format (which writes zeros to every sector in the volume):
That means all those sectors that were Pending are going to get reallocated. It is now safe for the filing system to use those sectors again. In order to instruct the filing system that those sectors are no longer "bad", you perform an option where it reevaluates bad sectors:
>chkdsk c: /B
where the command documentation says
/B NTFS only: Re-evaluates bad clusters on the volume
(implies /R)
Or
According to:
https://technet.microsoft.com/en-us/library/cc730714(v=ws.11).aspx
/B NTFS only: Clears the list of bad clusters on the volume and
rescans all allocated and free clusters for errors. /b includes
the functionality of /r. Use this parameter after imaging a
volume to a new hard disk drive.
This was a whole lotta writing, and a whole lotta screenshots, for something that will never be read.
Best Answer
I could be done but you probably wouldn't want to.
When an error occurs when a sector is written the drive replaces the bad sector with a spare and then rewrites the data and there is no data loss. The "Reallocated Sectors Count" is a count of these sectors. But things aren't so simple when an error occurs when a sector is read. Remapping the sector would not be a good idea because this would prevent recovery of it's data if a later read operation were to succeed. Instead the drive makes a note of the bad sector and waits for one of 2 events to occur. The "Current Pending Sector Count" is a count of such sectors.
If the sector is later successfully read it can be remapped with no data loss. Unfortunately you have no way of knowing when this will occur or even if it is possible. The read operation may succeed at the next attempt or it may fail after 1000 tries.
If the sector is later written to it can be remapped with no data loss. Unfortunately there is no way of knowing when or if this will occur. If the sector contains frequently modified data the wait may not be long. But if the sector contains a system or application executable file it may be long time before it is updated, or it may not happen at all.
Note that all of this occurs entirely within the drive with the OS having no involvement or knowledge of the operation. The drive provides no means of identifying which sectors are involved, just their number. It could probably be determined with drive specific software designed for the use of data recovery professionals. Such software is designed for professional use and priced accordingly.
With no way of knowing which sectors are involved there isn't much that software can do with them. Doing a clone backup of the drive and then restoring it would force the pending sectors to be written and allow then to be remapped. With an image backup you have no assurance that the sectors involved would be written. And the data in the bad sectors would be forever lost. And with a large drive this would take considerable time.
There really is nothing to be gained by forcing the reallocation. There is no advantage in successfully reading a remapped sector with the wrong data over failing to reading the original sector with the original data. And there is a chance it may eventually succeed if not remapped. If the sector is later written it will be remapped with no data loss.