Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Information > CHKDSK Log

Reply
Thread Tools

CHKDSK Log

 
 
Jeff Strickland
Guest
Posts: n/a
 
      05-31-2012
Seems to me that anytime CHKDSK runs, it should halt at the end and display
the results until the operator (me) comes along and clicks NEXT.

Where do I find the file that stores the last CHKDSK results?


 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      05-31-2012
Jeff Strickland wrote:
> Seems to me that anytime CHKDSK runs, it should halt at the end and
> display the results until the operator (me) comes along and clicks NEXT.
>
> Where do I find the file that stores the last CHKDSK results?


There's no reason for the various versions of Windows to do their
CHKDSK the same way.

You could visit the various specific Windows groups and ask there.

alt.windows7.general
microsoft.public.windowsxp.general

and so on.

I think in the case of my Windows 7 laptop, in the System Volume Information
folder, there were some CHKDSK related files. They were stored in binary
mode, and were not decipherable. The files were fairly small. Now, what's
wrong with this observation ? Windows 7 makes all attempts at accessing
SVI "Access Denied". Not even NFI or contig can get in there, running elevated.
To do what I did, I had to do it from Linux. And there is a danger, if you
screw around in there, Windows 7 won't boot the next time. So it's not like
in good conscience, I can recommend heading in that direction.
Stay out of there!

It's possible the output options of CHKDSK, depend on whether
it's run from GUI or from command line. From GUI, perhaps the
results are stored in Event Viewer somewhere. From command line,
there'd be an option to dump them to the screen.

Since CHKDSK can run from early in the Windows booting process
(before C: is mounted for actual usage), there is a problem
at that point in time, with recording anything. I don't know
how they handle that. To CHKDSK C:, C: would normally be
busy, and the OS instead schedules C: for a check on the
next reboot. And then, a particular registry key is modified,
so that the CHKDSK command gets run, and right before
Windows is fully started. For partitions other than C:,
a CHKDSK can be run immediately (with output as a function
of launching method).

It's Windows - it's meant to be mysterious.

Paul
 
Reply With Quote
 
 
 
 
Jeff Strickland
Guest
Posts: n/a
 
      05-31-2012

"Paul" <(E-Mail Removed)> wrote in message
news:jq8jei$2i9$(E-Mail Removed)...
> Jeff Strickland wrote:
>> Seems to me that anytime CHKDSK runs, it should halt at the end and
>> display the results until the operator (me) comes along and clicks NEXT.
>>
>> Where do I find the file that stores the last CHKDSK results?

>
> There's no reason for the various versions of Windows to do their
> CHKDSK the same way.
>
> You could visit the various specific Windows groups and ask there.
>
> alt.windows7.general
> microsoft.public.windowsxp.general
>
> and so on.
>
> I think in the case of my Windows 7 laptop, in the System Volume
> Information
> folder, there were some CHKDSK related files. They were stored in binary
> mode, and were not decipherable. The files were fairly small. Now, what's
> wrong with this observation ? Windows 7 makes all attempts at accessing
> SVI "Access Denied". Not even NFI or contig can get in there, running
> elevated.
> To do what I did, I had to do it from Linux. And there is a danger, if you
> screw around in there, Windows 7 won't boot the next time. So it's not
> like
> in good conscience, I can recommend heading in that direction.
> Stay out of there!
>
> It's possible the output options of CHKDSK, depend on whether
> it's run from GUI or from command line. From GUI, perhaps the
> results are stored in Event Viewer somewhere. From command line,
> there'd be an option to dump them to the screen.
>
> Since CHKDSK can run from early in the Windows booting process
> (before C: is mounted for actual usage), there is a problem
> at that point in time, with recording anything. I don't know
> how they handle that. To CHKDSK C:, C: would normally be
> busy, and the OS instead schedules C: for a check on the
> next reboot. And then, a particular registry key is modified,
> so that the CHKDSK command gets run, and right before
> Windows is fully started. For partitions other than C:,
> a CHKDSK can be run immediately (with output as a function
> of launching method).
>
> It's Windows - it's meant to be mysterious.
>
> Paul


Win XP Home, SP3.

