|Subject:||Destructive, dangerous Autochk.exe|
|Posted by:||Ian (I…@discussions.microsoft.com)|
|Date:||Mon, 26 Jun 2006|
An observation that someone from MS might care to comment on:
Relates to all NT- based OS's including XP:
When an unscheduled reboot happens, the system runs AUTOCHK.EXE to check the
system partition before reloading the OS. In principle this sounds like a
sensible precaution, however if any files were found to be damaged, then the
files are SILENTLY DELETED. The user is not told of this, nor is any option
to cancel given.
This in fact creates a far worse problem than if no automatic check had
taken place. The user now has a disk from which an unspecified number of
files are missing, and no easy way to tell which files, or even which folders
they were in.
From this point on, no program on the disk can be relied upon to function
correctly, and no documents, media or sourcecode can be treated as complete
or reliable. In fact, if the disk contents are in any way valuable, then the
only proper resolution is a full restore from tape.
Technically, the deletion is logged in the event logs, but this would only
be apparent to a very tech-savvy user, and even then, only if the user knew
something had gone amiss. Which he likely doesn't, especially if he didn't
observe the reboot.
The fragments of the files are moved to a FOUND.xxx folder in the root of
C:, however there is no simple way of identifying what the original filenames
were, hence again no way of telling what has been destroyed, or where it came
To cap it all, autochk.exe itself (in the system folder) is protected by SFT
and cannot be removed from the system.
I reackon the guys at MS need to have a long, hard think about this. Any
system which zaps files at random - the user unaware it's happening - is a
crazy piece of design.
Windows 9x used to run Scandisk in similar situations, however its action
was to inform the user of any damaged files found. Autochk does not.