PC Health
The new features bound into Windows Millennium fall into two categories; add-on fluff like Windows Media Player and Movie Maker, and core system functionalities that are grouped together as PC Health. The latter group include:
System File Protection
System Restore
System Information (part of Help and Support)
Windows Update
System File Protection
and System Restore overlap in that both are run from *statemgr that is run from the registry on startup. This builds backup data in C:\_RESTORE, which is used by System Restore to fall back to a previous state. The other PC Health item in the startup axis (and Tasks) builds another set of data that is merely used to describe the system via System Information, for the erudition of user and tech support. Both subsections of the PC Health group of technologies can be a nuisance sometimes, and it's nice that they can be amputated separately should the need arise.Sometimes problems arise with the more trivial
item that collects System Information; typically it remains active and slows the system
down, whereas it's normally hardly noticeable. If this happens, you can remove it from
Tasks and the startup axis, with no ill effects. It's *statemgr
and the features that it powers that I'll be concentrating on here.
The roots of SFP can be traced back to the original Windows 95, which defended it's Winsock.dll and WSock32.dll against 3rd-party software installations by checking these on startup and replacing them if they had changed. Windows 98 introduced System File Checker (SFC) that broadened the scope to all system code, but this was more of a passive tool for the savvy user to apply manually. In keeping with Windows Millennium's "protect the new users from themselves" philosophy, SFP is a fully automated protection for monitored files that are replaced in real time as they are deleted or changed.
What SFP watches for are attempts to open protected files for writes. It does not monitor the contents of these files (the overhead would be onerous if it did, though checksums are wonderful things), it does not prevent "upgrades" of these files if done though the accepted installation process, and it won't pick up wild writes or cross-links that corrupt them without opening them by name. I suspect there's no communication from ScanDisk to SFP should the former delete or "fix" a protected file, so I'd not expect SFP to repair whatever ScanDisk finds to have been damaged.
So SFP doesn't protect against much other than explicit user-level deletions or overwrites. This is still useful, but probably not as essential a service as many assume. SFP appears to have no role for the most worrying of problems; file system corruption and malware attack.
As part of your risk management, you may want to deliberately inactivate some Windows functionalities that are more likely to be used by malware than the user, by renaming away certain system files that are required for these. In this context, SFP becomes a nuisance, defending the malware's right to attack your system against your attempts to defend it!
However, it's possible to bath the baby without drowning it in too much bath water. Instead of systematically killing SFP, you can edit the files that control what it does, so that the files you want to rename away will not be "protected". There are two easily-edited text files that are useful for this purpose; FILELIST.XML (which lists the files and directories that are to be protected or not), and sfpdb.sfp (which lists where the "proper" originals of these files are held).
The method I use is to first edit FILELIST.XML from DOS mode, to remove itself from protection; after that, further edits can be done from within Windows, though in practice I do these from DOS mode at the same time. Then I can edit FILELIST.XML and sfpdb.sfp to exclude the files I want to remove, without having to cycle System Restore to put these changes into effect. You can also edit FILELIST.XML alone, but then you need to cycle SR to propagate your changes to the binary VDXMON.DAT file it really uses.
FILELIST.XML lives in %WinDir%\System\Restore, and can be edited from DOS mode via Edit, or (once it is not "protected" by SFP) in Windows. The syntax may look familiar if you've looked at raw HTML; each section starts with a <heading> and ends with a negation </heading>, e.g. <sfp> (...several lines...) </sfp>, or <exclude> (...several lines...) </exclude>.
XML files are a bit different in syntax to the .ini conventions we are used to - for a start, you don't comment out lines by preceding these with a semicolon or other character. So I find it easier to use Edit, Find to find a reference to the file I am after, then select the entire line, cut it, and paste it at the top of the <exclude> section. As always, it's a Good Idea to keep a copy of the original FILELIST.XML file so you can fall back to that if your edits go pear-shaped.
In contrast, sfpdb.sfp is a fairly straightforward .ini-syntax file (although there are no [section headings] present), where you can precede offending lines with a semicolon to deactivate them by "commenting them out". The sfpdb.sfp file lives in %WinDir%\System\SFP, and can be edited from DOS mode via Edit, or (once it is not "protected" by SFP) in Windows. Keep a backup copy in case something goes wrong, and you can track changes more easily by locating your commented-out lines at the top of the file.
Bottom line
My policy is to preserve SFP functionality as
far as possible or convenient, but if it has to go, then go it will. So far, that's seldom
been necessary, but is best practice before dropping someone else's hard drive into the
system.
Once it is appropriately muzzled, SFP is easy to live with in nearly all cases. However, SR is much more ambitious and potentially obtrusive, and depending on how you set up your PC, you may decide you'd rather be rid of it.
Just what is SR, anyway?
Although intended to protect non-tech users, it's conceptually difficult to explain to semi-tech users. It is not a system backup utility, although it can consume considerable disk space, and it does not backup your data at all. It's best to think of it as a system-level "undo" stack; a state backup that aims to let you fall back to "the way your PC was before". If you are used to the concepts of full and incremental backup (as discussed in the data management page), then you could think of SR as an historical incremental backup that works backwards from your current state, whereas the usual incremental backup works forward from a previous fully-backed-up state.
While the system is running, all changes that fall within the scope of SR are backed up in C:\_RESTORE, and every now and then, a "restore point" is made. It's important to note that there's hardly any overhead to making a restore point; the data it uses is already there, and all that happens is that a snapshot is made of the registry and a few other settings files. That's not to say SR doesn't impose an overhead on the system, but this is in two other situations; where the backup data is made (which is when the changes are made, which is when the system is in use) and when these loose backup file copies are compressed into .cab archives to save space (the process called "cabbing") that should happen when the system is idle.
The best way to use SR is immediately after trying something that didn't work, preferably falling back to a restore point you made just before trying whatever it was that didn't work (e.g. installing a new and invariably not uninstallable version of DirectX). The older the restore point you fall back to, the more likely you are to suffer collateral damage where changes you wanted to keep get undone as well.
You may have noted something more than my usual skepticism in what I've written about SR so far. Reasons:
Inflexibility of storage - SR has to store its backup data in C:\_RESTORE,and you cannot relocate this anywhere else. This is a big problem when you have a small C: that is supposed to be kept lean, clean and fast.
Uncertainty of scope - SR catches nearly everything outside the various "My" ghettos that are set aside for user data, and some user data locations that are embedded within the Windows subtree. But you are never that sure that all components of a change will be reversed by a System Restore.
Inflexibility of use - assuming you know what you are "restoring" back to (because you made an explicit restore point, instead of using an automatic one from an arbitrary time/date and wondering what it will do), you still have scant control over the process; you either splat everything back, or you don't. You can't preview your changes (although you can "undo" them), you can't edit the data, and you can't apply bits of the backed up data on a piecemeal basis. It seems a wasted opportunity to have all that space tied up in what should be more useful backup data, and not be able to get at it!
Single-application dependency - if SR won't use the data, you can't use it. Contrast this with, say, a backup made by InfoZip that can be accessed by anything that can read .zip archives, allowing the direct-vision convenience of WinZip or the "in case of fire break glass" survivability of InfoZip for DOS.
Fragility - SR will simply throw away your SR data for a number of reasons. Typically this will be anything that changes your enumeration of drive letters, but can be other triggers too. SR may also refuse to use the data even if it is still there, typically when there's something about the registry it doesn't like. Finally, if your hard drive was in another Windows Millennium system for any reason, that system will have splatted your \_RESTORE with a \_Restore of its own, containing nil but a single 1-byte file holding the drive letter the volume is supposed to be enumerated as (it is mismatches between these files and the actual letters allocated that triggers a flush of all SR backup data).
Flakiness - even when nominally disabled (with the attendant reboot that any change in SR status involves), SR can spontaneously re-enable itself, typically when drive letters change. The pattern may be quite distinctive; capacity slider is on maximum (which is the duh-fault) but the capacity figures are far lower than expected - e.g. instead of ranging from 200M to 500M, it may range from 25M to 50M instead. Even when it stays disabled, C:\_RESTORE can grow beyond the expected 2M or so, due the Wininit.exe processing of Wininit.ini files that appears to ignore SR status.
Missed drive changes - it's annoying that SR throws away its backup data whenever drive letters change, but understandable in that "restoring" data to the wrong volume would be Bad. Given that SR assumes this isn't a problem because it's checked the assigned drive letters against the values held in each volume's \_Restore, a rather nasty possibility suggests itself; what happens if a change in hard drives is missed, and SR proceeds on the assumption that all is well? This can happen quite easily, e.g. if you have a removable drive bracket that always has a hard drive with a single primary partition in it (thus always the same letter assignments), but that drive could be any one of several different ones you swap around. This is just another example as to why drive volumes should be identified rather than enumerated.
Malware risk - Inevitably, SR may include malware within the backed up data, but it also and hides this from detection in three ways: it changes the file name extensions, which may cause infected files to be overlooked; it hides infected files within .cab archives that scanners and Find may not penetrate, and it prevents all write-access from any process, including antivirus utilities. The suggested "cure" is to delete these infected files by "cycling SR" to flush all SR data.
In fact, the risk of malware re-infection is non-trivial, given this scenario:
Malware infects system
Antivirus "cleans" it, but files damaged or bad settings left behind
User attempts to fix the problem by doing a System Restore
User thinks system is clean, but now it it isn't anymore
If your antivirus was updated, and the new files fall within the scope of SR, then doing a System Restore may also revert your antivirus to outdated files. I'm told that most antivirus data files fall outside SR's scope, but as an example, an F-Prot for DOS engine update that replaces the .exe would be exposed to this risk.
So you have something that can impose more hassle on the system than a full system backup, is less useful than a full system backup, and in fact may fail when you need it. Technically proficient users will usually predict when their activities are likely to go wrong and will want to prepare a fallback route beforehand; if they rely on SR to fulfill this role, they may be more than annoyed when SR falls over instead. If you have to make an alternate plan in addition to SR, why bother with SR at all?
Certain patters of use are very likely to pose problems with SR:
Multiple hard drive volumes - if your strategies to maintain system performance include the use of a small C: volume that is set aside purely for the most often used code and temp/swap space, you won't be happy to have an enormous lump of "cold" data clogging up this volume. Every bad-exit ScanDisk will have to wade through it, and every defrag will have to shuffle it about as well. More significantly, all changes to monitored files on any other hard drive volume may now include a data copy operation from that volume to C:\_RESTORE. That's not just a matter of leaving the data clusters chained as they were and copying over the directory pointer, as happens when preserving files in a \Recycled on the same volume; that's a head-thrashing nightmare.
Bulk file operations of monitored file types - as above, especially if combined with above
Data recovery - because *statemgr creates a \_Restore on every hard drive volume it sees, any sick hard drive or file system will be at risk from these writes. Unlike most other objectionable aspects of SR, this one requires deactivation of SFP as well, as a side-effect of removing *statemgr from the startup axis.
Drop-in hard drives - as changing hard drive letter enumeration is likely to cause SR to spontaneously re-enable, you may find you have to reboot twice after each time you add or remove extra hard drives; the second time following disabling SR (again).
If you fall into the first two categories, you may want to disable SR. If you fall into the last two categories, you may prefer to rip *statemgr out of the startup axis as well, even if that means SFP dies too.
Right-click on the "My Computer" object and choose Properties, or go Start, Settings, Control Panel, System. From there, click the Performance tab, File System button, and then the Troubleshooting tab in the dialog that appears. There, you finally come upon the checkbox to disable System Restore; check that box, OK, and then restart when you are prompted to do so.
Not exactly the most obvious UI, but there's worse; if you don't restart when prompted, or if you apply the same change to the registry via the appropriate .reg import and don't restart when not prompted, then your intended setting is thrown away, and SR just keeps on truckin' as Microsoft intended.
You may also hear of "cycling System Restore". This is basically the process of disabling SR, restarting when commanded to do so, then re-enabling it again, and is often suggested as a way of clearing the SR data that has built up in C:\_RESTORE. However, you can also just delete that data from DOS mode; in my experience (including testing with a provocative Wininit.ini file), the subtree is recreated on the fly as required.
Bottom line
My standard build practice is to disable SR, but
leave *statemgr active in the startup axis. I do this mainly
because I also use multiple hard disk volumes with a small and hopefully fast C: on the
systems that I build. With a left-as-MS-default installation on one big C: drive, your
mileage may vary; faced with a choice between no technical backup and SR, SR makes more
sense.
(C) Chris Quirke, all rights reserved - September 2001