Chkdsk vs. Chkntfs?

I've been occasionally getting an error message on my Event Viewer,
Event ID 55, source Ntfs, message:

"The file system structure on the disk is corrupt and unusable. Please
run the chkdsk utility on the volume Hit 1000 winboot."

I'm absolutely certain that these are mostly fake messages, caused by
transient power losses. But still, I can't take a chance, If I were to
follow the advice given in the message and run chkdsk, since it's a boot
disk, it will require a reboot of the system and the chkdsk will run
just prior to system restart. I'd have no problems with that except
chkdsk is woefully slow, it takes over an hour to run it on my system.
I'd rather not run it, if all it's going to find is that there is
nothing wrong with the file system.

I found a technote from Microsoft, which is for a previous version of
Windows:

http://www.microsoft.com/technet/sup...ntfs&LCID=1033

It suggested running the "chkntfs" utility on the drive letter first and
it returns a simple "is dirty" or an "is not dirty" message. Runs in a
few seconds even while online. It usually sends back an "is not dirty"
message. Can this utility be trusted, compared to "chkdsk"? That is, are
there situations which Chkntfs is not aware of that Chkdsk is more
thorough about?

Yousuf Khan

Yousuf Khan <> wrote on Sat, 10 Dec 2011 21:55:37
-0500 in <4ee41baa$>

>I've been occasionally getting an error message on my Event Viewer,
>Event ID 55, source Ntfs, message:
>
> "The file system structure on the disk is corrupt and unusable. Please
>run the chkdsk utility on the volume Hit 1000 winboot."

Run chkdsk with no options so it runs in read only mode with no surface
scan. This is fast and only takes a few minutes for most disks and checks
the NTFS.
--
Carroll B. Robbins, Jr.

In message <>, Carroll Robbins
<> writes:
>Yousuf Khan <> wrote on Sat, 10 Dec 2011 21:55:37
>-0500 in <4ee41baa$>
>
>>I've been occasionally getting an error message on my Event Viewer,
>>Event ID 55, source Ntfs, message:
>>
>> "The file system structure on the disk is corrupt and unusable. Please
>>run the chkdsk utility on the volume Hit 1000 winboot."
>
>Run chkdsk with no options so it runs in read only mode with no surface
>scan. This is fast and only takes a few minutes for most disks and checks
>the NTFS.

Will doing that clear the flag that is causing Yousuf to get the warning
messages he is getting?

Yousuf, when you say you think these "are mostly fake messages, caused
by transient power losses" - what is causing these? If the mains supply
where you are often has these, a UPS (assuming this isn't a
laptop/netbook) is probably a good idea.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Live Faust, die Jung.

In message <4ee41baa$> someone claiming to be Yousuf
Khan <> typed:

>It suggested running the "chkntfs" utility on the drive letter first and
>it returns a simple "is dirty" or an "is not dirty" message. Runs in a
>few seconds even while online. It usually sends back an "is not dirty"
>message. Can this utility be trusted, compared to "chkdsk"? That is, are
>there situations which Chkntfs is not aware of that Chkdsk is more
>thorough about?

chkntfs doesn't actually check anything on the drive except whether the
drive is scheduled for an automatic chkdsk on startup.

If a drive is shut down with potential for data loss in the NTFS
filesystem itself, a chkdsk will be scheduled and run automatically on
the next startup.

That being said, it's very rare that you'll have NTFS corruption these
days unless you have failing hardware, NTFS is reasonably good at
detecting and correcting possible corruption in real time (or the next
time the volume is mounted, in the case of a sudden shutdown)

--
It's always darkest before dawn. So if you're going to
steal your neighbor's newspaper, that's the time to do it.

On 11/12/2011 5:07 AM, J. P. Gilliver (John) wrote:
> In message <>, Carroll Robbins
> <> writes:
>> Yousuf Khan <> wrote on Sat, 10 Dec 2011
>> 21:55:37
>> -0500 in <4ee41baa$>
>>
>>> I've been occasionally getting an error message on my Event Viewer,
>>> Event ID 55, source Ntfs, message:
>>>
>>> "The file system structure on the disk is corrupt and unusable. Please
>>> run the chkdsk utility on the volume Hit 1000 winboot."
>>
>> Run chkdsk with no options so it runs in read only mode with no surface
>> scan. This is fast and only takes a few minutes for most disks and checks
>> the NTFS.
>
> Will doing that clear the flag that is causing Yousuf to get the warning
> messages he is getting?

No, because it doesn't repair anything. Run with /f to repair, and that
can indeed take a long time I'd do it during lunchtime, or overnight.

HTH
Wolf K.

"J. P. Gilliver (John)" <> wrote on Sun, 11 Dec
2011 10:07:23 +0000 in <>

>Will doing that clear the flag that is causing Yousuf to get the warning
>messages he is getting?

The error messages are not caused by a flag. chkdsk will check the volume
to determine if it is corrupt. If it checks out good then the message is
bogus or transient. If the volume is corrupt then you will need to use the
/f option to fix it. This is also quick but the time depends on the
corruption and you will most likely lose some data. The /r option to do a
surface scan is the slow option that takes a long time and is only
necessary if the hardware is failing.
--
Carroll B. Robbins, Jr.

Yousuf Khan wrote:

> I've been occasionally getting an error message on my Event Viewer, Event ID 55, source Ntfs, message:

> "The file system structure on the disk is corrupt and unusable.
> Please run the chkdsk utility on the volume Hit 1000 winboot."

> I'm absolutely certain that these are mostly fake messages, caused by transient power losses.

They arent necessarily 'fake' if its caused by a transient power loss.