CHKDSK runs at boot time. One selects it from within Windows, but it does
not run until the next boot sequence. There is no reason that the process
cannot halt when finished, and wait for user intervention to proceed to
launching Windows. Indeed, not only is there no reason that the boot
sequence cannot be halted when CHKDSK is finished, it is stupid from where I
sit that there is not a requirement for user intervention before Windows can
begin to load. Sure, how many people run CHKDSK? Not many, I am sure. But
anybody that's doing diagnostics on a machine might want to do it, and they
would almost always want the results so they have an idea of what they are
dealing with. All the CHKDSK command needs -- it is a DOS-level command, so
it would not impact Windows at all in any way -- is a halt with a prompt,
PRESS ANY KEY TO CONTINUE. This would slow the loading of Windows ONLY when
chkdsk runs, but so what?

But whatever. I ran CHKDSK, and now I want to know what it found, but I
don't know where the file hides.




 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      06-01-2012
Jeff Strickland wrote:

>
> Win XP Home, SP3.
>
> CHKDSK runs at boot time. One selects it from within Windows, but it
> does not run until the next boot sequence. There is no reason that the
> process cannot halt when finished, and wait for user intervention to
> proceed to launching Windows. Indeed, not only is there no reason that
> the boot sequence cannot be halted when CHKDSK is finished, it is stupid
> from where I sit that there is not a requirement for user intervention
> before Windows can begin to load. Sure, how many people run CHKDSK? Not
> many, I am sure. But anybody that's doing diagnostics on a machine might
> want to do it, and they would almost always want the results so they
> have an idea of what they are dealing with. All the CHKDSK command needs
> -- it is a DOS-level command, so it would not impact Windows at all in
> any way -- is a halt with a prompt, PRESS ANY KEY TO CONTINUE. This
> would slow the loading of Windows ONLY when chkdsk runs, but so what?
>
> But whatever. I ran CHKDSK, and now I want to know what it found, but I
> don't know where the file hides.


Just ran it here. Went to command prompt, and did a "chkdsk /f c:"
to schedule a CHKDSK run during bootup.

It took about 2 minutes to run, gave a passing grade, and went
right on to show the usual desktop.

I went to Settings : Control Panel , clicked the Administrative Tools,
selected Event Viewer, clicked the Application entry on the left, then
looked at the topmost "Winlogon" event on the right. Double clicking on
that gave me:

*******
5/31/2012
9:35:06 PM
Information

Checking file system on C:
The type of the file system is FAT32.

A disk check has been scheduled.
Windows will now check the disk.
Volume Serial Number is 492A-AC63
76089312 KB total disk space.
5286496 KB in 952 hidden files.
467200 KB in 14496 folders.
45415776 KB in 183374 files.
24919808 KB are available.

32768 bytes in each allocation unit.
2377791 total allocation units on disk.
*******

So that's an example of a log entry created by CHKDSK.
WinXP SP3 Pro 32 bit (OEM).

Paul
 
Reply With Quote
 
VanguardLH
Guest
Posts: n/a
 
      06-06-2012
Jeff Strickland wrote:

> "Paul" <(E-Mail Removed)> wrote in message
> news:jq8jei$2i9$(E-Mail Removed)...
>> Jeff Strickland wrote:
>>> Seems to me that anytime CHKDSK runs, it should halt at the end and
>>> display the results until the operator (me) comes along and clicks NEXT.
>>>
>>> Where do I find the file that stores the last CHKDSK results?

>>
>> There's no reason for the various versions of Windows to do their
>> CHKDSK the same way.
>>
>> You could visit the various specific Windows groups and ask there.
>>
>> alt.windows7.general
>> microsoft.public.windowsxp.general
>>
>> and so on.
>>
>> I think in the case of my Windows 7 laptop, in the System Volume
>> Information
>> folder, there were some CHKDSK related files. They were stored in binary
>> mode, and were not decipherable. The files were fairly small. Now, what's
>> wrong with this observation ? Windows 7 makes all attempts at accessing
>> SVI "Access Denied". Not even NFI or contig can get in there, running
>> elevated.
>> To do what I did, I had to do it from Linux. And there is a danger, if you
>> screw around in there, Windows 7 won't boot the next time. So it's not
>> like
>> in good conscience, I can recommend heading in that direction.
>> Stay out of there!
>>
>> It's possible the output options of CHKDSK, depend on whether
>> it's run from GUI or from command line. From GUI, perhaps the
>> results are stored in Event Viewer somewhere. From command line,
>> there'd be an option to dump them to the screen.
>>
>> Since CHKDSK can run from early in the Windows booting process
>> (before C: is mounted for actual usage), there is a problem
>> at that point in time, with recording anything. I don't know
>> how they handle that. To CHKDSK C:, C: would normally be
>> busy, and the OS instead schedules C: for a check on the
>> next reboot. And then, a particular registry key is modified,
>> so that the CHKDSK command gets run, and right before
>> Windows is fully started. For partitions other than C:,
>> a CHKDSK can be run immediately (with output as a function
>> of launching method).
>>
>> It's Windows - it's meant to be mysterious.
>>
>> Paul

