Ckdsk - inconsistent results for system partition

[Guest]

If I run chkdsk in read-only mode under windows following message
is being generated
The type of the file system is NTFS.
Volume label is System.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Security descriptor verification completed.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows found problems with the file system.
Run CHKDSK with the /F (fix) option to correct these.

41945680 KB total disk space.
4640312 KB in 26335 files.
8580 KB in 3399 indexes.
0 KB in bad sectors.
98156 KB in use by the system.
65536 KB occupied by the log file.
37198632 KB available on disk.

4096 bytes in each allocation unit.
10486420 total allocation units on disk.
9299658 allocation units available on disk.


Inspired by the error hint I have scheduled then autochkdsk.
In event log can find following message

Checking file system on C:
The type of the file system is NTFS.
Volume label is System.


A disk check has been scheduled.
Windows will now check the disk.
Windows has checked the file system and found no problems.

41945680 KB total disk space.
4637948 KB in 26335 files.
8580 KB in 3399 indexes.
0 KB in bad sectors.
98156 KB in use by the system.
65536 KB occupied by the log file.
37200996 KB available on disk.

4096 bytes in each allocation unit.
10486420 total allocation units on disk.
9300249 allocation units available on disk.


First report doesn't correspond to second one.
What is it actually ?
Which is correct, which not ?
How have I to interpret this situation ?

--
win xp pro sp 2 engl
Excel, Word Viewers 2003
PP Viewer 2007
MS security patches applying manually only
MBSA 2.0.1
Fx 2.0 as permitted browser only

 

[Guest]

Chkdsk is poo. You wouldn't believe the number of times I've ran chkdsk, its
reported errors, os I ran chkdsk /f /r and restarted the computer, only to
run chkdsk straightaway and get the same errors again.

 

[Wesley Vogel]

First report doesn't correspond to second one.

What is it actually ?
Which is correct, which not ?

Don't even bother running CHKDSK in read-only mode. It is a waste of time
and prone to not accurately reporting information. CHKDSK might report
spurious errors because it cannot lock the drive.

1. In My Computer or Windows Explorer, right-click the volume you want to
check, and then click Properties.
2. On the Tools tab, click Check Now.
3. Check both boxes:

o To run Chkdsk by using the /f parameter, select the Automatically fix file
system errors check box, and then click Start.
[[Specifies whether Windows repairs file-system errors found during disk
checking. All files must be closed for this program to run. If the drive is
currently in use, a message asks if you want to reschedule
the disk checking for the next time you restart your computer. Your drive is
not available to run other tasks while the disk is being checked.]]

o To run Chkdsk by using the /r parameter, select the Scan for and attempt
recovery of bad sectors check box, and then click Start.
[[Specifies whether Windows repairs file-system errors found during disk
checking, locates bad sectors, and recovers readable information. All files
must be closed for this program to run. If the drive is currently in use, a
message asks if you want to reschedule the disk checking for the next time
you restart your computer. Your drive is not available to run other tasks
while the disk is being checked. If you select this option, you do not need
to select Automatically fix file system errors. Windows fixes any errors on
the disk.]]

You have to reboot for Error-checking to run.

For a look at the chkdsk log.

Open the Event Viewer...
Start | Run | Type: eventvwr | Click OK |
Look in Application | Listed as Information |
Event ID: 1001
Source: Winlogon
[[Description: This includes file system type; drive letter or GUID, and
volume name or serial number to help determine what volume Chkdsk ran
against. Also included is whether Chkdsk ran because a user scheduled it or
because the dirty bit was set.]]

[[When Autochk runs against a volume at boot time it records its output to a
file called Bootex.log in the root of the volume being checked. The Winlogon
service then moves the contents of each Bootex.log file to the Application
Event log.]]

[[This file states whether Chkdsk encountered any errors and, if so,
whether they were fixed.]]
-----

[[Chkdsk might not accurately report information in read-only mode.]]
From...
Chkdsk
http://www.microsoft.com/resources/...windows/xp/all/reskit/en-us/prmb_tol_pwfd.asp