> But still, I can't take a chance, If I were to follow the advice given in the message and run chkdsk, since it's a
> boot disk, it will require a reboot of the system and the chkdsk will run just prior to system restart. I'd have no
> problems with that except chkdsk is woefully slow, it takes over an hour to run it on my system. I'd rather not run
> it, if all it's going to find is that there is nothing wrong with the file system.

Trouble is that since the problem is caused by a transient power loss,
the only way to be sure if it really has been corrupted is to run chkdsk.

> I found a technote from Microsoft, which is for a previous version of Windows:

> http://www.microsoft.com/technet/sup...ntfs&LCID=1033

> It suggested running the "chkntfs" utility on the drive letter first
> and it returns a simple "is dirty" or an "is not dirty" message. Runs
> in a few seconds even while online. It usually sends back an "is not
> dirty" message. Can this utility be trusted, compared to "chkdsk"?
> That is, are there situations which Chkntfs is not aware of that
> Chkdsk is more thorough about?

Its telling you what you already know, if the drive is flagged as dirty,
that you need to run chkdsk. It also allows you to reset that flag if
you want to postpone doing the chkdsk and dont just want to cancel
that manually at reboot time.

One obvious approach is to use a UPS so you dont get transient power losses.

In article <4ee41baa$>,
says...
>
> I've been occasionally getting an error message on my Event Viewer,
> Event ID 55, source Ntfs, message:
>
> "The file system structure on the disk is corrupt and unusable. Please
> run the chkdsk utility on the volume Hit 1000 winboot."
>
> I'm absolutely certain that these are mostly fake messages, caused by
> transient power losses. But still, I can't take a chance, If I were to
> follow the advice given in the message and run chkdsk, since it's a boot
> disk, it will require a reboot of the system and the chkdsk will run
> just prior to system restart. I'd have no problems with that except
> chkdsk is woefully slow, it takes over an hour to run it on my system.
> I'd rather not run it, if all it's going to find is that there is
> nothing wrong with the file system.
>
> I found a technote from Microsoft, which is for a previous version of
> Windows:
>
> http://www.microsoft.com/technet/sup...ntfs&LCID=1033
>
> It suggested running the "chkntfs" utility on the drive letter first and
> it returns a simple "is dirty" or an "is not dirty" message. Runs in a
> few seconds even while online. It usually sends back an "is not dirty"
> message. Can this utility be trusted, compared to "chkdsk"? That is, are
> there situations which Chkntfs is not aware of that Chkdsk is more
> thorough about?
>
> Yousuf Khan

This is like continuing to drive a car after the oil light comes on.
Yes, it *might* be a false alarm, but...

It's perfectly possible that your disk is on its last legs, and you're
days or even hours away from total, unrecoverable loss. Yes, that's the
worst case, but I see it regularly.

What I'd do is this:

Back up all data on the disk to separate physical storage

Image the disk (e.g. Acronis True Image, or Windows Complete backup)
again to separate physical storage. (This preserves Windows, and the
effort that might otherwise go into installing it, and all you
applications and settings.

If you have anything installed which can monitor the disk's SMART data
(e.g. HDTune) run that and see if any of the parameters, particularly
"Reallocated Sectors" is showing an alert.

I use a paid-for utility called Spinrite to audit and manage the state
of sectors on the disk (this also reports SMART status). It can take 48
hours to run for a large disk, especially if it's struggling to recover
data from failing sectors.

Then I'd run the fullest version of chkdsk, which only takes a couple of
hours, typically.

If you can't spare an hour or so to run chkdsk when the system seems to
be asking you to, then you have to accept you could lose everything.

Once you're confident your syste is ok, install HDTune or Acronis Disk
Monitor (configure it not to monitor backups, if you don't want these
alerts).

Disks don't last for ever!

--

Phil, London

On 11/12/2011 5:07 AM, J. P. Gilliver (John) wrote:
> Will doing that clear the flag that is causing Yousuf to get the warning
> messages he is getting?
>
> Yousuf, when you say you think these "are mostly fake messages, caused
> by transient power losses" - what is causing these? If the mains supply
> where you are often has these, a UPS (assuming this isn't a
> laptop/netbook) is probably a good idea.

UPS might help, but I've had somewhat bad experiences with UPSes in the
past, so I'm not really ready to go down that road again. My system is a
somewhat unusually power-hungry system, there's a 650W PS inside it, but
it may just be barely enough to power all of the stuff inside it.
Besides the mainboard and processor, there is six internal hard drives,
a video card, and a couple of optical drives. Plus there are various USB
hard drives and other peripherals that get attached and detached from it
from time to time. It's more of a server really than a standard desktop.

Yousuf Khan

On 11/12/2011 6:20 AM, DevilsPGD wrote:
> chkntfs doesn't actually check anything on the drive except whether the
> drive is scheduled for an automatic chkdsk on startup.
>
> If a drive is shut down with potential for data loss in the NTFS
> filesystem itself, a chkdsk will be scheduled and run automatically on
> the next startup.
>
> That being said, it's very rare that you'll have NTFS corruption these
> days unless you have failing hardware, NTFS is reasonably good at
> detecting and correcting possible corruption in real time (or the next
> time the volume is mounted, in the case of a sudden shutdown)

I have a task attached to the NTFS error event in the event viewer. The
task immediately notifies me when this error occurs with a pop-up
message. The message pops up in the middle of normal operations most of
the time, not during power failures or improper shutdowns most of the
time. That's not to say that message occurs often, it's only happened 4
times in the last two months, so far, and three of those occurred three
times in a row on one particular day in November, for what reason I
don't know; so I'd consider that only one incident really. Even during
the November incident when running chkdsk during the next reboot, it
found nothing wrong.

Yousuf Khan