When you install an application and unexpectedly cause Windows to crash, it is most likely because the application has rewritten the key Windows system files, causing the system to crash. After the file is modified, the results are often unpredictable. The system may be functioning properly, with some errors, or a complete crash. Fortunately, Windows 2000, XP, and Server 2003 use a mechanism called Windows File Protection (WFP) that prevents critical system files from being overwritten. In this article, I will explain what WFP does and how it works. (Note: Although there is no difference in the operation of WFP on Windows 2000, XP, and Server 2003, the information in this article, including registry related entries and SFC syntax, is for XP.)
How Windows File Protection Works
WFP is designed to protect the contents of Windows folders. WFP protects specific file types, such as SYS, EXE, DLL, OCX, FON, and TTF, rather than blocking any modifications to the entire folder. The registry key determines the file type protected by WFP.
When an application attempts to replace a protected file, WFP checks the digital signature of the replacement file to determine if the file is from Microsoft and is the correct version. If both of these conditions are met, then replacement is allowed. Under normal circumstances, the types of files that are allowed to replace system files include Windows service packs, patches, and operating system upgrades. System files can also be replaced by Windows Updater or Windows Device Manager/Class Installer.
If these two conditions are not met at the same time, the protected file will be replaced by the new file, but will soon be replaced by the correct file. When this happens, Windows will copy the correct version of the file from the Windows installation CD or from the DLLCache folder on your computer.
Windows File Protection is not just to protect files by refusing to modify, it can refuse to remove. Take a look at WFP's approach, open the \\WINDOWS\\SYSTEM32 folder and rename the CALC.EXE file to CALC.OLD. When you do this, a message will prompt you if changing the extension of this file may cause this file to be unavailable. Click the Yes button to confirm this warning. Now, wait a few minutes and press F5 to refresh the view of the file system. It may take some time to complete the replacement. When the file is eventually replaced, Windows will make a corresponding record in the event log.
on WFP noteworthy point is very close and it is a combination of Windows Installer. Whenever the Windows installer needs to install a protected file, it will hand it over to WFP instead of trying to install it. Then WFP determines if the installation is allowed.
System File Check
Although automatic file replacement saves time, there are situations where manual intervention is required. For example, you may not want to wait for WFP to determine if a protected file has been replaced. Fortunately, you can manually control WFP with a tool called System File Check (SFC).
SFC is a command-line tool, you need to run at the command prompt window. Its syntax is like this:
SFC [/SCANNOW] [/SCANONCE] [/SCANBOOT] [/REVERT] [/PURGECACHE] [/CACHESIZE=x]
/SCANNOW option to notify SFC Scan all protected system files immediately. If an incorrect file version is found during the scan, this wrong version will be replaced with the correct version of Microsoft. Of course, this means you may have to have a Windows installation CD, the latest service pack or an upgrade patch.
The /SCANONCE parameter tells WFP to scan the protected system files the next time the system boots. Any wrong files will be replaced by the correct version during the scan. As the name of this parameter means, this scan is only done once. After the system startup will return to normal, the SFC will no longer run.
The /SCANBOOT parameter is similar to the /SCANONCE option. The difference is that SCANONCE scans protected files only when Windows starts next time, while the SCANBOOT parameter scans system files every time Windows starts. These two parameters will replace the wrong system file if needed, which may require you to provide a copy of the correct file version.
The /REVERT option is used to turn off the SFC. For example, suppose you use the SCANBOOT option to scan the protected files each time the system boots. As you can imagine, this does increase the total time the computer starts up. Finally, you may be tired of the long startup time and want to turn off SFC. Simply use SFC /REVERT to shut down the SFC at startup.
The /PURGECACHE option needs to be cautious. Before that, I explained that Windows uses a cache folder to hold backups of the correct versions of various system files. If you run the SFC /PURGECACHE command, then this file cache will be emptied and those backup files will be deleted. This command will also cause Windows to start scanning various protected files and rebuild the file cache while scanning. Of course, this may mean that you must provide Windows with a copy of the Windows installation CD or system file upgrade.
The last SFC command option is /CACHESIZE=x. There are a lot of contradictory information about the default size of the file cache. At the time of this writing, I found that the default size of the file cache specified in the three different Microsoft Knowledge Base articles is different. In one article, the recommended file cache size is 50 MB, while the other recommended size is 300 MB. What's more, the third article points out that this size should be infinite. In fact, the size of the default value is not important, because you can use the CACHESIZE option to change the size of this file cache according to your needs.
When using the CACHESIZE option, you must type the command SFC /CACHESIZE=x, which is the number of megabytes you want to allocate to the file cache. After specifying the new file cache size, you must reboot the system and run the SFC /PURGECACHE command.