[[If you run chkdsk without the /f command-line option on an active
partition, it might report spurious errors because it cannot lock the
drive.]]

[[Using chkdsk with open files
If you specify the /f command-line option, chkdsk sends an error message if
there are open files on the disk. If you do not specify the /f command-line
option and open files exist, chkdsk might report lost allocation units on
the disk. This could happen if open files have not yet been recorded in the
file allocation table. If chkdsk reports the loss of a large number of
allocation units, consider repairing the disk.]]
From...
Chkdsk
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/chkdsk.mspx

[[In read-only mode, CHKDSK quits before it completes all three phases if it
encounters errors in earlier phases, and CHKDSK is prone to falsely
reporting errors. For example, CHKDSK may report disk corruption if NTFS
happens to modify areas of a disk while CHKDSK is examining the disk. For
correct verification, a volume must be static, and the only way to guarantee
a static state is to lock the volume. CHKDSK locks the volume only if you
specify the /F switch (or the /R switch, which implies /F). You may need to
run CHKDSK more than once to get CHKDSK to complete all its passes
in read-only mode. ]]
From...
An Explanation of the New C and I Switches That Are Available to Use with
Chkdsk.exe
http://support.microsoft.com/kb/314835

To take advantage of all the Chkdsk parameters, use the command-line version
of Chkdsk.

See..
Understanding what CHKDSK does
here...
An explanation of the new /C and /I Switches that are available to use with
Chkdsk.exe
http://support.microsoft.com/kb/314835

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

 

[cquirke (MVP Windows shell/user)]

On Mon, 12 Feb 2007 11:17:01 -0700, "Wesley Vogel"

Don't even bother running CHKDSK in read-only mode. It is a waste of time
and prone to not accurately reporting information. CHKDSK might report
spurious errors because it cannot lock the drive.

1. In My Computer or Windows Explorer, right-click the volume you want to
check, and then click Properties.
2. On the Tools tab, click Check Now.
3. Check both boxes:

o To run Chkdsk by using the /f parameter, select the Automatically fix file
system errors check box, and then click Start.

o To run Chkdsk by using the /r parameter, select the Scan for and attempt
recovery of bad sectors check box, and then click Start.

Earlier, someone said "ChkDsk is poo", and they are 100% correct.

Unfortunately, if you use NTFS, it's all you have.

You have to choose between:
- running safely (read-only) but getting fake "errors"
- running accurately but risking irreversible damage

The assumption behind ChkDsk is that you'd rather have a sane file
system than recovered data. When ChkDsk /F "fixes" file system
errors, it does so by taking a guess at how to resolve detected file
system anomalies - and it keeps no ability to "undo" its guesses.

If you'd rather have an accurate preview of what ChkDsk would be
allowed to do it it were to "fix", then use it without the /F or /R
parameters, but without booting the OS on the volume you are trying to
check. Google( Bart PE ) for a suitable non-HD-boot platform from
which this can be done.

To exclude physical errors, run HD Tune from www.hdtune.com rather
than risking data loss with ChkDsk /R. Again, if the volume is on a
HD suspected of failing, do not boot Windows from it; work from Bart
CDR boot, and run HD Tune from there.


If you use FATxx instead of NTFS, *and* the volume you wish to check
does not overrun the 137G mark on the physical HD, then you can use
Scandisk as run from a Win95 SR2 or later DOS mode boot.

Unlike ChkDsk, ScanDisk will stop when it finds errors, tell you what
it plans to do, and asks if it can continue.


If you use FATxx instead of NTFS, but the volume crosses the first
physical 137G on the HD, then DOS mode and Win9x are not safe OSs, and
Scandisk can't help you. You can use ChkDsk and ChkDsk /F, as
described for NTFS.

Final note: At least for FATxx volumes, there's a difference between:
- rt-clicking a volume, Properties, Tools, check for errors
- running ChkDsk explicitly

The first runs very quickly, does nothing, and will miss errors that
DOS mode Scandisk would have detected and (if allowed) fixed. When
you explicitly run ChkDsk, it takes longer and is more likely to
actually find problems that are there.

