Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Correcting errors in the volume Bitmap

Status
Not open for further replies.

jaymax2U

Technical User
Oct 1, 2008
47
US
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!
 
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.
 
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.

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.
 
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.
 
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.
 
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?
 
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.
 
By the way, I never run it in READ ONLY mode and always do a /F. Never had a problem yet. Knocks on wood.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top