Windows 2000 is more than just Windows NT version 5, the successor to Windows NT 4. Microsoft spent an inordinate amount of time and effort in the development cycle of Windows 2000 to address many of the concerns with its predecessor, NT 4. One of the primary strengths of Windows NT was its improved reliability over both the Windows 9x and NT 3.5 environments. However, many users became frustrated with the inability to control the Windows environment and to solve problems with DLLs, corrupt or inconsistent system files, bad drivers, and other application problems. The dreaded Blue Screen of Death and other system failures proved difficult to both identify and solve.
With the development of Windows 2000, Microsoft provided a number of new and revised tools, utilities, and command-line features that help identify and eliminate, or at least decrease, problems with drivers and software. These new features provide new stability for Windows 2000 users, as well as new and improved ways of identifying and overcoming system problems through both command-line and GUI methods. In this Daily Drill Down, I’ll introduce the most important of the new and updated troubleshooting tools in Windows 2000 Professional. Many of these tools are also available in Windows 2000 Server.
Improving Windows 2000
Because of problems with Windows NT 4.0 and 9x maintaining the integrity of the OS environment, Microsoft went to unusual lengths to address some of the major frustrations with the reliability of Windows. In fact, Microsoft decided to go outside their corporation and employ a third-party software tester, National Software Testing Laboratories (NSTL), to evaluate Windows 2000 reliability. Because of this testing, Windows 2000 is significantly more stable than its predecessors. NSTL went outside the ideal lab environment and tested customer installations to provide real-life performance statistics. According to NSTL benchmarks, Windows 2000 Professional is three times more stable than NT Workstation and 13 times more stable than Windows 98. To achieve this level of reliability, Microsoft included a number of significant improvements to protect both the initial Microsoft environment and the third-party software and driver vendors.
One of the irritating problems with Windows 2000 is its inability to install and run older Windows NT or 9x programs in the Windows 2000 environment. To help solve this problem, Microsoft developed a utility to fool the offending installation program into thinking that the appropriate service pack or operating system is in place. A major problem in NT 4 was with third-party problem drivers that ran in the NT kernel. Because the kernel communicates directly with the hardware, improved reliability of the drivers would improve the stability of Windows 2000. A secondary concern with drivers—difficult to track down by NT troubleshooters—was DLL conflicts. To a large degree, DLL problems are a result of poorly written driver applications. Another driver issue to be addressed was that of file corruption, especially of system files through installation of new or updated drivers.
Windows 2000 solutions
The tools I discuss in this Daily Drill Down are all related to the goal of Windows file protection. Although there were a number of tools in the previous Windows products, the significant tools/utilities introduced in Windows 2000 to address file protection are:
- Application Compatibility Tool
- System File Checker
- Driver Verification
- Recovery Console
- Digital Certificates
Application Compatibility Tool
One of the software issues I experienced was the inability for certain installation programs to identify Windows 2000 as an upgrade to either NT or Windows 9x. Many software programs written for Windows NT are designed to look for a particular service pack before installation can proceed. When installing one such application with Windows 2000, I received an error message that was both frustrating and amusing: The installation program informed me that the current operating system (Windows 2000) was too old and needed to be updated. Microsoft was well aware of this situation and developed the Application Compatibility tool to trick an application into thinking that you’re running the required version of the operating system. I have found the Application Compatibility tool (Apcompat.exe) to be a useful workaround in these circumstances. With this utility, you can simulate NT 4.0 Service Packs 3 through 5 or even Windows 9x.
To find Apcompat.exe, browse your Windows 2000 CD’s \Support directory. The syntax of the command is:
Apcompat [-?] [-v version name] –x program path] [-d] [-t] [-g] [-k]
The -? displays the command-line syntax, and -v <version name> specifies the operating system/version number requested. Values can be:
- 1 (NT4 SP3)
- 2 (NT4 SP4)
- 3 (NT4 SP5)
- 4 (Windows 98)
- 5 (Windows 95)
The -x <program path> specifies the path/name of the program to be run, -d disables the Heap Manager, -t specifies the use of the \Temp folder for the specified program, -g corrects the disk space detection, and -k keeps (stores) the application compatibility settings. You can also run this program with a Windows interface (Figure A).
| Figure A |
 |