I tested this by deliberately creating errors within the FAT using
low-level disk tools from DOS mode, then running "Check for errors" in
XP, then doing another DOS mode boot and running Scandisk. XP's
easy-UI "check" found no errors at all; Scandisk found all the errors
I'd created, and would often fix them in an appropriate manner.

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Wesley Vogel]

Hi Chris,

"For correct verification, a volume must be static, and the only way to
guarantee a static state is to lock the volume." And the only way to do
that is to run chkdsk /f or chkdsk /r not chkdsk with no switches (read-only
mode).

As near as I can tell, the only reason to run chkdsk in read-only mode is to
see how long it would take to actually run chkdsk /r or /f. That seems
goofy to me, but maybe if it's some mission-critical server situation where
down time is critical then it may have some value. We have to remember that
MS creates things for big companies, not us piddly consumers.

Chkdsk lists and corrects file system errors on disks it does not fix messed
up user data.

David Candy puts it rather eloquently.

"You don't run chkdsk without a reason. Chkdsk job is to repair the disk not
save your data. If it has to throw all your data away to repair the disk it
will. A repair is to meet certain integrity tests."

"Image a car crash that you are trapped in. Chkdsk will repair the car even
if it kills you while doing so. It will try not to kill you but if the only
way to repair the car is to kill you it will. Chkdsk is not a rescue vehicle
or an ambulance but a smash repairer. If you want to live you need to call
the ambulance first before calling chkdsk."
David Candy
http://groups.google.com/group/micr...12530?lnk=st&q=&rnum=5&hl=en#b28aa18642912530

<quote>
Metadata is "data about data." Metadata is the file system "overhead," so to
speak, that keeps track of information about all of the files that are
stored on the volume. Metadata includes information about what allocation
units make up the data for a given file, what allocation units are free,
what allocation units contain bad sectors, and so on. The data that the file
contains, on the other hand, is termed "*user data*." NTFS protects its
metadata through the use of a transaction log. *User data* is not protected
in this way.
<quote>
An Explanation of the New C and I Switches That Are Available to Use with
Chkdsk.exe
http://support.microsoft.com/kb/314835

<quote>
NTFS does not guarantee the integrity of *user data* following an instance
of disk corruption, even when a full Chkdsk is run immediately after
corruption is detected. Chkdsk might not recover all files, and files that
are recovered might be internally corrupted. Therefore, you must protect
important data by performing periodic backups.
<quote>
Reducing the Time Required to Run Chkdsk on NTFS Volumes
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkd_tro_vaea.asp

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

 

[cquirke (MVP Windows shell/user)]

On Tue, 13 Feb 2007 14:20:34 -0700, "Wesley Vogel"

Hi Chris,
Hi!

"For correct verification, a volume must be static, and the only way to
guarantee a static state is to lock the volume."

Fair enough.

And the only way to do that is to run chkdsk /f or chkdsk /r

That's the bad design - what if you don't trust ChkDsk to "fix"? You
should be able to set up a ChkDsk in read-only mode to run on boot,
before the OS starts banging away at the HD.

In practice, it isn't ChkDsk that checks the HD on boot, but a
different tool called AutoChk. It may be that AutoChk has no
read-only mode, and it may be that ChkDsk can't be set to run early
enough in the OS boot process to be effective.

As near as I can tell, the only reason to run chkdsk in read-only mode is to
see how long it would take to actually run chkdsk /r or /f.

ChkDsk is not a data preservation or recovery tool; it maintains the
file system sanity on a "kill, bury, deny" basis. Broken files are
deleted and buried (no undoability) and if you want the details as to
what happened, good luck in trolling through the logs.

NTFS prides itself on robustness, and at first glance the rollback
feature sounds great; an intrerrupted operation always has the
previous state to fall back to. Then you read a bit deeper and start
seeing the * disclaimers; "user data" (i.e. the data that's actually
IN the file) is NOT preserved, only the metadata that describes it.

