XP File Protection: What you need to know

When you install an application only to have it crash Windows, there's a good chance the crash occurred because the application overwrote critical Windows system files. The results are unpredictable any time that system files are overwritten. The system may run fine with the modified files, or the system may operate erratically or fail completely. Fortunately, Windows 2000, XP, and Server 2003 use a mechanism called Windows File Protection (WFP) to prevent critical system files from being overwritten. In this article, I'll explain what WFP is and how it works. I'll go on to show you how to modify or override WFP's behavior. (Note: Although WFP works almost identically on Windows 2000, XP, and Server 2003, this article's information, including the registry entries and SFC syntax, was written specifically for XP.)

How Windows File Protection works
WFP is designed to protect the contents of the Windows folder. Rather than preventing any modifications to the entire folder, WFP protects specific file types, such as SYS, EXE, DLL, OCX, FON, and TTF. Registry entries control the file types that WFP protects.
When an application attempts to replace a protected file, WFP checks the replacement file's digital signature to see if Microsoft signed the file and to see if the file is the correct version. If both of these conditions check out, then the replacement is allowed. Normally, the only types of files that are allowed to replace system files are those included with Windows service packs, hot fixes, and operating system upgrades. System files can also be replaced by Windows Update or by the Windows Device Manager/Class Installer.
If the two conditions are not met, the protected file will be replaced by the new file, but will soon be overwritten by the correct version. When this happens, Windows pulls the correct version of the file either from the Windows installation CD or from the computer's DLLCache folder.
Windows File Protection doesn't just protect files against modification--it also protects them against deletion. To see WFP in action, navigate to the \WINDOWS\SYSTEM32 folder and rename the CALC.EXE file to CALC.OLD. When you do, you'll see a message indicating that changing the file's extension may make the file unusable. Acknowledge the warning by clicking the Yes button. Now, wait a few minutes and press the F5 key to refresh your view of the file system. It can take some time for the replacement to be made. When the file is eventually replaced, Windows will let you know by making an entry into the Event Logs.
An interesting side note about WFP is that it actually works closely with the Windows installer program. Any time that the Windows Installer needs to install a protected file, it hands the file off to WFP rather than attempting to install the file itself. WFP then makes the judgment call as to whether to allow the installation.
System File Checker
While automatic file replacement does save time, there are situations that may require manual intervention. For example, you may not want to wait around for WFP to detect that a protected file has been replaced. Fortunately, there is a tool called the System File Checker (SFC) that you can use to manually control WFP.
SFC is a command line tool that should be run from the Command Prompt window. The syntax looks like this:
SFC [/SCANNOW] [/SCANONCE] [/SCANBOOT] [/REVERT] [/PURGECACHE] [/CACHESIZE=x]
The /SCANNOW switch tells SFC to scan all protected files right now. If an incorrect file version is detected during the scanning process, the incorrect version will be reverted back to the official Microsoft version. Of course, this may sometimes mean that you must have the Windows installation CD or the latest service pack or hot fix available.
The /SCANONCE parameter tells WFP to scan the protected system files the next time that the machine is booted. During the scan, any incorrect files will be replaced with the proper versions. As the parameter's name implies, this type of scan will only happen once. Subsequent system boots will occur normally without SFC running.
The /SCANBOOT parameter is similar to the /SCANONCE option. The difference is that while SCANONCE scans the protected files the next time that Windows boots, the SCANBOOT parameter scans the system files every time that Windows boots. Both of these commands replace incorrect system files as necessary and may require you to provide copies of the correct file versions.

The /REVERT switch is used to turn off SFC. For example, suppose that you used the SCANBOOT option to scan all protected files every time that the system boots. As you can imagine, this would really increase the amount of time that it takes the computer to boot up. Eventually, you may get tired of these long boot times and want to disable the SFC. To do so, you'd simply use the SFC /REVERT command, which will prevent SFC from running at boot up.

The /PURGECACHE switch is one to be careful with. Earlier I explained that Windows uses a cache folder to store backup copies of the correct version of the various system files. If you run the SFC /PURGECACHE command, though, the cache will be emptied and the backup files will be erased. This command will also cause Windows to start scanning the various protected files and will rebuild the cache while doing so. Of course, this may mean that you'll have to provide Windows with the Windows installation media or copies of updated system files.

The last SFC command switch is the /CACHESIZE=x switch. There is actually a lot of contradictory information about the default cache size. While researching this article, I found three different Microsoft Knowledgebase articles that specified three different default cache sizes. One article suggested that the default cache size was 50 MB, while another suggested that the size was 300 MB. Still another indicated that the size was unlimited. The default size doesn't really matter, though, because you can use the CACHESIZE switch to change the size of the cache to meet your needs.

To use the CACHESIZE switch, you must enter the command SFC /CACHESIZE=x, where x is the desired number of megabytes that you want to dedicate to the cache. After specifying the new cache size, you must reboot the system and then run the SFC /PURGECACHE command.

Controlling WFP and SFC through the registry
Earlier, I explained that the registry controlled the general behavior of WFP. There are several different registry keys that you can modify in order to control the behavior of WFP. Some of these keys are directly manipulated every time you run SFC. Others have lower-level functions, such as specifying the location of the file cache or of the installation files.

Modifying the registry can be dangerous. If you make an incorrect modification, it can destroy Windows and/or your applications. Therefore, I strongly recommend creating a full backup before attempting any of the techniques outlined in this section.

To access the SFC registry keys, enter the REGEDIT command at the Run prompt. This will open the Registry Editor. Now, navigate through the registry tree to this key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon

Normally, the WinLogon portion of the registry is used to control various boot options. Since many of the SFC options control whether SFC is run on boot up, however, Microsoft has placed the SFC-related registry keys in this location.

SFCDisabled
This registry key controls whether SFC is enabled or disabled. There are actually four different options that you can set just by changing the DWORD value. The default DWORD value is 0. This setting enables SFC. Normally you won't want to change this value. However, you can change the value from 0 to 4 to leave SFC enabled but to disable the popups.

You may only disable SFC if you have a kernel debugger hooked up. If you are using a kernel debugger, you can change the registry key's DWORD value to 1, which will disable SFC and then prompt you on all subsequent boots as to whether you want to reenable it.

You can also disable SFC by changing the DWORD value to 2. This option disables SFC at the next boot only. There is no option to reenable SFC, because SFC will automatically be reenabled on the following boot.

SFCScan
Earlier, I showed you the SCANONCE, SCANBOOT, and REVERT options for the SFC. Any time that you use any of these options, SFC is actually modifying the SFCScan registry key. You can modify this key by changing its assigned DWORD value.

The default value is 0. This value indicates that protected files should not be scanned at boot up. This setting is equivalent to running the SFC /REVERT command.

Changing the assigned DWORD value to 1 indicates that protected files should be scanned on every boot. Setting the SFCScan value to 1 is equivalent to running the SFC /SCANBOOT command.

Finally, setting the DWORD value to 2 tells SFC to scan the protected files on the next boot, but not on subsequent boots. This is the equivalent to running the SFC /SCANONCE command.

SFCQuota
The SFCQuota registry key is used to control the SFC cache size. As you may recall, earlier when I talked about the SFC /CACHESIZE=x command, I indicated that there was a lot of inconsistent information regarding the default cache size. On my system though, the DWORD value assigned to the SFCQuota registry key was 0xffffffff. According to the Microsoft Knowledge Base, this translates into a 300-MB cache size. The same knowledgebase article indicates that you can cache all protected system files by changing this value to FFFFFFFF.

SFCDllCacheDir
Earlier, I explained that Windows uses the DLLCACHE folder as the location for storing cached copies of system files. Normally, this folder exists in the \WINDOWS\SYSTEM32 folder. However, by modifying the SFCDllCacheDir registry key, you can actually control the cache location.

Cached files will always be placed in the DLLCACHE folder, but by using this registry key, you can control the folder's location. The only catch is that you must specify a location that exists on a local hard drive. In Windows 2000, you could specify a network share as the DLLCACHE location, but this option does not exist in Windows XP.

SFCShowProgress
Yet another registry key related to SFC is the SFCShowProgress key. This registry key allows you to set its DWORD value to either 0 or 1. The default value is 0, which disables the SFC progress bar. Setting the value to 1 causes SFC to display the progress bar.

Source File Location
Earlier, when I was explaining how WFP and SFC worked, I indicated several times that you may have to supply the Windows installation media or copies of valid source files under some conditions. By modifying the registry though, it is actually possible to point Windows to a set of source files rather than having Windows ask you for those files.

This registry key is found in a different part of the registry. To access it you must go to this key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup

Once you arrive at this location, you can specify the location of the Windows system files by using either a drive letter and path or a UNC.

The only real gotcha associated with using this command is that you must place the files within a folder called I386. For example, if your Windows system files were in a folder named C:\I386, then you would only specify the C:\ portion of the path within the registry because Windows assumes that the I386 folder will exist. Likewise, if you were to use a UNC share, the I386 folder must exist beneath the share point. For example, if you were to share a folder called FILES, you would want to place the I386 folder inside of the FILES folder. You could then tell Windows to look at \\server_name\FILES for the shared files. Windows would then look for the system files within \\server_name\FILES\I386.

Additional reading
For more information on Windows File Protection and System File Checker, check out these Microsoft Knowledge Base and Microsoft Developer Network articles:

• Description of the Windows 2000 System File Checker (Sfc.exe): 22471
• Description of Windows XP and Windows Server 2003 System File Checker (Sfc.exe): 310747
• Description of the Windows File Protection Feature: 222193
• Registry Settings for Windows File Protection: 222473
• Microsoft Platform SDK: Windows File Protection
• Microsoft Platform SDK: Windows Installer—Windows File Protection on Windows 2000 and Windows XP