[/QUOTE]
Actually, the hardware, rather than Windows.
MBR is replaced by FDisk /MBR and the corresponding Recovery Console
FixMBR command. The RC FixBoot "fixes" PBR, not MBR (if that) and
attends to Boot.ini perhaps (can't recall) and BootCfg /Rebuild does
Boot.ini (as the poster wanted) and maybe the PBR, but not MBR.
Lots of system-level things can play in MBR, such as boot managers
(e.g. to switch between Linux and Windows, or to hide Windows
installations on different partitions from each other). Compaq used
to put CMOS Setup in a "special" partition instead of ROM, and this
dumb-ass practice may be continuing with Acer.
Moral: Avoid big-brand systems.
Also (most likely) false, as noted in a previous post. It sets a flag
to indicate a volume should be checked - and that is not a BootExecute
setting, as we'll discuss later - and AFAIK that flag is in the
partition to be scanned. It used to be in the start of the FAT in
FATxx; dunno where it's set in NTFS, but expect it's similar.
This is the same "dirty" flag that is set and cleared during every
Windows session (so that a bad exit leaves it set) so if there were
any deadly incompatability here, it should have bitten you whether you
invoke AutoChk or not.
There's another flag set when a disk operation fails, that triggers
Scandisk surface scan in Win9x and may trigger a "ChkDsk /R" via
AutoChk in XP. AFAIK that flag is where the other one is, but as this
should mark a physical HD rather than a volume, it may be somewhere in
the HD's system space, from sectors 0 (MBR) to 62 or so.
It doesn't touch the MBR at all, it simply writes an entry to the
BootExecute value in the registry, in turn this entry is read when the
computer boots and chkdsk will run if the entry contains instructions
telling it to do so.
The BootExecute value can be used to suppress AutoChk for drive
letters; this is the only control you have over what AutoChk will do
(i.e. none, all you can do is kill it off). But AFAIK this value is
not dynamically altered to indicate what should be scanned in the way
that the "dirty" and "bad disk" flags do.
OK, let's look at a few of those links...
Ah! I see I'm wrong in some of what I wrote above:
http://support.microsoft.com/kb/218461/
If the administrator schedules the command to run the
next time the system restarts, Chkdsk does not set the
"Dirty Bit" on an in-use volume in order to check the
volume at the next boot. Instead, it sets a registry entry
to tell Autochk to run against that volume. The "Dirty Bit"
is set by the file system itself only if it detects a problem
Here's an example of bad design...
When Autochk runs against a volume at boot time it
records its output to a file called Bootex.log in the root
of the volume being checked. The Winlogon service
then moves the contents of each Bootex.log file to the
Application Event log. One event log message for each
volume checked is recorded as follows:
Event ID: 1001
Source: Winlogon
....what's wrong with this picture?
- you have to run Windows to access the event log
- you have to "smell" that ChkDsk/AutoChk is reported as "WinLogon"
Why not leave the last log (or better, append to whatever log exists)
in C:\ as a separate file, instead of "moving" it where it is more
difficult to read in the context of an unbootable OS on a dying HD?
Why not fix the side-effect of this system, so that log events stand
out as being from ChkDsk and AutoChk instead of "Winlogon"?
If file system's corrupted of the disk is failing, I want to know NOW.
(See also
http://support.microsoft.com/kb/275735 )
Back to the original article...
The registry entries used by Autochk to determine which
volumes get checked at boot time are:
Hkey_local_machine\System\CurrentControlSet\Control\Session
Manager\ BootExecute:REG_MULTI_SZ: autocheck autochk *
NOTE: This is the default setting for Autochk and also the result
of using Chkntfs /d to have all volumes checked at boot time.
I use Autocheck autochk /k
/k:E * (etc.) to prevent AutoChk from
screwing around "fixing" all volumes other than C:, as I'd rather use
DOS Mode Scandisk instead (as I can for FATxx < 137G).
What this article suggests is that certain commands can blow out my
protective setting and expose my data to auto-slaughter instead.
Thinking of ChkDsk /d in particular. See also...
http://support.microsoft.com/kb/158675
....implying similar risks, if ChkDsk ignores whatever settings are
already there. MS has a bad track record in such matters.
This is interesting...
http://www.microsoft.com/technet/sysinternals/information/NativeApplications.mspx
....as it explains the need for AutoCk duplicating what ChkDsk does.
Thanks for great links