All of this pivots on the ASSumption that the only problem will be
normal file operations that are interrupted, e.g. by bad exits. You'd
have half a file on an otherwise sane file system, and you'd "fix"
this by deleting the lost chain and (if presernt) the dir entry that
defines it. Exactly as one can do in FATxx.

But there aree other causes for file system damage, where what to do
isn't nearly so obvious - bad RAM could cause corruption within the
file system structure itself, or write good data back to the wrong
place. In such cases, I'd want to tackle this manually, starting with
an assessment of what is damaged BEFORE any sort of "fix".

but maybe if it's some mission-critical server situation where
down time is critical then it may have some value.

That's an issue, yes, especially with the duhfault "one big C:, always
in use" design. That practically guarantees C: will always be bent
after a bad exit, and the whole thing will have to be "fixed".

MS creates things for big companies, not us piddly consumers.

Big companies have professionally-aadministered backups and good
server hardware, usually with some redundancy. So the ASSumption is
that no need for data recovery exists.

Chkdsk lists and corrects file system errors on disks it does not fix messed
up user data.

The process of "fixing" file system errors can make recovery of user
disaster impossible.

David Candy puts it rather eloquently.

"You don't run chkdsk without a reason. Chkdsk job is to repair the disk not
save your data. If it has to throw all your data away to repair the disk it
will. A repair is to meet certain integrity tests."

And you still ask why we'd want a "look, don't touch" mode?

<quote>
NTFS does not guarantee the integrity of *user data* following an instance
of disk corruption
</quote>

My point exactly.

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Wesley Vogel]

Howdy,

In practice, it isn't ChkDsk that checks the HD on boot, but a
different tool called AutoChk. It may be that AutoChk has no
read-only mode, and it may be that ChkDsk can't be set to run early
enough in the OS boot process to be effective.

Yes, Chris, you're correct, autochk.exe is what actually runs at boot,
chkdsk.exe does not run at boot. I was using chkdsk in the generic sense,
like MS did here.

"Because both Autochk.exe and the verification code in the Chkdsk.exe
utility DLLs are based on the same source code, the rest of this article
uses the term "CHKDSK" to refer generically to either Autochk.exe or
Chkdsk.exe."
An Explanation of the New C and I Switches That Are Available to Use with
Chkdsk.exe
http://support.microsoft.com/kb/314835

With BootExecute set to the default setting of "autocheck autochk*", autochk
will run on every boot to see if the dirty bit is set. If the dirty bit is
set, autochk checks the volume for errors and tries to repair them. If the
dirty bit is not set, nothing much else happens.

If chkdsk is used with the /r or /f switches it schedules autochk to run at
boot to check for and repair errors. Without the switches, in either GUI or
command-line mode, chkdsk does not popup with the "Do you want to schedule
this disk check to occur the next time you restart the computer?" or the
"Would you like to schedule this volume to be checked the next time the
system restarts?" messages so autochk does not get scheduled to do anything
other than look for the dirty bit being set.

The dirty bit can be set with the fsutil dirty set command or if there is
something wrong with the drive. Actual disk corruption or a crash, "changes
were made to the volume and the computer shutdown before the changes were
committed to disk".

Either of these commands adds the registry value and schedules autochk on a
restart.