| The Application Compatibility tool runs on the command line or within Windows, as shown here. |
Should the original error occur again after successfully installing the program, the application is incompatible and cannot be run under Windows 2000. (Note: This utility will not help with programs that attempt to directly access hardware or Windows 9x programs that use Virtual Device Drivers [VXDs].)
Why disable the heap manager?
Some older programs utilize memory in a way that conflicts with Windows 2000 memory management. Although a program running with the heap manager disabled will avoid conflicts with Windows 2000 memory management, it will also utilize memory less efficiently.
Why correct the disk space detection?
Windows 2000 can detect and utilize space above the 2.1-GB barrier that existed in previous versions. If the application uses a different data type to store the amount of free disk space available, there will be insufficient space to run.
For more information about the Application Compatibility tool, see the Microsoft Knowledge Base article Q251062.
System File Checker
One of the most frustrating aspects of the previous versions of Windows was its inability to track or trap invalid changes to critical system files by software, particularly when installing drivers. To improve Windows, Microsoft added the Windows File Protection feature. Windows 2000 maintains a copy of the critical system files used by the operating system.
The System File Checker utility (Sfc.exe) is a command-line utility that can be run by system administrators to verify that the protected system files are valid and, if not, replace them with a version in the cache. The System File Checker maintains a copy of all DLLs to protect them from either user deletion or corruption during program installation. Many installation programs do not check the version of existing system files before either overwriting or replacing system files with their own version. Although the newly installed application may appear to run fine, another application requiring the original system file may not run correctly, if at all. How many people have faced the dreaded message that a new DLL is older than the existing one? Or that a shared DLL may affect another application if changed? Nothing is more frustrating than trying to work backwards to find the original DLL. To help alleviate this problem, vendors must utilize the Microsoft Windows Installer as a condition of receiving the Windows 2000 certified logo to put on their product. This ensures that the installation software will minimize conflicts.
Once set up, System File Checker runs when you restart your computer. If it detects that a protected file has been overwritten or deleted, the System File Checker will retrieve the correct version system file from the folder: %systemroot%\system32\dllcache. Click here to see the syntax of the command.
sfc [/scannow] [/scanonce] [/scanboot] [/cancel] [/quiet] [/enable] [/purgecache] [/cachesize=x]
For a complete definition of these parameters, see the Microsoft Knowledge Base article Q222471.
Should the %systemroot%\system32\dllcache folder become corrupt, which I have yet to see, you can repair the contents of the dllcache directory by using the [/scannow], [/scanonce], or [/scanboot] options. I personally use the [/scanboot] option (to scan all protected files every time the computer restarts) and have noticed little negative impact on the length of the Windows boot process. In fact, the return on investment and peace of mind should make it a standard for anyone using Windows 2000.
Driver Verifier
Where the System File Checker identifies and recovers corrupted system files, the Driver Verifier utility (Verifier.exe) provides you with the ability to monitor one or more kernel mode drivers, watching for illegal function calls or system corruption. In Windows NT 4.0, many driver errors were undetected and led to the dreaded Blue Screen of Death with little information of value in the resulting error log.
With the Driver Verifier utility in place, Windows 2000 detects most bugs immediately. One of the common sources for driver errors is illegal memory addressing to kernel code or buffer pointers. Because device drivers connect the operating system to hardware resources, undetected bugs such as these can be fatal.
You can run Driver Verifier in two ways—either by editing the registry with Regedt32.exe (only for the fearless experts) or by running Verifier.exe. For more information on the registry version of verifier, please see the Microsoft Knowledge Base article Q244617. This type of editing through the registry requires an in-depth knowledge of both the registry and drivers involved.
There is both a command-line and GUI interface available for the verifier utility. In the GUI interface, it is quite easy to select the driver(s) you are suspicious of and wish to monitor. Driver Verifier Manager is located in the %WinDir%\System32 folder. The GUI interface is shown in Figure B, with one driver marked for checking.
| Figure B |
 |
