On Sat, 07 Jul 2007 13:06:34 -0300, John John
>M.I.5¾ wrote:
>> "Mark F." <reply2group@nospam.com> wrote in message
>>>M.I.5¾ wrote:
>>>>"Patrick Keenan" <test@dev.null> wrote in message
>>>>>"lonerlette" <lonerlette@discussions.microsoft.com> wrote in message
>>>>>>Boot.ini file was deleted from my laptop, I have no xp disk
>>>>>You can borrow any bootable XP CD to run bootcfg /rebuild from
>>>>>the Recovery Console.
>>>>Though generally true, it is not universally true. Some manufacturers
>>>>customise the windows
Actually, the hardware, rather than Windows.
>>>>to such an extent that generic windows disks won't work.
>>>>Many of those affected machines will be rendered non bootable if you just
>>>>try to do an error check on the system disk. This is because windows
>>>>immediately re-writes the Master Boot Record to make the machine boot
>>>>into a DOS based disk check - the generic MBR used not being valid for
>>>>the PC. If you succeed in replacing the MBR from the HP recovery disk,
>>>>Scandisk runs and then craps the PC again as Windows then replaces the
>>>>MBR with the generic windows MBR which is, again, invalid.
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.
>> chkdsk does not nomally re-write the MBR. But if you try to check the
>> Windows system drive (usually C or the drive that the swap file is on (if
>> different), this cannot be done while Windows is running. Hence chkdsk
>> writes an MBR that causes (or should cause) the machine to boot into a DOS
>> mode; reboots the machine and runs scandisk. It then reverses the
>> procedure once scandisk has done its stuff.
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.
>http://search.microsoft.com/results...0=Search&FORM=QBME1&l=1&mkt=en-US&PageType=99
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
>------------------------- ---- --- -- - - - -
I'm on a ten-year lunch break
>------------------------- ---- --- -- - - - -