CHKDSK: no Winlogon result

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

--
Terry, East Grinstead, UK

Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

I think I've found the answer to my own question. For my C: drive I had to
run the chkdsk on reboot. For the E: drive I just had to 'unmount' it. It
seems that you do not then get a Winlogon event. I only became aware it
had finished when I realised that disk activity had stopped and as I had
no message window, there was presumably nothing to report for that day and
a half's operation?

--
Terry, East Grinstead, UK

Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

Why aren't you running a console-mode command inside a console (that
stays open)? Stop running "chkdsk" using the Win+R run dialog. When
the program exits, it's no longer there to provide a console (aka
command shell). Run "cmd" (command line interpreter) that opens a
console. THEN run console-mode commands within it. When the
console-mode program ends, the console will still be there because it
was loaded by cmd.exe which is still running.

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch over
the [/f] is a [massive] waste of time...

==

Cheers, Tim Meddick, Peckham, London. :-)




"Terry Pinnell" wrote in message
...
Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

I think I've found the answer to my own question. For my C: drive I had
to
run the chkdsk on reboot. For the E: drive I just had to 'unmount' it. It
seems that you do not then get a Winlogon event. I only became aware it
had finished when I realised that disk activity had stopped and as I had
no message window, there was presumably nothing to report for that day
and
a half's operation?

--
Terry, East Grinstead, UK

Tim Meddick wrote:

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch over
the [/f] is a [massive] waste of time...

The /f switch only looks for inconsistencies in the file system, not
whether or not data can be read reliably from the drive. What good is a
valid file system if the bytes aren't reliably read from the media? By
the time you see any error message that you mention (I've yet to see one
in over 25 years of using PCs that explicitly states the media is the
fault) then it's too late and you've probably also lost some files.

How often do YOU run chkdsk (whatever set of parameters)? I maybe run
it once per year, if that, or when some abnomally appears in the
operation of the hard disk. No one runs it every day, every week, or
even every month. How often do you check the pressures of your car's
tires or its oil level?

Since most folks don't work 24 hours every day, their workstation will
be free at some time when the user isn't there. Since most folks sleep,
they computer will be idle at some time. There is no massive waste of
time to run chkdsk with its /r switch when you aren't even at that
computer.

It's my opinion that computers, like cars, can be "driven" a certain way by
it's owner so as to make it more vulnerable to certain types of fault - in
my own personal experience (with WinXP) I have found over the last 10 years
working with it, that disk data errors, of a type that can be corrected by
[chkdsk /f] have occurred on my system, whereas, the same vulnerability is
not present on other [XP] systems I have worked on or observed.

Simple fact is - if I don't run disk checks for greater than 20 re-starts,
I can end up with crashes and / or the blue screen of death! Often, these
errors that have arisen, have been corrected with starting the WinXP
Recovery Console and running [chkdsk /f]...

Something I don't quite understand is when [chkdsk /p] (run from the WinXP
RC) refuses to check a system disk (with message: "disk has one or more
unrecoverable problems") but then will repair them if [chkdsk /f] is run on
it from another boot volume?...

==

Cheers, Tim Meddick, Peckham, London. :-)




"VanguardLH" wrote in message
...
Tim Meddick wrote:

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover
data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch
over
the [/f] is a [massive] waste of time...

The /f switch only looks for inconsistencies in the file system, not
whether or not data can be read reliably from the drive. What good is a
valid file system if the bytes aren't reliably read from the media? By
the time you see any error message that you mention (I've yet to see one
in over 25 years of using PCs that explicitly states the media is the
fault) then it's too late and you've probably also lost some files.

How often do YOU run chkdsk (whatever set of parameters)? I maybe run
it once per year, if that, or when some abnomally appears in the
operation of the hard disk. No one runs it every day, every week, or
even every month. How often do you check the pressures of your car's
tires or its oil level?

Since most folks don't work 24 hours every day, their workstation will
be free at some time when the user isn't there. Since most folks sleep,
they computer will be idle at some time. There is no massive waste of
time to run chkdsk with its /r switch when you aren't even at that
computer.