>
> Win XP Home, SP3.
>
> CHKDSK runs at boot time. One selects it from within Windows, but it does
> not run until the next boot sequence. There is no reason that the process
> cannot halt when finished, and wait for user intervention to proceed to
> launching Windows. Indeed, not only is there no reason that the boot
> sequence cannot be halted when CHKDSK is finished, it is stupid from where I
> sit that there is not a requirement for user intervention before Windows can
> begin to load. Sure, how many people run CHKDSK? Not many, I am sure. But
> anybody that's doing diagnostics on a machine might want to do it, and they
> would almost always want the results so they have an idea of what they are
> dealing with. All the CHKDSK command needs -- it is a DOS-level command, so
> it would not impact Windows at all in any way -- is a halt with a prompt,
> PRESS ANY KEY TO CONTINUE. This would slow the loading of Windows ONLY when
> chkdsk runs, but so what?
>
> But whatever. I ran CHKDSK, and now I want to know what it found, but I
> don't know where the file hides.


When you run chkdsk and it reports the volume is inuse (and you cannot
unlock it because it is the OS partition or you simply don't want to
release access to your data files right now), you can opt to run it on
Windows next boot. That adds an entry for chkdsk under the BootExecute
registry key (that Windows checks on startup to run whatever is listed
there - and which could include malware).

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

At that point in the boot process, I doubt that stdout redirection will
work. That means modifying the BootExecute entry to run:

autocheck autochk * /r\DosDevice\C: > C:\chkdsk.log

probably won't work. Since the command interpreter hasn't yet been
loaded or isn't available, you can't replace that command line in the
registry with a .bat file to run chkdsk following by a pause command.
There won't be a command interpreter available yet to parse the .bat
file to run each command within it.

Have you tried running chkdsk when booting into Recovery Console mode?
I haven't tested this to know if chkdsk will run on the OS partition
without the lockout when under Recovery Console mode. If it does work,
Recovery Console mode is a command console (or shell) so the output of
chkdsk will remain on screen.

On advanced or enterprise versions of Windows (i.e., server versions),
the output of chkdsk gets logged into the Application log that you can
see with Event Viewer. Maybe this works, too, for workstation versions
of Windows. Schedule chkdsk to run on boot, let it run, let Windows
load and login, and then check the Event Viewer under Applications to
see if there's an entry in there for the chkdsk results. I've never
tried this but then I didn't think about it until today. From what I've
read of posts by others, chkdsk's results gets recorded in the event
logs and is visible at Event Viewer -> Application, click "Source" at
top (to sort by that column), scroll down to WinInit and [double-]click
to view its details. If this works, I learned something new today.
 
Reply With Quote
 
Jeff Strickland
Guest
Posts: n/a
 
      06-06-2012

