What does the "chkdsk /b" argument do?
1 - 10 of 10 Posts
![Techie007](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="96" height="96"><rect fill-opacity="0"/></svg>){kind=avatar}
Joined
·
2,225 Posts
Quote:
The /b performs the same scan, and then attempts to re-read the areas occupied by the $BadClus file, to evaluate whether they should be released back to general use or not. On a failing HDD, the last part of this test could be quite tortuous and take a lot of time, as each failed read will probably take a second to timeout-and there could be hundreds or thousands of them from a previous scan. But for a normal HDD, there would be no bad sectors, so the two tests would be the same.
I agree with Oj010 that this is quite unnecessary as pretty much all drives nowadays silently remap any failed sectors to the spare sector pool before Windows even realizes what's happening. By the time a drive's spare sector pool is exhausted (no more spare sectors available for remapping new bad sectors), the drive is probably done anyway due to run-away media failure. Windows introduced this feature back in the day when HDDs didn't have a spare sector pool, and having a couple bad sectors was normal.
Probably the more important use of scanning for bad sectors would be to identify impending drive failure and retrieve data before it becomes completely unreadable. See, a drive can be working perfectly fine, while certain areas storing rarely accessed files are degrading, and no one would ever know about the problem because those areas are never read. I have personally had this happen with about a half-dozen HDDs over the years.
Even then, chkdsk is a bad tool for this job because of its very aggressive approach (it can burn up an otherwise functioning drive just because of a small bad area), its complete lack of reporting, and the fact that it will ignore the time aspect of reads. Bad areas usually start reading slowly before they fail completely. These extremely slow areas pass chkdsk until the point of complete failure, at which point chkdsk goes into torture mode trying to recover the lost data, which often overheats the drive, causing its premature (and complete) demise. Often times, all the drive needs is the slow area to be copied to memory, zeroed+oned a couple of times, and then written back to the same spot. Unfortunately, I am not aware of a better tool for this sort of scanning at this time. Maybe I'll write one someday.
![smile.gif](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="70" height="22"><rect fill-opacity="0"/></svg>)
The /r flag scans the entire non-marked portion of a partition for unreadable areas to add to the super-hidden $BadClus file so that they can't be used to store file data.Originally Posted by cdoublejj
What does the "chkdsk /b" argument do?
The /b performs the same scan, and then attempts to re-read the areas occupied by the $BadClus file, to evaluate whether they should be released back to general use or not. On a failing HDD, the last part of this test could be quite tortuous and take a lot of time, as each failed read will probably take a second to timeout-and there could be hundreds or thousands of them from a previous scan. But for a normal HDD, there would be no bad sectors, so the two tests would be the same.
I agree with Oj010 that this is quite unnecessary as pretty much all drives nowadays silently remap any failed sectors to the spare sector pool before Windows even realizes what's happening. By the time a drive's spare sector pool is exhausted (no more spare sectors available for remapping new bad sectors), the drive is probably done anyway due to run-away media failure. Windows introduced this feature back in the day when HDDs didn't have a spare sector pool, and having a couple bad sectors was normal.
Probably the more important use of scanning for bad sectors would be to identify impending drive failure and retrieve data before it becomes completely unreadable. See, a drive can be working perfectly fine, while certain areas storing rarely accessed files are degrading, and no one would ever know about the problem because those areas are never read. I have personally had this happen with about a half-dozen HDDs over the years.
Even then, chkdsk is a bad tool for this job because of its very aggressive approach (it can burn up an otherwise functioning drive just because of a small bad area), its complete lack of reporting, and the fact that it will ignore the time aspect of reads. Bad areas usually start reading slowly before they fail completely. These extremely slow areas pass chkdsk until the point of complete failure, at which point chkdsk goes into torture mode trying to recover the lost data, which often overheats the drive, causing its premature (and complete) demise. Often times, all the drive needs is the slow area to be copied to memory, zeroed+oned a couple of times, and then written back to the same spot. Unfortunately, I am not aware of a better tool for this sort of scanning at this time. Maybe I'll write one someday.
Joined
·
10,400 Posts
I ended up using that command after cloning a failing HDD to a brand new SSD. I knew it did /r but, also something else but, wasn't sure. I doubt /b really does any thing on a new SSD because I doubt clusters clone, just the data.
FYI for those coming across this via google, DO NOT perfom a check disk on a dying drive!!! clone it first then run the chkdsk on the new drive.
FYI for those coming across this via google, DO NOT perfom a check disk on a dying drive!!! clone it first then run the chkdsk on the new drive.
Joined
·
2,225 Posts
Quote:
The "badness" of the sectors themselves obviously doesn't clone from an old drive to a new one-the new hardware will not get damaged by copying from the old. However, if Windows marked areas of a partition as "bad", that marking could get cloned to the new drive if the cloning program does an exact clone. Basically, all chkdsk does is extend and fragment a super-hidden file (on the root of the affected partition) named $BadClus to occupy the space of the bad sectors it finds. This prevents new data from being written in those places as the space is already used by the $BadClus file. However, this marking by Windows does not happen unless the user manually runs chkdsk to do a surface scan (/r or /b flags). During normal operation, the device itself does sector remapping instead, and this is stored by the device firmware and will not get copied by any clone operation.
Either way, running chkdsk on a clone is the perfect way to fix any lingering issues. chkdsk /f will fix any lingering database inconsistencies, and chkdsk /b will reevaluate the entire partition, removing any areas previously masked off as "bad" as they now can be successfully read on the clone.
Definitely agree with the last paragraph! Now that I understand what you were trying to figure out, I can give a little more input:Originally Posted by cdoublejj
I ended up using that command after cloning a failing HDD to a brand new SSD. I knew it did /r but, also something else but, wasn't sure. I doubt /b really does any thing on a new SSD because I doubt clusters clone, just the data.
FYI for those coming across this via google, DO NOT perfom a check disk on a dying drive!!! clone it first then run the chkdsk on the new drive.
The "badness" of the sectors themselves obviously doesn't clone from an old drive to a new one-the new hardware will not get damaged by copying from the old. However, if Windows marked areas of a partition as "bad", that marking could get cloned to the new drive if the cloning program does an exact clone. Basically, all chkdsk does is extend and fragment a super-hidden file (on the root of the affected partition) named $BadClus to occupy the space of the bad sectors it finds. This prevents new data from being written in those places as the space is already used by the $BadClus file. However, this marking by Windows does not happen unless the user manually runs chkdsk to do a surface scan (/r or /b flags). During normal operation, the device itself does sector remapping instead, and this is stored by the device firmware and will not get copied by any clone operation.
Either way, running chkdsk on a clone is the perfect way to fix any lingering issues. chkdsk /f will fix any lingering database inconsistencies, and chkdsk /b will reevaluate the entire partition, removing any areas previously masked off as "bad" as they now can be successfully read on the clone.
Quote:
Question. Assuming someone has maliciously marked a good block as bad, say in order to hide a virus there, would chkdsk /b check, find the block is OK, and bring it back into service, unhiding the virus?Originally Posted by Techie007
The /r flag scans the entire non-marked portion of a partition for unreadable areas to add to the super-hidden $BadClus file so that they can't be used to store file data.
The /b performs the same scan, and then attempts to re-read the areas occupied by the $BadClus file, to evaluate whether they should be released back to general use or not. On a failing HDD, the last part of this test could be quite tortuous and take a lot of time, as each failed read will probably take a second to timeout-and there could be hundreds or thousands of them from a previous scan. But for a normal HDD, there would be no bad sectors, so the two tests would be the same.
I agree with Oj010 that this is quite unnecessary as pretty much all drives nowadays silently remap any failed sectors to the spare sector pool before Windows even realizes what's happening. By the time a drive's spare sector pool is exhausted (no more spare sectors available for remapping new bad sectors), the drive is probably done anyway due to run-away media failure. Windows introduced this feature back in the day when HDDs didn't have a spare sector pool, and having a couple bad sectors was normal.
Probably the more important use of scanning for bad sectors would be to identify impending drive failure and retrieve data before it becomes completely unreadable. See, a drive can be working perfectly fine, while certain areas storing rarely accessed files are degrading, and no one would ever know about the problem because those areas are never read. I have personally had this happen with about a half-dozen HDDs over the years.
Even then, chkdsk is a bad tool for this job because of its very aggressive approach (it can burn up an otherwise functioning drive just because of a small bad area), its complete lack of reporting, and the fact that it will ignore the time aspect of reads. Bad areas usually start reading slowly before they fail completely. These extremely slow areas pass chkdsk until the point of complete failure, at which point chkdsk goes into torture mode trying to recover the lost data, which often overheats the drive, causing its premature (and complete) demise. Often times, all the drive needs is the slow area to be copied to memory, zeroed+oned a couple of times, and then written back to the same spot. Unfortunately, I am not aware of a better tool for this sort of scanning at this time. Maybe I'll write one someday.![smile.gif](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="65" height="19"><rect fill-opacity="0"/></svg>)
Joined
·
2,225 Posts
Yes, running chkdsk /b would unmark any maliciously marked bad sectors. However, if there's maliciously hidden sectors, you've got a bigger problem--a malicious program running amok with SYSTEM privileges!
Yes, malicious data can be stored the space marked as bad sectors. No, unmaking that space will not cause the malicious data to become "unhidden", all it would do is unprotect that data releasing it to the free space pool.
All that marking a bad sector does is make space unavailable for new data by saying it is used by the super hidden $BadClaus file. You could technically accomplish the same thing with a regular file by saving a file with a lot of zeroes in it and using the defragmentation APIs to move it to a particular spot. Now that spot can't be used for anything else--exactly what happens when a cluster is marked as bad. Now pretend that that file is invisible, and store malicious data inside. Then delete the file. This is exactly what would happen if a virus did what you wondered about. After deletion (or an unmaking of maliciously marked bad sectors), the data still exists in the free space, but it's now inaccessible, vulnerable to being overwritten (had no filename) by the next file that comes along.
Yes, malicious data can be stored the space marked as bad sectors. No, unmaking that space will not cause the malicious data to become "unhidden", all it would do is unprotect that data releasing it to the free space pool.
All that marking a bad sector does is make space unavailable for new data by saying it is used by the super hidden $BadClaus file. You could technically accomplish the same thing with a regular file by saving a file with a lot of zeroes in it and using the defragmentation APIs to move it to a particular spot. Now that spot can't be used for anything else--exactly what happens when a cluster is marked as bad. Now pretend that that file is invisible, and store malicious data inside. Then delete the file. This is exactly what would happen if a virus did what you wondered about. After deletion (or an unmaking of maliciously marked bad sectors), the data still exists in the free space, but it's now inaccessible, vulnerable to being overwritten (had no filename) by the next file that comes along.
1 - 10 of 10 Posts
Join the discussion
Recommended Reading
-
Hard Drives & Storage
- 14
- 943
-
Operating Systems
- 9
- 2K
-
KSIMP88 · updated
-
Hard Drives & Storage
- 6
- 548
-
Hard Drives & Storage
- 9
- 679
-
Cyber Akuma · updated
-
Hard Drives & Storage
- 5
- 725
