|
Posted by Joe Richards [MVP] on June 26, 2006, 12:23 pm
If you were Registered and logged in, you could reply and use other advanced thread options
The only time autochk is run is when the file system is considered dirty
when it is shut down and that doesn't occur with every unscheduled
reboot or even MOST unscheduled reboots. In fact, in the 10 years I have
been running NT Based machines (thousands if not tens of thousands of
them) I have seen Autochk only a handful of times and I play with flakey
test drivers on a regular basis and see blue screen reboots on a regular
basis.
When the FS is dirty that means the state of the disk is indeterminent
and already considered unsafe. Unless you have a very flaky disk, mobo,
or power supply you shouldn't hardly EVER be seeing autochk.
It is possible to disable the autochk (as well as force it to run on the
next reboot). Trying to control system functionality by deleting system
files is pretty unenlightened. Just search the web and you will find
directions as all it takes a very simple registry edit.
That being said, I much rather have autochk remove files than depend on
a system that could have a bad disk and not knowing if it is corrupt or
not. If I had a machine that seemed to be autochking a lot, I would look
at what is wrong with the hardware.
joe
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm
Ian wrote:
> 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
> from.
>
> 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.
>
>
| 
XML site map