Windows file protection windows xp

Summary

This article describes the Windows File Protection (WFP) feature.

More Information

Windows File Protection (WFP) prevents programs from replacing critical Windows system files. Programs must not overwrite these files because they are used by the operating system and by other programs. Protecting these files prevents problems with programs and the operating system.

WFP protects critical system files that are installed as part of Windows (for example, files with a .dll, .exe, .ocx, and .sys extension and some True Type fonts). WFP uses the file signatures and catalog files that are generated by code signing to verify if protected system files are the correct Microsoft versions. Replacement of protected system files is supported only through the following mechanisms:

• Windows Service Pack installation using Update.exe

• Hotfixes installed using Hotfix.exe or Update.exe

• Operating system upgrades using Winnt32.exe

• Windows Update

If a program uses a different method to replace protected files, WFP restores the original files. The Windows Installer adheres to WFP when installing critical system files and calls WFP with a request to install or replace the protected file instead of trying to install or replace a protected file itself.

How the WFP feature works

The WFP feature provides protection for system files using two mechanisms. The first mechanism runs in the background. This protection is triggered after WFP receives a directory change notification for a file in a protected directory. After WFP receives this notification, WFP determines which file was changed. If the file is protected, WFP looks up the file signature in a catalog file to determine if the new file is the correct version. If the file is not the correct version, WFP replaces the new file with the file from the cache folder (if it is in the cache folder) or from the installation source. WFP searches for the correct file in the following locations, in this order:

1. The cache folder (by default, %systemroot%\system32\dllcache).

2. The network install path, if the system was installed using network install.

3. The Windows CD-ROM, if the system was installed from CD-ROM.

If WFP finds the file in the cache folder or if the installation source is automatically located, WFP silently replaces the file and logs an event that resembles the following in the System log:

Event ID: 64001

Source: Windows File Protection

Description: File replacement was attempted on the protected system file c:\winnt\system32\ file_name . This file was restored to the original version to maintain system stability. The file version of the system file is x.x:x.x.

If WFP cannot automatically find the file in any of these locations, you receive one of the following messages, where file_name is the name of the file that was replaced and product is the Windows product you are using:

• Windows File Protection
  Files that are required for Windows to run properly have been replaced by unrecognized versions. To maintain system stability, Windows must restore the original versions of these files. Insert your
  product CD-ROM now.

• Windows File Protection
  Files that are required for Windows to run properly have been replaced by unrecognized versions. To maintain system stability, Windows must restore the original versions of these files. The network location from which these files should be copied, \\server\share, is not available. Contact your system administrator or insert
  product CD-ROM now.

Note If an administrator is not logged on, WFP cannot display either of these dialog boxes. In this situation, WFP displays the dialog box after an administrator logs on. WFP may wait for an administrator to log on in the following scenarios:

• The SFCShowProgress registry entry is missing or is set to 1, and the server is set to scan every time that the computer starts. In this situation, WFP waits for a console logon. Therefore, the RPC server does not start until the scan is performed. The computer has no protection during this time.

  Note You can still map network drives, use system files, and use Terminal Services to log on to the server. WFP does not consider these operations as a console logon, and keeps waiting indefinitely.

• WFP has to restore a file from a network share. This situation may occur if the file is not present in the Dllcache folder or if the file is corrupted. In this situation, WFP may not have the correct credentials to access the share from the network-based installation media.

The second protection mechanism that is provided by the WFP feature is the System File Checker (Sfc.exe) tool. At the end of GUI-mode Setup, the System File Checker tool scans all the protected files to make sure that they are not modified by programs that were installed by using an unattended installation. The System File Checker tool also checks all the catalog files that are used to track correct file versions. If any of the catalog files are missing or damaged, WFP renames the affected catalog file and retrieves a cached version of that file from the cache folder. If a cached copy of the catalog file is not available in the cache folder, the WFP feature requests the appropriate media to retrieve a new copy of the catalog file.

The System File Checker tool gives an administrator the ability to scan all the protected files to verify their versions. The System File Checker tool also checks and repopulates the cache folder (by default, %SystemRoot%\System32\Dllcache). If the cache folder becomes damaged or unusable, you can use either the sfc /scanonce command or the sfc /scanboot command at a command prompt to repair the contents of the folder.

