CHKDSK Log

Discussion in 'Computer Information' started by Jeff Strickland, May 31, 2012.

  1. 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?
    Jeff Strickland, May 31, 2012
    #1
    1. Advertising

  2. Jeff Strickland

    Paul Guest

    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
    Paul, May 31, 2012
    #2
    1. Advertising

  3. "Paul" <> wrote in message
    news:jq8jei$2i9$...
    > 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.
    Jeff Strickland, May 31, 2012
    #3
  4. Jeff Strickland

    Paul Guest

    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
    Paul, Jun 1, 2012
    #4
  5. Jeff Strickland

    VanguardLH Guest

    Jeff Strickland wrote:

    > "Paul" <> wrote in message
    > news:jq8jei$2i9$...
    >> 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.
    VanguardLH, Jun 6, 2012
    #5
  6. "VanguardLH" <> wrote in message
    news:jqnrqq$jf3$...
    > Jeff Strickland wrote:
    >
    >> "Paul" <> wrote in message
    >> news:jq8jei$2i9$...
    >>> 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?
    Jeff Strickland, Jun 6, 2012
    #6
  7. Jeff Strickland

    VanguardLH Guest

    Jeff Strickland wrote:

    > "VanguardLH" <> wrote in message
    > news:jqnrqq$jf3$...
    >> Jeff Strickland wrote:
    >>
    >>> "Paul" <> wrote in message
    >>> news:jq8jei$2i9$...
    >>>> 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?
    VanguardLH, Jun 6, 2012
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rocky

    Where is log file for chkdsk for Windows XP?

    Rocky, Jul 9, 2003, in forum: Computer Support
    Replies:
    8
    Views:
    83,797
    hacklestone
    May 13, 2009
  2. jaze
    Replies:
    0
    Views:
    577
  3. Jimmy Dean
    Replies:
    4
    Views:
    792
    Timmy
    Sep 9, 2003
  4. Nottoman

    Is there a log file for CHKDSK in Win2000?

    Nottoman, Dec 20, 2003, in forum: Computer Support
    Replies:
    2
    Views:
    2,896
  5. Jerry G.

    Log On Screen Changed. No More Auto-Log On.

    Jerry G., Oct 22, 2004, in forum: Computer Support
    Replies:
    2
    Views:
    533
    Locke Nash Cole
    Oct 22, 2004
Loading...

Share This Page