chkdsk c: /f /r
or
Right click Drive | Properties | Tools tab | Check Now button |
Select both boxes in Check Disk Local Disk (C | Click Yes to
Do you want to schedule this disk check to occur the next time you restart
the computer?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Value Name: BootExecute
Data Type: REG_MULTI_SZ
Value Data: autocheck autochk /r \??\C:

"The BootExecute data item contains one or more commands that Session
Manager runs before it loads any services. The default value for this item
is Autochk.exe, which is the Windows NT version of Chkdsk.exe."
Windows NT Workstation Resource Kit: What Happens When You Start Your
Computer
http://www.microsoft.com/technet/archive/ntwrkstn/reskit/booting.mspx?mfr=true

Description of Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000
http://support.microsoft.com/kb/218461

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

 

[cquirke (MVP Windows shell/user)]

On Thu, 15 Feb 2007 12:36:43 -0700, "Wesley Vogel"

Yes, Chris, you're correct, autochk.exe is what actually runs at boot,
chkdsk.exe does not run at boot. I was using chkdsk in the generic sense,
like MS did here.

OK. I've never been too clear on the differences; there must be come,
for the two to exist (unless one is just a wrapper for the other).

"Because both Autochk.exe and the verification code in the Chkdsk.exe
utility DLLs are based on the same source code, the rest of this article
uses the term "CHKDSK" to refer generically to either Autochk.exe or
Chkdsk.exe."
An Explanation of the New C and I Switches That Are Available to Use with
Chkdsk.exe
http://support.microsoft.com/kb/314835

Great article, sobering reading...

<editpaste1>

CHKDSK has identified the space that is in use and the space that is
available, both within the MFT and on the volume as a whole. NTFS
keeps track of this information in bitmaps of its own, which are
stored on the disk. CHKDSK compares its results with the bitmaps that
NTFS keeps. ... if a file record segment that was in use is found to
be corrupted, the disk clusters that were associated with that file
record segment are marked as "available" in the CHKDSK bitmap but are
marked as "in use" in the NTFS bitmap.

</editpaste1>

IOW, the damaged file is thrown away and can't be gotten back.

<paste2>

If CHKDSK finds directory listings for file record segments that are
no longer in use, or for file record segments that are in use but that
do not correspond to the file that is listed in the directory, CHKDSK
simply removes the directory entry for the file record segment.

</paste2>

Once again, your data is thrown away and can't be recovered.

<paste3>

When CHKDSK finds an unreadable sector, NTFS adds the cluster that
contains that sector to its list of bad clusters. If the bad cluster
is in use, CHKDSK allocates a new cluster to do the job of the bad
cluster. If you are using a fault-tolerant disk, NTFS recovers the bad
cluster's data and writes the data to the newly allocated cluster.
Otherwise, the new cluster is filled with a pattern of 0xFF bytes.

</paste3>

So whatever that was in the lost cluster gets FF'd out. Not great...
and as NTFS's code itself will do this on the fly, simply accessing
the file system is enough to cause this damage, and ChkDsk in
read-only mode will have a similar effect.

With BootExecute set to the default setting of "autocheck autochk*", autochk
will run on every boot to see if the dirty bit is set. If the dirty bit is
set, autochk checks the volume for errors and tries to repair them. If the
dirty bit is not set, nothing much else happens.

"Nothing much else" isn't quite "nothing", is it?

If chkdsk is used with the /r or /f switches it schedules autochk to run at
boot to check for and repair errors. Without the switches, in either GUI or
command-line mode, chkdsk does not popup with the "Do you want to schedule
this disk check to occur the next time you restart the computer?" or the
"Would you like to schedule this volume to be checked the next time the
system restarts?" messages so autochk does not get scheduled to do anything
other than look for the dirty bit being set.

This is a design problem; you can't get an accurate read-only ChkDsk
result. I avoid this mess by doing my ChkDsk from Bart CDR boot.

The dirty bit can be set with the fsutil dirty set command or if there is
something wrong with the drive.

That forces the auto-fixing nightmare one is trying to avoid :-/

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Value Name: BootExecute
Data Type: REG_MULTI_SZ
Value Data: autocheck autochk /r \??\C:

How to stop AutoChk playing with volumes even if they are "dirty":

autocheck autochk /k:C /k /k:E /k:F /k:G /k:H /k:I /k:J /k:K /k:L
/k:M /k:N /k:O /k /k:Q /k:R /k:S /k:T /k:U /k:V /k:W /k:X /k:Y /k:Z
*

Just delete the /k:? for the volumes you do want checked. On NTFS I
let it check C:, but on my own system I'd rather do that manually via
DOS mode Scandisk when needed. I would suppress checking of all
letters not part of the system, so that if you ever need in to salvage
files fronm a dropped-in drive, at least some risk is contained.

"The BootExecute data item contains one or more commands that Session
Manager runs before it loads any services. The default value for this item
is Autochk.exe, which is the Windows NT version of Chkdsk.exe."

I wonder what the AutoCheck before the AutoChk means?

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!