"VanguardLH" <(E-Mail Removed)> wrote in message
news:jqnrqq$jf3$(E-Mail Removed)...
> Jeff Strickland wrote:
>
>> "Paul" <(E-Mail Removed)> wrote in message
>> news:jq8jei$2i9$(E-Mail Removed)...
>>> Jeff Strickland wrote:
>>>> Seems to me that anytime CHKDSK runs, it should halt at the end and
>>>> display the results until the operator (me) comes along and clicks
>>>> NEXT.
>>>>
>>>> Where do I find the file that stores the last CHKDSK results?
>>>
>>> There's no reason for the various versions of Windows to do their
>>> CHKDSK the same way.
>>>
>>> You could visit the various specific Windows groups and ask there.
>>>
>>> alt.windows7.general
>>> microsoft.public.windowsxp.general
>>>
>>> and so on.
>>>
>>> I think in the case of my Windows 7 laptop, in the System Volume
>>> Information
>>> folder, there were some CHKDSK related files. They were stored in binary
>>> mode, and were not decipherable. The files were fairly small. Now,
>>> what's
>>> wrong with this observation ? Windows 7 makes all attempts at accessing
>>> SVI "Access Denied". Not even NFI or contig can get in there, running
>>> elevated.
>>> To do what I did, I had to do it from Linux. And there is a danger, if
>>> you
>>> screw around in there, Windows 7 won't boot the next time. So it's not
>>> like
>>> in good conscience, I can recommend heading in that direction.
>>> Stay out of there!
>>>
>>> It's possible the output options of CHKDSK, depend on whether
>>> it's run from GUI or from command line. From GUI, perhaps the
>>> results are stored in Event Viewer somewhere. From command line,
>>> there'd be an option to dump them to the screen.
>>>
>>> Since CHKDSK can run from early in the Windows booting process
>>> (before C: is mounted for actual usage), there is a problem
>>> at that point in time, with recording anything. I don't know
>>> how they handle that. To CHKDSK C:, C: would normally be
>>> busy, and the OS instead schedules C: for a check on the
>>> next reboot. And then, a particular registry key is modified,
>>> so that the CHKDSK command gets run, and right before
>>> Windows is fully started. For partitions other than C:,
>>> a CHKDSK can be run immediately (with output as a function
>>> of launching method).
>>>
>>> It's Windows - it's meant to be mysterious.
>>>
>>> Paul

>>
>> Win XP Home, SP3.
>>
>> CHKDSK runs at boot time. One selects it from within Windows, but it does
>> not run until the next boot sequence. There is no reason that the process
>> cannot halt when finished, and wait for user intervention to proceed to
>> launching Windows. Indeed, not only is there no reason that the boot
>> sequence cannot be halted when CHKDSK is finished, it is stupid from
>> where I
>> sit that there is not a requirement for user intervention before Windows
>> can
>> begin to load. Sure, how many people run CHKDSK? Not many, I am sure. But
>> anybody that's doing diagnostics on a machine might want to do it, and
>> they
>> would almost always want the results so they have an idea of what they
>> are
>> dealing with. All the CHKDSK command needs -- it is a DOS-level command,
>> so
>> it would not impact Windows at all in any way -- is a halt with a prompt,
>> PRESS ANY KEY TO CONTINUE. This would slow the loading of Windows ONLY
>> when
>> chkdsk runs, but so what?
>>
>> But whatever. I ran CHKDSK, and now I want to know what it found, but I
>> don't know where the file hides.

>
> When you run chkdsk and it reports the volume is inuse (and you cannot
> unlock it because it is the OS partition or you simply don't want to
> release access to your data files right now), you can opt to run it on
> Windows next boot. That adds an entry for chkdsk under the BootExecute
> registry key (that Windows checks on startup to run whatever is listed
> there - and which could include malware).
>
> http://support.microsoft.com/kb/158675
>
> At that point in the boot process, I doubt that stdout redirection will
> work. That means modifying the BootExecute entry to run:
>
> autocheck autochk * /r\DosDevice\C: > C:\chkdsk.log
>
> probably won't work. Since the command interpreter hasn't yet been
> loaded or isn't available, you can't replace that command line in the
> registry with a .bat file to run chkdsk following by a pause command.
> There won't be a command interpreter available yet to parse the .bat
> file to run each command within it.
>
> Have you tried running chkdsk when booting into Recovery Console mode?
> I haven't tested this to know if chkdsk will run on the OS partition
> without the lockout when under Recovery Console mode. If it does work,
> Recovery Console mode is a command console (or shell) so the output of
> chkdsk will remain on screen.
>
> On advanced or enterprise versions of Windows (i.e., server versions),
> the output of chkdsk gets logged into the Application log that you can
> see with Event Viewer. Maybe this works, too, for workstation versions
> of Windows. Schedule chkdsk to run on boot, let it run, let Windows
> load and login, and then check the Event Viewer under Applications to
> see if there's an entry in there for the chkdsk results. I've never
> tried this but then I didn't think about it until today. From what I've
> read of posts by others, chkdsk's results gets recorded in the event
> logs and is visible at Event Viewer -> Application, click "Source" at
> top (to sort by that column), scroll down to WinInit and [double-]click
> to view its details. If this works, I learned something new today.