On 11/03/2013 9:19 PM, VanguardLH wrote:
Tim Meddick wrote:

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch over
the [/f] is a [massive] waste of time...

The /f switch only looks for inconsistencies in the file system, not
whether or not data can be read reliably from the drive. What good is a
valid file system if the bytes aren't reliably read from the media? By
the time you see any error message that you mention (I've yet to see one
in over 25 years of using PCs that explicitly states the media is the
fault) then it's too late and you've probably also lost some files.

If there is any physical damage to sectors, then it will most likely be
picked up by the disk drive itself in its SMART monitoring. Usually if
the sector is still readable, it will try to move the sector to a spare
sector. If the sector is unrecoverable, then it'll be marked as an
unrecoverable sector in SMART. At that point you should run the chkdsk/r
to recover anything that can be, and possibly restore from backups those
files listed as bad. Should only run it after seeing unrecoverable
sectors from SMART, otherwise waste of time.

Yousuf Khan

In ,
Yousuf Khan typed:
On 11/03/2013 9:19 PM, VanguardLH wrote:
Tim Meddick wrote:

Also like to add; there is no real benefit in using the
exhaustive [/r] switch (rather than, simply, using the
[/f] switch, instead), unless you have received error
messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being
marked as bad. - Using the [/r] switch, in that case,
will effectively try to recover data residing in
those [bad] sectors. Other than for those [specific]
reasons, use of the [/r] switch over the [/f] is a [massive] waste of
time...

The /f switch only looks for inconsistencies in the file
system, not whether or not data can be read reliably
from the drive. What good is a valid file system if the
bytes aren't reliably read from the media? By the time
you see any error message that you mention (I've yet to
see one in over 25 years of using PCs that explicitly
states the media is the fault) then it's too late and
you've probably also lost some files.

If there is any physical damage to sectors, then it will
most likely be picked up by the disk drive itself in its
SMART monitoring. Usually if the sector is still
readable, it will try to move the sector to a spare
sector. If the sector is unrecoverable, then it'll be
marked as an unrecoverable sector in SMART. At that point
you should run the chkdsk/r to recover anything that can
be, and possibly restore from backups those files listed
as bad. Should only run it after seeing unrecoverable
sectors from SMART, otherwise waste of time.
Yousuf Khan

I have to disagree, though I don't see the need to run it very often. If
there are bad sectors on the disc surface, especially if they're in unused
space, it's better to let it mark the out BEFORE they cause problems.

That said, however, if/when I do find a hardware problem with the disc, I'll
run it every week or so to make sure the list of bad sectors isn't
increasing. SMART is great, but t doesn't catch everything.

Why wait until you have problems, possible unrecoverable, before running a
check?

HTH,