| Use the Driver Verifier Manager to check for unstable Windows 2000 drivers. |
Once you have rebooted your system, the Driver Verifier will watch the drivers that you have requested to monitor for problems. Should an error subsequently occur, you will be presented with a blue-screen bug check error. (A list of error codes can be found within Knowledge Base article Q244617.) Due to the nature of such problems, I would recommend that you contact the vendor of the offending software for upgrades or fixes. Be sure to include a copy of the error generated to help the vendor identify and resolve the problem. If, after a reasonable length of time, no error should occur, the driver in question is probably fine and you can check other suspicious drivers.
Although I have never had to utilize this feature, I know a number of people who have found this new utility a real help in resolving system problems.
Recovery Console
The Windows 2000 Recovery Console gives an administrator the ability to gain access to the system from a command-line session. This would be needed to perform such actions as replacing damaged files, repairing MBRs, disabling services, or enabling services. Be aware that your access is restricted to the root directories, the system directory of the installation you logged on to, and any removable drives you may have booted from. The Recovery Console is not installed by default. After installing it from the Windows 2000 CD, the Recovery Console option is added to your boot menu. The Recovery Console can also be run from the installation CD or boot disk.
For more information on the Recovery Console, please see the following TechProGuild Daily Drill Downs:
- “Using the Recovery Console option in Windows 2000”
- “Fix your Windows 2000 system quickly with the Recovery Console”
Digital Certificates
With each of the previously mentioned utilities, I’ve dealt with ways to identify and recover from system problems caused by bad installation programs or similar situations. In an effort to ensure the reliability of the drivers found in Windows 2000, Microsoft introduced Digital Certificates as part of the Driver Signing program.
To qualify for a Digital Certificate, a driver is put through a series of rigorous tests. Those drivers that pass the stringent Microsoft testing will be signed and added to the Hardware Compatibility List. The approved and signed drivers are allowed to place the Windows 2000 compatibility logo on their product. All drivers on the Windows 2000 CD have been digitally signed and are included on the Hardware Compatibility List. Unsigned drivers may function properly, but there is no guarantee. Also, vendor updates may contain errors and may not have been resubmitted to Microsoft for certification.
To check the status of the drivers on your computer, Windows 2000 includes a new tool, the File Signature Verification utility (Sigverif.exe). To run it, type sigverif at a command prompt. A series of screens will guide you through the process. Sigverif.exe generates a log, Sigverif.txt, that you can view any time in Notepad (see Figure C). The log can be extensive but is a wealth of information.
| Figure C |
 |
| The extensive log generated by the File Signature Verification utility gives you a glance behind the scenes. |
The File Signature Verification utility was designed for drivers already installed on your particular system. But what about drivers that you will install in the future? One of the problems with NT 4.0 was that it allowed drivers to be installed with no intervention. This led to many an unknown problem or the Blue Screen of Death. Windows 2000 includes a new utility, Driver Signing Options, that allows you to determine how new drivers are handled during installation.
The Driver Signing Options dialog box is accessible through Control Panel’s System applet. Select the Hardware tab and click the Driver Signing button. You can select three ways to handle unsigned drivers (see Figure D):
- Ignore—Installs all files, regardless of file signature (default)
- Warn—Displays a message before installing an unsigned file
- Block—Prevents installation of unsigned files
| Figure D |
 |
| Select the way you’d like Windows 2000 to handle driver installation. |
I recommend that you at least use the default option, Warn. I use this option and have been surprised at the number of unsupported drivers that are still out there. Whether a device is installed via the Hardware Installation Wizard or with Plug and Play, the driver’s signing will be checked by this utility.
The bottom line
Microsoft has implemented a number of extremely useful utilities in Windows 2000 to help ensure the reliability and stability of its operating system. This brief introduction to the main utilities should provide you with the impetus to explore these new features of Windows 2000 and prepare you to better support the new operating system.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
