 |
System File ProtectionThomas LeeThis article was first
published in Back Office Magazine in October 1999
|
||||
| DLL
Hell
|
In this month’s Technical Windows 2000 column, I am going to take a look at a new feature included with Windows 2000 called System File Protection (or SFP) SFP is designed to protect system files and I’ll discuss why you want your system files to be protected (as if you don’t already know!), how SFP works and how you can make use of it. I will also discuss how you can disable it. DLL HellOne of the great design approaches Microsoft took with Windows was the use of dynamic link libraries (DLLs). A DLL is a library file that is dynamically loaded at run time (i.e. when you load a program). DLLs typically hold useful library routines used by one or more applications. The advantage of the DLL approach is two fold. First if errors are found in the DLL, then an updated DLL can be issued to solve the problem. This approach is much easier than having to re-issue an entire application. Secondly, DLLs can be shared between multiple applications. With statically linked program libraries, the library routines are never shared, which can be wasteful of memory. Overall, the DLL architecture was a great idea and in most cases still works well today. However, the DLL architecture also presents a major problem. What happens when you install a new application, and the application installation program loads a new version of some shared DLL and which now works just slightly differently than the original DLL? The result can be odd application errors, Dr Watson failures, or in extreme cases, system crashes. In some cases, the application will work, but other applications, which have worked fine up until now, suddenly start to fail. If you load enough applications eventually you may end up in DLL Hell! The bad news is that it’s often very difficult to find the specific DLL that is the cause of the problem. In researching this article, I found a couple of good examples of DLL hell: one on BugNet (http://207.158.205.117/alerts/bugalert_32299.html) and another article http://www.infoworld.com/cgi-bin/displayNew.pl?/livingst/980112bl.htm written by Brian Livingston. While the specific problems raised in both of these examples have been resolved, the problem they highlight is all too common. So why does DLL hell exist? In general, the problem occurs when you install an application – and this can include Microsoft as well as 3rd party applications. When the application you are installing needs a particular DLL, the installation procedure needs to ensure that the DLL will be present on the computer. Well written installation programs will check and ensure the right DLL is on your system. Sadly, some don’t – and instead adopt the approach “we need this DLL and we know how to put it on your computer”. In many cases, this will work just fine, but all too often problems exist as the web pages noted above point out all too clearly. This problem has existed almost since Windows was first released although with Windows 95 and Windows 98, the issues have been exacerbated. The latest beta of Windows 2000 Professional contains over 1400 files with the .DLL extension and on a Windows 2000 Domain Controller in my office, there are nearly 1800 DLLs. With such vast numbers of DLLs, there needs to be a better way to protect key system files. System File ProtectionSystem File Protection is a Windows 2000 facility that detects changes to key system files and can take appropriate action when such changes occur. SFP runs in the background, and registers to receive directory change notification for changes made to protected directories. When SFP detects that a directory change event has occurred, it will check to see if a protected file has been deleted or overwritten. It checks by comparing the signature of the file with that in a catalog to determine if the file is the correct Microsoft version. If an incorrect version is loaded or if a protected system file is deleted, SFP will simply replace the file with a copy from the protected system file cache (or from distribution media if a copy of the file is not in the DLL cache). Windows 2000 will protect all SYS, DLL EXE, TTF, FON and OCX files included on the Windows 2000 installation media. To demonstrate this feature in action, I opened a console window and attempted to rename NOTEPAD.EXE as NOTEPAD1.EXE, as shown in Figure 1.
Figure 1 - Attempting to rename NOTEPAD.EXE As soon as the rename operation was performed, Windows 2000 recognized that a protected file (i.e. NOTEPAD.EXE) had been changed and immediately reinstated this file with a copy from the DLL cache. This is also supposed accompanied by a pop-up message dialog. To assist administrators in tracking file changes, SFP also generates an Event Log Error, which is shown in Figure 2.
Figure 2 - SFP Even Log Entry Changing SFP DetailsThe operation of SFP is controlled by Registry value entries held in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. By default only Administrators or the system account can modify the registry entries, which should stop most end-users from changing these entries. The DLL cache is held, by default, in the folder %systemtoot%\system32\dllcache. This folder is super hidden (i.e. it has the System and Hidden attributes set) so by default it will not show up in Explorer. On NTFS volumes, the DLLCache folder is compressed, thus reducing the size of the folder by between 30 and 40 percent. On a new installation of Windows 2000 Professional for my laptop, the size on disk is around 30 MB, while on my desktop, which is running Advanced Server, the cache size on disk is over 190 megabytes! While on large servers, this may be acceptable, on desktop computers this use of space may be undesirable, particularly on computers running Windows 2000 Professional. The maximum cache size is held in registry in the SFCQuota value entry (REG_DWORD). By default this is set to 0x32 (50) for Professional (limiting the cache size to 50 megabytes) and 0xFFFFFF for Windows 2000 servers (i.e. no upper limit on cache size). You can also change where the DLLCache folder is stored by adding the value SFPGDllCacheDir (REG_EXPAND_SZ). You can specify either a local folder (the default is %systemroot%\system32) or a network folder. For corporate customers, using a network folder will be the ideal solution. Installing UpdatesSo what happens when you want to update Windows 2000? For example, you might need to apply a hot fix or to install a new device driver. The SFP process is designed to enable certain trusted and well know update mechanisms to work. These include:- · Windows 2000 Service Packs, installed with UPDATE.EXE · Hotfix distributions, installed by HOTFIX.EXE · Operating system upgrades, installed by WINNT32.EXE · Updates installed by Windows update (http://windowsupdate.microsoft.com). Each of these mechanisms will enable you to update protected system files without invoking system file protection. System File CheckerAssociated with the SFP facility is the System File Checker (SFC.EXE). SFC.EXE enables the administrator to scan all protected files to verify their versions and to check and repopulate the DLLCACHE folder. This would be useful if, for some reason, the DLLCACHE folder was deleted, or was for some reason corrupted. Disabling SFPBut what if you just want to turn it off? There are two methods to disable System File Protection – one is temporary, while the other is more permanent. To temporarily disable SFP, just boot into Safe Mode. In Safe Mode, System File Protection is disabled. This would allow you to manually replace a DLL or other protected system file, should the need arise. Alternatively, you can modify the SFPDisable registry value (held in the same key as noted above). This registry value entry (a REG_DWORD) can have the following values: - · 0 – SFP enabled, popups will occur when SFP is invoked · 1 – Disabled, but a prompt will be given the next time the system reboots asking whether to re- enable it · 2 – Disabled at next boot only and with no prompt to re-enable · 3 – Not Documented · 4 – Enabled, but with pop-ups disabled The default values are 0 for Windows 2000 Professional and 4 for the Windows 2000 Server versions. You will, however, need to reboot your machine before a change of this value entry will be effective. Forcing a Bug CheckMost of the time, you will just want to let System File Protection do its thing, replacing files in cases where they are incorrectly over written. However, on some systems, particularly servers, you may want to be a bit more cautious. This is especially important on publicly available servers, for example a web server on the Internet. These boxes should be very tightly locked down with strict policies in place regarding the loading or updating of new applications. File replacement should not be happening in such a production environment. In a world where hackers are a fact of life, you might consider an unauthorized file replacement as possible sabotage. To avoid the intruder doing any further damage, you may need to shut the server down immediately. Forcing a deliberate bug check on a production server is not very popular with most system administrators. It’s not very user friendly either. There could be data loss, and of course, there’s that great huge long chkdsk that will have to be done (although this is much improved in Windows 2000). There is also the loss of services running on those servers that needs to be considered. For e-commerce sites, this translates into lost revenue. However, if the system is under attack, the alternatives may be even less palatable. You have to choose the lesser of two evils! To force a bug check, use the SFPBugCheck value entry, held in the Winlogon key as noted above. If this REG_DWORD value entry is set to 1, then when SFP detects a changed file, a bug check will occur. DLL RedirectionSo what happens when you try to load an application and it fails because the DLLs it is looking for are not there? And what about the impact of SFP on smaller application vendors? Or suppose a legacy application really does need a particular version of some key DLL which happens to conflict with a system DLL? To avoid these being major issues, Windows 2000 has added a new method to allow the application to alter where DLLs are loaded from. This is implemented by means of a DLL Redirection File. In normal operation, when an application requests the operating system to load a DLL, Windows 2000 will use the current path statement to find the DLL. On most Windows 2000 systems, this path will start system’s System32 directory, which is protected by SFP. The DLL Redirection file tells Windows 2000 to start searching for the files in the folder where the application was started. This means that the application can load all the DLLs it wants without conflicting with system DLLs, or versions of DLLs used by other applications. The redirection folder is named simply <appname>.local, where <appname> is the full file name of the application (excluding the path). For example, if your application is called coolapp.exe, then the redirection file would be called coolapp.exe.local. The contents of the redirection file are ignored – it’s only the presence of the file that counts. When Windows 2000 starts coolapp.exe, and sees coolapp.exe.local in the same folder in which coolapp.exe is located, the OS will load DLLs from that directory first. The assumption is that the application will have loaded all its private DLLs in that folder. If DLLs are not found in the application’s folder, the normal DLL location behavior resumes. This allows the application to access all the other system DLLs. This should allow software vendors to quickly fix any DLL problems encountered with Windows 2000 or possibly avoid having to redesign the application to use newer version of core system DLLs. It could also reduce the risk of name conflict – where two vendors create DLLS with the same name. The only downside is that there this can lead ton an increase in memory requirements, especially if you are using lots of applications that take advantage of redirection. In which case, just buy more memory! SummarySystem File Protection should go a long way to reducing the probability of DLL Hell and should provide you with better control over the systems folders. As ever, if you have any comments on this month’s column or any suggestions for future columns, please email me at Thomas_lee@bearpeark.co.uk. |