Twayne`

I didn't know the reasons for it, but knew the behaviour - exactly right -
just what I was trying to say!...

There's a difference between a little accumulated data corruption (which, I
was also saying, *can* lead to crash/boot problems, if not averted by
running [chkdsk /f] every so often (who hasn't found "FILE000.CHK" files
in the root directory at some time), and data-corruption due to physical
damage to the surface of a disk (which I have never actually witnessed
myself, except to old floppy-discs!!)...

==

Cheers, Tim Meddick, Peckham, London. :-)




"Yousuf Khan" wrote in message
...
On 11/03/2013 9:19 PM, VanguardLH wrote:
Tim Meddick wrote:

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless
you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as
bad. -
Using the [/r] switch, in that case, will effectively try to recover
data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch
over
the [/f] is a [massive] waste of time...

The /f switch only looks for inconsistencies in the file system, not
whether or not data can be read reliably from the drive. What good is a
valid file system if the bytes aren't reliably read from the media? By
the time you see any error message that you mention (I've yet to see one
in over 25 years of using PCs that explicitly states the media is the
fault) then it's too late and you've probably also lost some files.

If there is any physical damage to sectors, then it will most likely be
picked up by the disk drive itself in its SMART monitoring. Usually if
the sector is still readable, it will try to move the sector to a spare
sector. If the sector is unrecoverable, then it'll be marked as an
unrecoverable sector in SMART. At that point you should run the chkdsk/r
to recover anything that can be, and possibly restore from backups those
files listed as bad. Should only run it after seeing unrecoverable
sectors from SMART, otherwise waste of time.

Yousuf Khan

Yousuf Khan wrote:
On 11/03/2013 9:19 PM, VanguardLH wrote:
Tim Meddick wrote:

Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover
data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch
over
the [/f] is a [massive] waste of time...

The /f switch only looks for inconsistencies in the file system, not
whether or not data can be read reliably from the drive. What good is a
valid file system if the bytes aren't reliably read from the media? By
the time you see any error message that you mention (I've yet to see one
in over 25 years of using PCs that explicitly states the media is the
fault) then it's too late and you've probably also lost some files.

If there is any physical damage to sectors, then it will most likely be
picked up by the disk drive itself in its SMART monitoring. Usually if
the sector is still readable, it will try to move the sector to a spare
sector. If the sector is unrecoverable, then it'll be marked as an
unrecoverable sector in SMART. At that point you should run the chkdsk/r
to recover anything that can be, and possibly restore from backups those
files listed as bad. Should only run it after seeing unrecoverable
sectors from SMART, otherwise waste of time.

Yousuf Khan

The hard drive records spared out sectors. The SMART
statistics show limited information that it is happening.

As long as the hard drive has extra sectors to use, it will
automatically provide spares.

And when that is done, no CRC errors are reported to the user.
The disk looks "spotless", if a little slow, right up until
some area of the disk runs out of spares.

*******

When the automatic sparing feature of the hard drive is exhausted,
that's when you start to see CRC errors reported.

If you run CHKDSK, scan for sector read errors, if a CRC error
is found, not only that sector is considered bad, but the
entire cluster is marked as bad ($BADCLUS). The next time the
cluster is freed, it will not be re-used for file storage,
because the file system now has a record of it being bad ($BADCLUS).

http://support.microsoft.com/kb/103657

"$badclus, Bad Cluster File:
Contains all the bad clusters on the volume."

You have two levels of protection. The disk drive does it's part,
but when the disk drive is in bad shape, then the file system
has features to protect you. A CHKDSK scan at that point (scanning
for CRC errors), helps wall off the parts of the disk that
should no longer be used ($BADCLUS).

Paul

I have a related question.

I thought before I had tried using the chkdsk/f switch (and it said it had
to reboot to do this) and then after reboot, it kept trying to run it again
each time I rebooted - and I couldn't disable it from running again unless I
used msconfig. But my memory may be off. Does anybody know what I'm
referring to?

Tim Meddick wrote:
Also like to add; there is no real benefit in using the exhaustive [/r]
switch (rather than, simply, using the [/f] switch, instead), unless you
have received error messages stating, specifically, that the disk has
suffered physical damage that resulted in sectors being marked as bad. -
Using the [/r] switch, in that case, will effectively try to recover data
residing in those [bad] sectors.
Other than for those [specific] reasons, use of the [/r] switch over
the [/f] is a [massive] waste of time...

==

Cheers, Tim Meddick, Peckham, London. :-)




"Terry Pinnell" wrote in message
...
Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

I think I've found the answer to my own question. For my C: drive I had
to
run the chkdsk on reboot. For the E: drive I just had to 'unmount' it. It
seems that you do not then get a Winlogon event. I only became aware it
had finished when I realised that disk activity had stopped and as I had
no message window, there was presumably nothing to report for that day
and
a half's operation?

--
Terry, East Grinstead, UK

VanguardLH wrote:

Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

Why aren't you running a console-mode command inside a console (that
stays open)? Stop running "chkdsk" using the Win+R run dialog. When
the program exits, it's no longer there to provide a console (aka
command shell). Run "cmd" (command line interpreter) that opens a
console. THEN run console-mode commands within it. When the
console-mode program ends, the console will still be there because it
was loaded by cmd.exe which is still running.

Not sure I follow that. I've always use the Run box. Are you saying that
the chkdsk command (or at least the chkdsk /r version) should only be run
from XP's Command Prompt? Where is that documented please?

--
Terry, East Grinstead, UK

Terry Pinnell wrote:

VanguardLH wrote:

Terry Pinnell wrote:

A couple of days ago I did a chkdsk C: /r and as usual the results could
afterwards be studied in Event Viewer Application Winlogon.

Yesterday I started a similar check on my 2 TB external WD HD
chkdsk E: /r

It eventually finished after maybe 30 hours or so and the DOS window
closed, but there is no new Winlogon entry.

Anyone have any idea why, or where else I might see the results please?

Why aren't you running a console-mode command inside a console (that
stays open)? Stop running "chkdsk" using the Win+R run dialog. When
the program exits, it's no longer there to provide a console (aka
command shell). Run "cmd" (command line interpreter) that opens a
console. THEN run console-mode commands within it. When the
console-mode program ends, the console will still be there because it
was loaded by cmd.exe which is still running.

Not sure I follow that. I've always use the Run box. Are you saying that
the chkdsk command (or at least the chkdsk /r version) should only be run
from XP's Command Prompt? Where is that documented please?

The Run box runs the program you specified. When you run chkdsk, a
console window shows up for chkdsk. When chkdsk exits, so does its
console window. The Run dialog can't be leaving consoles open for every
command on the assumption you still want them around.

Win+R (run dialog)
Enter: cmd.exe (load the command-line interpreter)
This opens a console window for the cmd.exe program.
NOW run your console-mode programs, like chkdsk.
When those console-mode programs exist, the console remains.
That's because cmd.exe is still running so that's the console you see.
Look at the output of the console-mode programs you run in that console.
When you're done with that console, exit cmd.exe.
Enter the 'exit' command in the console to exit cmd.exe.
Or click on the "X" titlebar icon.

On 12/03/2013 7:18 PM, Tim Meddick wrote:
I didn't know the reasons for it, but knew the behaviour - exactly right
- just what I was trying to say!...

There's a difference between a little accumulated data corruption
(which, I was also saying, *can* lead to crash/boot problems, if not
averted by running [chkdsk /f] every so often (who hasn't found
"FILE000.CHK" files in the root directory at some time), and
data-corruption due to physical damage to the surface of a disk (which I
have never actually witnessed myself, except to old floppy-discs!!)...

Actually, those FILE*.CHK files are only created if there are real
messed up file metadata table issues in the filesystem, eg. messed up
pointers, etc. Those are now exceedingly rare, especially with NTFS,
they were much more likely to happen under the older FAT system which
didn't have any redundancy in the file tables. But when actual
corruption occurs inside the file data itself, then you won't have a
*.CHK file created. Instead the file will remain named the same, and
it'll not look any different than if there were no corruption. SMART
gives you an idea that there could be corruption of the data, but not
necessarily which file it's in. It's then that you need to run the
chkdsk/r to find the corrupted file that's sitting on that corrupted
sector. This is necessarily a long process because it's got to be
discovered sector by sector.

Yousuf Khan

In message , Terry Pinnell
writes:
VanguardLH wrote:
[]
Why aren't you running a console-mode command inside a console (that
stays open)? Stop running "chkdsk" using the Win+R run dialog. When
[]
Not sure I follow that. I've always use the Run box. Are you saying that
the chkdsk command (or at least the chkdsk /r version) should only be run
from XP's Command Prompt? Where is that documented please?

To give a shorter version of VLH's reply: the chkdsk command runs the
same whether you run it from the command prompt (either by finding it in
the menu structure or by typing cmd into the run box), or by typing it
directly into the run box. The difference is what happens when it has
finished: if you did it by typing it into the run box, the window
disappears; if you did it by typing it into a previously-opened command
window, the window doesn't disappear. The practical reason you might
want the window not to disappear is so that you can read any message the
command puts up, especially if it only puts it up as it finishes.

This applies to most commands, not just chkdsk, and to chkdsk with or
without /r.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

They are public servants, so we will threat them rather as Flashman treats
servants. - Stephen Fry on some people's attitudo to the BBC, in Radio Times,
3-9 July 2010