The SfcScan value in the following registry key has three possible settings:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon The settings for the SfcScan value are:

• 0x0 = do not scan protected files after restart. (Default value)

• 0x1 = scan all protected files after every restart (set if sfc /scanboot is run).

• 0x2 = scan all protected files one time after a restart (set if sfc /scanonce is run).

By default, all system files are cached in the cache folder, and the default size of the cache is 400 MB. Because of disk space considerations, it may not be desirable to maintain cached versions of all system files in the cache folder. To change the size of the cache, change the setting of the SFCQuota value in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon WFP stores verified file versions in the Dllcache folder on the hard disk. The number of cached files is determined by the setting of the SFCQuota value (the default size is 0xFFFFFFFF, or 400 MB). The administrator can make the setting for the SFCQuota value as large or small as needed. Note that if you set the SFCQuota value to 0xFFFFFFFF, the WFP feature caches all protected system files (approximately 2,700 files).

There are two cases in which the cache folder may not contain copies of all protected files, regardless of the SFCQuota value:

1. Not enough disk space.

   Under Windows XP, WFP stops populating the Dllcache folder when less than (600 MB + maximum size of the page file) of space is available on the hard disk.
   Under Windows 2000, WFP stops populating the Dllcache folder when less than 600 MB of space is available on the hard disk.

2. Network Install.

   When Windows 2000 or Windows XP is installed over the network, files in the i386\lang directory are not populated in the Dllcache folder.

Additionally, all drivers in the Driver.cab file are protected, but they are not populated in the Dllcache folder. WFP can restore these files from the Driver.cab file directly without prompting the user for the source media. However, running the sfc /scannow command does populate the files from the Driver.cab file into the Dllcache folder.

If WFP detects a file change and the affected file is not in the cache folder, WFP examines the version of the changed file that the operating system is currently using. If the file that is currently in use is the correct version, WFP copies that version of the file to the cache folder. If the file that is currently in use is not the correct version, or if the file is not cached in the cache folder, WFP tries to locate the installation source. If WFP cannot find the installation source, WFP prompts an administrator to insert the appropriate media to replace the file or the cached file version.

The SFCDllCacheDir value (REG_EXPAND_SZ) in the following registry key specifies the location of the Dllcache folder.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon The default value data for the SFCDllCacheDir value is %SystemRoot%\System32. The SFCDllCacheDir value can be a local path. By default, the SFCDllCacheDir value is not listed in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. To modify the cache location, you must add this value.

When Windows starts up, WFP synchronizes (copies) the WFP settings from the following registry key

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protectionto the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinlogonTherefore, if the SfcScan, SFCQuota, or SFCDllCacheDir values are present in the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protection subkey, the values take precedence over the same values in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon subkey.

For more information about the WFP feature, click the following article number to view the article in the Microsoft Knowledge Base:

222473 Registry settings for Windows File Protection

For more information about the System File Checker tool in Windows XP and Windows Server 2003, click the following article number to view the article in the Microsoft Knowledge Base:

310747 Description of Windows XP and Windows Server 2003 System File Checker (Sfc.exe)

For more information about the System File Checker tool in Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base:

222471 Description of the Windows 2000 System File Checker (Sfc.exe)

For more information about the WFP feature, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/aa382551.aspx For more information about Windows Installer and WFP, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/aa372820.aspx

It cannot be done as silently as you were probably hoping for, mainly because of the debugger requirement:

You may disable WFP by setting the value SFCDisable (REG_DWORD) in
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\
Winlogon. By default, SFCDisable is set to 0, which means WFP is
active. Setting SFCDisable to 1 will disable WFP. Setting SFCDisable
to 2 will disable WFP for the next system restart only (without a
prompt to re-enable).

Important: You must have a kernel debugger attached to the system via
null modem cable (for example:I386kd.exe or Windbg.exe) to use
SFCDisable = 1 or SFCDisable = 2.

After WFP is disabled using the SFCDisable = 1 setting, the following
message will appear after logon:

Warning! Windows File Protection is not active on this system. Would
you like to enable Windows File Protection now? This will enable
Windows File Protection until the next system restart. .

