Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Donate Today!

Do you enjoy these
technical forums?
Donate Today! Click Here

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

jaymax2U (TechnicalUser)
7 May 10 16:51
Hello,

XP SP3 - 160 Gb, SATA, NTFS, 2 drives in RAID 1 [assuming it is the system disk, other larger storage disk on system]
Went down during the night - automatic reboot and running chkdsk apparently
for the last 10 hrs at least, continuously scrolling

"Correcting errors in the volume Bitmap"

What is an appropriate strategy for dealing with this?

Thanks!
rclarke250 (TechnicalUser)
8 May 10 0:39
from microsoft. you can try chkdsk/F

This problem occurs because when Chkdsk is run against an NTFS volume,
Chkdsk.exe may report that security descriptors are in the database that are
no longer referenced by any file or folder, and that it is removing them.
However, Chkdsk.exe just reclaims the unused security descriptors as a
housekeeping activity, and is not actually fixing any kind of problem.

Microsoft has confirmed that this is a problem in Windows. Fortunately, this
error message is an informational message, and can be safely ignored.

All NTFS volumes contain a security descriptor database. This database is
populated with security identifiers that represent unique permission
settings applied to files and folders. When files or folders have unique
NTFS permissions applied, NTFS stores a unique security descriptor once on
the volume, and also stores a pointer to the security descriptor on any file
or folder that references it.

If files or folders no longer use that unique security descriptor, NTFS does
not remove the unique security descriptor from the database, but instead,
keeps it cached. Like any caching strategy, you want to keep the cached
information as long as possible because it may be used again.

To determine if more serious problems exist before scheduling or running
Chkdsk.exe with the /f switch, run the "chkntfs :" (without
the quotation marks) command, where is the drive letter of the drive you
want to run the "chkdsk /f" (without the quotation marks) command against.
If this command reports that the "dirty bit" is set, there may be real
damage that needs to be fixed.
goombawaho (MIS)
8 May 10 8:54
If this is happening often or if the CHDSK doesn't finish in about 15 minutes, I would be very worried.  One time is not an issue, but it really shouldn't take that long.

If Chkdsk runs once and finds these errors and then you can run chkdsk again and no problems found/corrected, I wouldn't worry.

If you run CHDSK back to back and get issues and repairs, I would get the manufacturer's hard drive diagnostic utility and run the LONG scan (if there is a short and long test).  Find out if you have a physical hard drive problem which is tripping the Chkdsk.

If you don't, you're disk COULD go bye bye in the near future.

Since this is RAID, I would disconnect all but one drive at a time for testing and use the bootable ultimate boot CD to run the diagnostics from.  That way, you don't boot into Windows after having disconnected one of the RAID drives and get all the warnings.

http://www.ultimatebootcd.com/download.html
NOT the yellow box you see - further down to download

Run the diags three separate times - once each for RAID drives and then for the storage drive.

Another question - why would the data drive be non-raid.  You'd better find out what's going on in terms of what disks are RAID and what function they play or you won't understand the whole picture.
smah (MIS)
8 May 10 9:13
Let it go.  Although it normally shouldn't, I've see chkdsk take 1 day or more and successfully complete.  The only way to stop a chkdsk /r that is running at reboot is to reboot again and that will almost certainly make things worse.
goombawaho (MIS)
8 May 10 9:36
I would NOT let it go - it's a waste of time.  The last time I saw a CHKDSK run for more than 20 minutes was when the hard drive was near failure.  Testing with the diagnostic utilty found enough errors for it to classify the drive as "FAILED".

You have two different opinions - you'll have to choose one course of action.

I suppose if you have RAID and one of those drives is the one causing the problem, it won't really hurt to let the CHKDSK run, though the drive may fail during the process.  Might be a big deal if it was the data disk and it wasn't RAIDed.
linney (TechnicalUser)
8 May 10 15:38
I assume that "goombawaho" and the 15 minute length to run ChkDsk must be referring to "read only" mode, or perhaps with just an "/f parameter"?  With "ChkDsk /r" it would take considerable longer to run, maybe at a rate of 45 minutes per 40 GB of hard drive checked, certainly not 15 minutes in my experience.


When ChkDsk goes wrong it can lead to disaster and reformatting which is why I prefer to run any initial ChkDsk in "read only" mode before checking with any set parameter (or box checked in the GUI).


There are some relevant XP links in this post, relevant more to my slight digression from the current subject, but relevant if you use ChkkDsk often.

Is ChkDsk still a worry when run in Vista?
http://social.answers.microsoft.com/Forums/en-US/vistaprograms/thread/73df6210-7818-45fc-b9e6-d266541b96ae/


  
goombawaho (MIS)
9 May 10 8:09
Yes, yes.  Chkdsk /F is what I was referring to.  The /R takes forever and doesn't really tell you what you need to know (in a reasonable amount of time) about the file system/disk health.

If the Chkdsk /f finds errors, I also look at the "bad blocks" count and then I always run a 2nd if it does much repairing.

Then after the second if there are more repairs OR if after the first, bad blocks are found, I run the manuf. HDD diag utility.

The bottom line is that CHKDSK is not the best tool for determining if the hard drive is healthy.  It's a good tool for fixing file system problems.  But, if the disk has basic problems (is failing), no amount of CHKDSK is going to help you fix or diagnose the problem.
goombawaho (MIS)
9 May 10 8:12
By the way, I never run it in READ ONLY mode and always do a /F.  Never had a problem yet.  Knocks on wood.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close