A System File Checker Bug The System File Checker (SFC) utility is part of the Windows File Protection (WFP) feature in Windows XP and Windows 2000. WFP ensures that Microsoft and third-party software installations don't overwrite core components of the OS, including boot files, kernel files, and drivers. WFP tracks file-replacement activity for protected system files, primarily those in the \%systemroot%\system32\dllcache folder. On Win2K Server platforms, WFP monitors files with a .sys, .dll, .exe, .ttf, .fon, and .ocx file type. On XP systems and Win2K Professional systems, WFP monitors a subset of these system files. When an application attempts to overwrite a file that appears in the protected files folder, you typically see a pop-up message saying that “a file replacement was attempted on a protected system file …” and that WFP prevented the file replacement from taking place. WFP also records such activities with messages in the event log.

Situations exist in which you might want to run SFC to verify that the OS contains only the most current versions of crucial files (e.g., when writing and testing new drivers, when your system misbehaves at the dll or driver level). SFC lets you scan protected system files immediately, during the next reboot, or at every system restart. If files in the dllcache folder become corrupted, you can use SFC to clear and rebuild the contents of the protected file cache. SFC accepts the following command-line arguments:

- /scannow--scan protected system files immediately
- /scanonce--scan protected system files once at the next boot
- /scanboot--scan protected system files at every restart
- /cancel--cancel all pending scans
- /quiet--replace all incorrect file versions without prompting the user
- /enable--enable WFP
- /purgecache--purge and rebuild the dllcache folder
- /cachesize=x--sets the file cache size in bytes (reboot to activate)

Before you experiment with this utility, you need to know about an SFC bug that can potentially corrupt a system. According to the Microsoft article "The SFC /SCANNOW Command May Overwrite Hotfix Files" (http://support.microsoft.com/?kbid=814510), Microsoft packages patches, hotfixes, and security updates in a way that's incompatible with the SFC utility. (The article states that this problem is specific to Win2K Service Pack 3--SP3--and earlier versions; unless Microsoft packages security hotfixes for XP differently than it packages them for Win2K, this problem likely also applies to XP platforms.) If you run SFC /scannow on a system on which you've previously installed code fixes or security hotfixes, SFC can potentially overwrite the more recent hotfix version of a file in the dllcache folder with the version from the previous service pack. This incompatibility results from the fact that standalone updates and security fixes don't register the version number of each component in the location that SFC checks.

During a /scannow operation, SFC rebuilds the dllcache folder with files that contain the most recent registered version number. Because security fixes don't register the version number of each component in the same location that service packs use, SFC’s rebuilt list might contain a version (i.e., the version from the most recently installed service pack) that's several versions older than the currently loaded file. Thus, you end up with an old version in the dllcache folder and the current version in the \%systemroot%\system32 folder. When SFC rebuilds the files in the dllcache folder, it doesn't physically replace the binary image in the running OS, so it doesn't affect the running system. Likewise, SFC doesn't replace the correct version with the older version during a system restart. However, if the file in question ever becomes corrupt, SFC will replace the version in the %systemroot% folder with the version in the %dllcache% folder, with potentially nasty results. Microsoft says that Win2K SP4 will resolve this inconsistency. In the meantime, if you use or have used SFC with the /scannow option, you can avoid this potential conflict of binaries by reinstalling all code fixes and security hotfixes.