Clicking Yes will reactivate WFP until the next system restart. This
message will appear at every successful logon until SFCDisable is set
to 0.

See here.

Have you considered using devcon or, better yet, pnputil to load your driver from the command line?

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

Windows File Protection (WFP), a sub-system included in Microsoft Windows operating systems of the Windows 2000 and Windows XP era, aims to prevent programs from replacing critical Windows system files. Protecting core system files mitigates problems such as DLL hell with programs and the operating system. Windows 2000, Windows XP and Windows Server 2003 include WFP under the name of Windows File Protection; Windows Me includes it as System File Protection (SFP).

Operation

Edit

With Windows File Protection active, replacing or deleting a system file that has no file lock to prevent it getting overwritten causes Windows immediately and silently to restore the original copy of the file. The original version of the file is restored from a cached folder which contains backup copies of these files. The Windows NT family uses the cached folder %SystemRoot%\System32\Dllcache. Windows Me caches its entire set of compressed cabinet setup files and stores them in the %windir%\Options\Install folder.

WFP covers all files which the operating system installs (such as DLL, EXE, SYS, OCX etc.), protecting them from deletion or from replacement by older versions. The digital signatures of these files are checked using code signing and the signature catalog files stored in the %SystemRoot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} folder. Only certain operating system components such as the Package Installer (Update.exe) or Windows Installer (Msiexec.exe) can replace these files. Changes made using any other methods in order to replace these files are reverted and the files are silently restored from the cache. If Windows File Protection cannot automatically find the file in the cached folder, it searches the network path or prompts the user for the Windows installation disc to restore the appropriate version of the file.

WFP integrates with the System File Checker (sfc.exe) utility.

Windows Vista and later Windows systems do not include Windows File Protection, but they include Windows Resource Protection which protects files using ACLs. Windows Resource Protection aims to protect core registry keys and values and prevent potentially damaging system configuration changes, besides operating system files.

The non-use of ACLs in Windows File Protection was a design choice: Not only did it allow operation on non-NTFS systems, but it prevented those same «bad» installers from failing completely from a file access error.

External links

Edit

• Overview of Windows File Protection
• Registry settings for Windows File Protection
• Whitepaper on Windows File Protection
• Overview of System File Protection (Windows Me)
• Hacking Windows File Protection
• Effective Files Protection Tool

When setting up the Windows XP operating system, sometimes it becomes necessary to replace some system files. But the file cannot be replaced because the system does not allow it or restores the replaced file with the original copy. However, this limitation can be circumvented.

Instructions

Step 1

Protecting system files from replacement or modification is an important factor in protecting the operating system from the effects of viruses and Trojans. Therefore, it is not recommended to disable protection of system files unless absolutely necessary.

Step 2

Since Windows hides protected system files, you must first make them visible. To do this, open any disk or folder, select from the menu: «Tools» — «Folder Options» — «View». Remove the checkboxes from the lines «Hide protected system files» and «Hide extensions for registered file types.» Check the box «Show hidden files and folders». Click Apply to All Folders, then OK.

Step 3

Now you can see all files and their extensions. If you need to replace a single file, the easiest way to do this is by booting through a different operating system or LiveCD. Before changing, do not forget to create a restore point: «Start» — «All Programs» — «Accessories» — System Tools — «System Restore». Save the file to be replaced in a separate folder.

Step 4

If the system does not boot after changing the file, return the original file in the same way. Alternatively, press F8 while booting and select Load Last Known Good Configuration. This does not work either — try to select the «Boot in Safe Mode» item in the same menu. Then, after booting the OS, select System Restore.

Step 5

If you still want to disable the protection of system files, open the registry editor: «Start» — «Run», the regedit command. Find the path: HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows NT CurrentVersion Winlogon. Select the Winlogon folder, find the SFCDisable parameter in the window on the right. Click it with the right mouse button, select «Change». In the window that opens, replace 0 with ffffff9d. After a reboot, the system file protection will be disabled.

Step 6

Don’t leave system files unprotected. After you configure the system in the way you want, reopen this parameter and again restore its original value. Remember to restart your computer for the changes to take effect.