It seems odd to me (I'm an old guy that has been around since DOS3.1 was
king) that a vital diagnostic tool such as CHKDSK cannot have a Halt Routine
built into the last line of code so that the results can be seen if the
technician/user that invoked the tool is not present when the utility
finishes what it does. If there are <some number> of bad sectors on the
drive, that is critical information, and if the report cannot be reviewed
before the OS loads, then the results ought to be stored in a text file
someplace, arguably on the root directory, where they can be reviewed later.

I fully understand why CHKDSK cannot run until boot time, and as far as I
know, one cannot invoke the Recovery Console and run CHKDSK because CHKDSK
runs before the Recovery Console should be starting. The machine finishes
POST, then starts CHKDSK if there is a request for it to run that I assume
is flagged someplace such as win.ini or boot.ini, although I am not sure
where the command to start CHKDSK is stored. There is enough of a command
intrepreter to run that the machine knows to run CHKDSK, or not, so it
stands to reason that the default behavior of the untility ought to be that
it halts at the completion of running so that the results can be viewed.

Since the results cannot be viewed unless one happens to be standing over
the machine at the moment the utility finishes, then the results should be
someplace to be viewed later, my questions are, is there a place, and, what
is that place?



 
Reply With Quote
 
VanguardLH
Guest
Posts: n/a
 
      06-06-2012
Jeff Strickland wrote:

> "VanguardLH" <(E-Mail Removed)> wrote in message
> news:jqnrqq$jf3$(E-Mail Removed)...
>> Jeff Strickland wrote:
>>
>>> "Paul" <(E-Mail Removed)> wrote in message
>>> news:jq8jei$2i9$(E-Mail Removed)...
>>>> Jeff Strickland wrote:
>>>>> Seems to me that anytime CHKDSK runs, it should halt at the end and
>>>>> display the results until the operator (me) comes along and clicks
>>>>> NEXT.
>>>>>
>>>>> Where do I find the file that stores the last CHKDSK results?
>>>>
>>>> There's no reason for the various versions of Windows to do their
>>>> CHKDSK the same way.
>>>>
>>>> You could visit the various specific Windows groups and ask there.
>>>>
>>>> alt.windows7.general
>>>> microsoft.public.windowsxp.general
>>>>
>>>> and so on.
>>>>
>>>> I think in the case of my Windows 7 laptop, in the System Volume
>>>> Information
>>>> folder, there were some CHKDSK related files. They were stored in binary
>>>> mode, and were not decipherable. The files were fairly small. Now,
>>>> what's
>>>> wrong with this observation ? Windows 7 makes all attempts at accessing
>>>> SVI "Access Denied". Not even NFI or contig can get in there, running
>>>> elevated.
>>>> To do what I did, I had to do it from Linux. And there is a danger, if
>>>> you
>>>> screw around in there, Windows 7 won't boot the next time. So it's not
>>>> like
>>>> in good conscience, I can recommend heading in that direction.
>>>> Stay out of there!
>>>>
>>>> It's possible the output options of CHKDSK, depend on whether
>>>> it's run from GUI or from command line. From GUI, perhaps the
>>>> results are stored in Event Viewer somewhere. From command line,
>>>> there'd be an option to dump them to the screen.
>>>>
>>>> Since CHKDSK can run from early in the Windows booting process
>>>> (before C: is mounted for actual usage), there is a problem
>>>> at that point in time, with recording anything. I don't know
>>>> how they handle that. To CHKDSK C:, C: would normally be
>>>> busy, and the OS instead schedules C: for a check on the
>>>> next reboot. And then, a particular registry key is modified,
>>>> so that the CHKDSK command gets run, and right before
>>>> Windows is fully started. For partitions other than C:,
>>>> a CHKDSK can be run immediately (with output as a function
>>>> of launching method).
>>>>
>>>> It's Windows - it's meant to be mysterious.
>>>>
>>>> Paul
>>>
>>> Win XP Home, SP3.
>>>
>>> CHKDSK runs at boot time. One selects it from within Windows, but it does
>>> not run until the next boot sequence. There is no reason that the process
>>> cannot halt when finished, and wait for user intervention to proceed to
>>> launching Windows. Indeed, not only is there no reason that the boot
>>> sequence cannot be halted when CHKDSK is finished, it is stupid from
>>> where I
>>> sit that there is not a requirement for user intervention before Windows
>>> can
>>> begin to load. Sure, how many people run CHKDSK? Not many, I am sure. But
>>> anybody that's doing diagnostics on a machine might want to do it, and
>>> they
>>> would almost always want the results so they have an idea of what they
>>> are
>>> dealing with. All the CHKDSK command needs -- it is a DOS-level command,
>>> so
>>> it would not impact Windows at all in any way -- is a halt with a prompt,
>>> PRESS ANY KEY TO CONTINUE. This would slow the loading of Windows ONLY
>>> when
>>> chkdsk runs, but so what?
>>>
>>> But whatever. I ran CHKDSK, and now I want to know what it found, but I
>>> don't know where the file hides.

>>
>> When you run chkdsk and it reports the volume is inuse (and you cannot
>> unlock it because it is the OS partition or you simply don't want to
>> release access to your data files right now), you can opt to run it on
>> Windows next boot. That adds an entry for chkdsk under the BootExecute
>> registry key (that Windows checks on startup to run whatever is listed
>> there - and which could include malware).
>>
>> http://support.microsoft.com/kb/158675
>>
>> At that point in the boot process, I doubt that stdout redirection will
>> work. That means modifying the BootExecute entry to run:
>>
>> autocheck autochk * /r\DosDevice\C: > C:\chkdsk.log
>>
>> probably won't work. Since the command interpreter hasn't yet been
>> loaded or isn't available, you can't replace that command line in the
>> registry with a .bat file to run chkdsk following by a pause command.
>> There won't be a command interpreter available yet to parse the .bat
>> file to run each command within it.
>>
>> Have you tried running chkdsk when booting into Recovery Console mode?
>> I haven't tested this to know if chkdsk will run on the OS partition
>> without the lockout when under Recovery Console mode. If it does work,
>> Recovery Console mode is a command console (or shell) so the output of
>> chkdsk will remain on screen.
>>
>> On advanced or enterprise versions of Windows (i.e., server versions),
>> the output of chkdsk gets logged into the Application log that you can
>> see with Event Viewer. Maybe this works, too, for workstation versions
>> of Windows. Schedule chkdsk to run on boot, let it run, let Windows
>> load and login, and then check the Event Viewer under Applications to
>> see if there's an entry in there for the chkdsk results. I've never
>> tried this but then I didn't think about it until today. From what I've
>> read of posts by others, chkdsk's results gets recorded in the event
>> logs and is visible at Event Viewer -> Application, click "Source" at
>> top (to sort by that column), scroll down to WinInit and [double-]click
>> to view its details. If this works, I learned something new today.

>
> It seems odd to me (I'm an old guy that has been around since DOS3.1 was
> king) that a vital diagnostic tool such as CHKDSK cannot have a Halt Routine
> built into the last line of code so that the results can be seen if the
> technician/user that invoked the tool is not present when the utility
> finishes what it does. If there are <some number> of bad sectors on the
> drive, that is critical information, and if the report cannot be reviewed
> before the OS loads, then the results ought to be stored in a text file
> someplace, arguably on the root directory, where they can be reviewed later.
>
> I fully understand why CHKDSK cannot run until boot time, and as far as I
> know, one cannot invoke the Recovery Console and run CHKDSK because CHKDSK
> runs before the Recovery Console should be starting. The machine finishes
> POST, then starts CHKDSK if there is a request for it to run that I assume
> is flagged someplace such as win.ini or boot.ini, although I am not sure
> where the command to start CHKDSK is stored. There is enough of a command
> intrepreter to run that the machine knows to run CHKDSK, or not, so it
> stands to reason that the default behavior of the untility ought to be that
> it halts at the completion of running so that the results can be viewed.
>
> Since the results cannot be viewed unless one happens to be standing over
> the machine at the moment the utility finishes, then the results should be
> someplace to be viewed later, my questions are, is there a place, and, what
> is that place?


Did you do the mentioned setup where you schedule chkdsk to run at boot
time and then later go look in Event Viewer's Application log?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Where is log file for chkdsk for Windows XP? Rocky Computer Support 8 05-13-2009 07:05 AM
Is there a log file for CHKDSK in Win2000? Nottoman Computer Support 2 12-20-2003 05:51 AM
CHKDSK, cannot lock current drive. Derek F Computer Support 4 10-25-2003 12:03 AM
CHKDSK doesn't run if I have a bad shutdown in WinXP Pro (SP1) Jimmy Dean Computer Support 4 09-09-2003 11:16 AM
2nd partition of disk 2 ALWAYS needs to run CHKDSK jaze Computer Support 0 09-05-2003 08:05 AM



Advertisments