Microsoft® Windows® 2000 Professional Resource Kit, Core Technologies for Windows 2000 Professional and Windows 2000 Server

Disclaimer:

This book is based on Microsoft® Windows® 2000 applications and technologies that are under development. Future versions of this book will reflect subsequent changes in Windows 2000.

© 1985-1999 Microsoft Corporation. All rights reserved.


File Systems

Microsoft® Windows® 2000 supports the NTFS file system and two file allocation table (FAT) file systems: FAT16 and FAT32. The structure of volumes formatted by each of these file systems, as well as the way each file system organizes data on the disk, are significantly different. The capabilities and limitations of these file systems must be reviewed in order to determine their comparative features. The version of NTFS that comes with Windows 2000 (referred to as NTFS version 5.0) includes reparse points, native structured storage, the change journal, encryption, sparse file support, and several other new features.

In This Chapter

About Windows 2000 File Systems

Comparing FAT16, FAT32, and NTFS

File and Folder Compression

NTFS Recoverability

Reparse Points

File System Tools

Related Chapters in the Resource Kit

  • For information about disks, see “Understanding Disks” in this book.
  • For information about disk storage, see “Storing and Managing Data” in this book.
  • For information about system recovery, see “System Recovery” in this book.
  • For information about the registry, see “Overview of the Registry” in this book.

Additional Resources

  • For more information about transaction logging and NTFS recovery operations, see Inside the Windows NT File System, by Helen Custer (Microsoft Press 1994, ISBN 1-55615-660-X).


About Windows 2000 File Systems

An operating system’s ability to access files on a volume depends on the file system with which the volume was formatted. Table 9 1 shows the file system format used by various operating systems.

Note

The high performance file system (HPFS) has not been addressable or convertible since Microsoft® Windows® NT 3.51.

Table 9.1 Operating System and File System Compatibility

Operating System | File System Format of Volume
Windows 2000 | NTFS FAT16 FAT32
Microsoft® Windows® NT | NTFS FAT16
Microsoft® Windows® 95 OSR2 (Operating system release 2) and Microsoft® Windows® 98 | FAT16 FAT32
Windows 95 prior to version OSR2 | FAT16
Microsoft ® MS-DOS® | FAT16
OS/2 | FAT16

Note

FAT16 and FAT32 are referred to collectively as FAT unless the differences between them must be noted.

You can use long and short file names in both NTFS and FAT volumes. A long file name can be up to 256 characters long. Short file names are in the format Xxxxxxxx.yyy, and are compatible with MS-DOS and OS/2.


The FAT File System

FAT was designed for small disks and simple folder structures. FAT stands for file allocation table, which is located at the beginning of the volume. To protect the volume, two copies of the file allocation table are stored on the volume. In the event that one of these files is corrupted, the other file is used. The file allocation table is stored in a fixed location so that the files needed to start the system can be located.

The FAT16 File System

FAT16 is included in Windows 2000 for the following reasons:

  • It maintains an upgrade path for earlier versions of Windows-compatible products.
  • It is compatible with most non-Microsoft operating systems.

The maximum size for a Windows 2000 FAT16 volume is 4,095 megabytes (MB); this is unchanged from previous versions.

A volume formatted with FAT16 is allocated in clusters. The default cluster size is determined by the volume size, and can be as large as 64 kilobytes (KB). The cluster number must fit in 16 bits and be a power of two. Table 9.2 shows the default cluster sizes for FAT16 volumes. You can specify a different cluster size if you format the volume with the format command from the command prompt. However, the size you specify must be listed in Table 9.2.

Table 9.2 FAT16 Cluster Sizes

Volume Size | Sectors Per Cluster | Cluster Size
0 MB - 32 MB | 1 | 512 bytes
33 MB - 64 MB | 2 | 1 KB
65 MB - 128 MB | 4 | 2 KB
129 MB - 255 MB | 8 | 4 KB
256 MB - 511 MB | 16 | 8 KB
512 MB - 1,023 MB | 32 | 16 KB
1,024 MB - 2,047 MB | 64 | 32 KB
2,048 MB - 4,095 MB | 128 | 64 KB

FAT16 is not recommended for volumes larger than 511 MB because of its overhead. You cannot use FAT16 on volumes larger than 4 gigabytes (GB), regardless of the cluster size.

Note

On volumes with the number of sectors less than 32,680, the cluster sizes can be up to 8 sectors per cluster. The format program, whether you format the volume by using Disk Administrator or run format at the command prompt, creates a 12-bit FAT. Volumes less than 16 MB are usually formatted for a 12-bit FAT, but the exact size depends on the disk geometry. The disk geometry also determines the point at which a larger cluster size is needed, because the number of clusters on the volume must fit into 16 bits. Therefore, you might have a 33 MB volume that still has only 1 sector per cluster.

FAT12 is the original implementation of FAT and is intended for very small media. FAT uses less space than disk file system structures because it uses less space for each FAT entry. You usually see FAT12 on very small media or on old media. All 1.44MB 3.5-inch floppy disks are FAT16, and all 5.25-inch floppy disks are FAT12.

Structure of a FAT16 Volume

Figure 9.1 illustrates how FAT organizes a volume. The file allocation table (areas FAT1 and FAT2 in Figure 9.1) identifies each cluster in the volume as one of the following:

  • Unused
  • Cluster in use by a file
  • Bad cluster
  • Last cluster in a file

Figure 9.1 Organization of a FAT Volume

The root folder contains an entry for each file and folder on the volume. The only difference between the root folder and other folders is that the root folder is at a specified location and has a fixed size of 512 entries (for a hard disk). The number of entries on a floppy disk depends on the size of the disk.

Folders have a 32-byte entry for each file and folder contained in the folder. The entry includes the following information:

  • Name (eight-plus-three characters).
  • Attribute byte (8 bits of information, described later in this section).
  • Create time (24 bits).
  • Create date (16 bits).
  • Last access date (16 bits).
  • Last modified time (16 bits).
  • Last modified date (16 bits).
  • Starting cluster number in the file allocation table (16 bits).
  • File size (32 bits).

In a FAT folder structure, files are given the first available location on the volume. The starting cluster number is the address of the first cluster used by the file. Each cluster contains a pointer to the next cluster in the file, or an indication (0xFFFF) that this cluster is the end of the file. These pointers and end of file indicators are shown in Figure 9.2.

Figure 9.2 Files on a FAT Volume

Figure 9.2 shows three files in a folder. File1.txt is large enough to use three clusters. File2.txt is a fragmented file that also requires three clusters. The third file, File3.txt, fits completely in one cluster. In each case, the folder entry points to the first cluster of the file.

The information in the folder is used by all operating systems that support FAT. Windows 2000 can store additional time stamps in a FAT folder entry. These time stamps show when the file was created or last accessed and are used principally by Portable Operating System Interface for UNIX (POSIX) applications.

Because all entries in a folder are the same size, the attribute byte for each entry in a folder describes what kind of entry it is. For example, one bit indicates that the entry is for a subfolder and another bit marks the entry as a volume label. Typically, only the operating system controls the settings of these bits.

The attribute byte includes four bits that can be turned on or off by the user—archive file, system file, hidden file, and read-only file.

The FAT32 File System

FAT32 is new for Windows 2000. The main benefit of FAT32 is its ability to support volumes larger than those handled by FAT16. FAT16 supports volumes up to 4 GB, whereas FAT32 formats volumes up to 32 GB. The FAT32 on-disk format and features are the same on Windows 2000 as they are on Windows 95 OSR2 and Windows 98.

Note

Windows 2000 FAT32 implementations are limited to creating 32 GB volumes; however, any size FAT32 volume can be mounted.

To maintain the best compatibility with programs, networks, and device drivers, FAT32 was changed as little as possible from existing FAT16 architecture, internal data structures, application programming interfaces (APIs), and on-disk format.

However, because FAT 32 requires 4 bytes to store cluster values, many internal and on-disk data structures and published APIs have been revised or expanded. In some cases, existing APIs have been prevented from working on FAT32 drives so legacy disk utilities that use them don’t damage the FAT32 drives. Most programs are unaffected by these changes and existing FAT tools and drivers should continue to work on FAT32 drivers. However, MS-DOS disk tools must be updated to support FAT32 drives.

Structure of a FAT32 Volume

The main difference between FAT16 and FAT32 is the logical partition size. FAT32 breaks the 2-gigabyte (GB) logical drive limitation of FAT16 volumes by extending a single logical drive capacity to 127 GB. If you have a 2 GB drive, you must use a 32 KB cluster. With FAT32, the range for a 4 KB cluster, for example, includes drive sizes between 512 MB and 8 GB.

The largest possible file for a FAT32 drive is 4 GB minus 2 bytes. FAT32 includes 4 bytes per cluster within the file allocation table. This differs from FAT16, which contains 2 bytes per cluster, and FAT12, which contains 1.5 bytes per cluster within the file allocation table.

A FAT32 volume must have at least 65,527 clusters. Also, you cannot decrease the cluster size on a FAT32 volume such that the file allocation table ends up being more than (16 MB - 64 KB)/4 or almost 4 million clusters.

You cannot format FAT32 volumes greater than 32 GB. Use NTFS to format volumes larger than these. For more information about why Microsoft recommends that you format all Windows 2000 partitions with NTFS, see “Advantages of NTFS” later in this chapter.

Note

You cannot create a FAT32 volume larger than 32 GB using the FORMAT tool. However, the Windows 2000 FASTFAT driver enables you to mount and fully support a FAT32 volume larger than 32 GB.

FAT16 and FAT32 do not scale well. As the volume gets bigger, the file allocation table gets bigger, which dramatically increases the amount of time it takes Windows 2000 to compute how much free space is on the boot volume when the system is rebooted.

File Names on FAT Volumes

Files created or renamed on FAT volumes use attribute bits to support long file names in a way that does not interfere with how MS-DOS or OS/2 gains access to the volume.

Whenever you create a file with a long file name, Windows 2000 creates a conventional eight-plus-three name for the file and one or more secondary folder entries for the file, one for each 13 characters in the long file name. Each secondary folder entry stores a corresponding part of the long file name in Unicode.

Windows 2000 marks the secondary folder entry as part of a long file name by setting the volume, read-only, system file, and hidden file attribute bits. MS-DOS and OS/2 generally ignore folder entries with all four of these attribute bits set, so these entries are invisible to these operating systems. MS-DOS and OS/2 access the file by using the conventional eight-plus-three file name contained in the folder entry for the file.

Figure 9.3 shows all of the folder entries for the file Thequi~1.fox, which has a long name of The quick brown.fox. The long name is in Unicode, so each character in the name uses two bytes in the folder entry. The attribute field for the long-name entries has the value 0x0F. The attribute field for the short name is 0x20.

Figure 9.3 Long File Name on a FAT Volume

Note

Windows 95, Windows 98, Windows NT and Windows 2000 use the same algorithm to create long and short file names. On computers that dual boot these operating systems, files that you create when running one operating system can be accessed when running the other.

For information about how Windows 2000 creates short file names, see “Using Long File Names” later in this chapter.

Warning

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

By default, Windows 2000 supports long file names on FAT volumes. You can prevent a FAT file system from creating long file names by setting the value of the Win31FileSystem registry entry

(in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem) to 1:

This value prevents Windows 2000 from creating new long file names on all FAT volumes, but it does not affect existing long file names.

Using FAT with Windows 2000

FAT16 works the same in Windows 2000 as it does in MS-DOS, Windows 3.x, Windows 95, and Windows 98. FAT32 works the same in Windows 2000 as it does in Windows 95 OSR2 and Windows 98. In fact, you can install Windows 2000 on an existing FAT primary partition or logical drive. When running Windows 2000, you can move or copy files between FAT and NTFS volumes.

Note

You cannot use Windows 2000 with any compression or partitioning software that requires disk drivers to be loaded by MS-DOS. Therefore, you cannot use MS-DOS 6.0 DoubleSpaceâ or MS-DOS 6.22 DiskSpaceä on a FAT primary partition or logical drive that you want to access when running Windows 2000.

If you have a dual-boot configuration with Windows 95, Windows 98, Windows NT and Windows 2000, you can create FAT partitions when running Windows 95 and Windows 98 that you cannot use when running Windows NT and Windows 2000. For more information, see “Understanding Disks” in this book.


The NTFS File System

Windows 2000 comes with NTFS version 5.0. This newest version of NTFS provides performance, reliability, and compatibility not found in FAT. The NTFS version 5.0 data structures allow you to take advantage of new features in Windows 2000, such as Active Directory, Management Software, and the storage features based on reparse points.

NTFS also includes security features required for file servers and high-end personal computers in a corporate environment, and data access control and ownership privileges important for data integrity.

Multiple Data Streams

NTFS version 5.0 supports multiple data streams, where the stream name identifies a new data attribute on the file. Streams have separate opportunistic locks, file locks, allocation sizes, and file sizes, but files can be shared.

This feature enables you to manage data as a single unit. The following is an example of an alternate stream:

myfile.dat:stream2

A library of files might exist where the files are defined as alternate streams, as in the following example:

library:file1
       :file2
       :file3

You could use a smart compiler to create a file structure like the following:

program:source_file
       :doc_file
       :object_file
       :executable_file

You can use the Win32 API CreateFile to create an alternate data stream. Or, from the command prompt, you can type commands such as:

echo text>program:source_file
more <program:source_file

Caution

Because NTFS is not supported on floppy disks, when you copy an NTFS file to a floppy disk, data streams and other attributes not supported by FAT are lost.

Reparse Points

Reparse points are new file system objects in NTFS version 5.0. Reparse points have a definable attribute containing user-controlled data and are used to extend functionality in the input/output (I/O) subsystem by altering the way NTFS resolves path names. For example, when you open the file C:\WINNT\System32\example.doc, NTFS locates the C drive, and then locates, in sequence, the boot partition, the WINNT directory, the SYSTEM32 directory, and Example.doc. At each step, a reparse point can exist.

For more information, see “Reparse Points” later in this chapter.

Native Structured Storage

In earlier versions of NTFS, the multiple data streams resulting from ActiveX compound documents are physically stored as a single data stream. In NTFS version 5.0, Native Structured Storage (NSS) allows each embedded object and substructure contained in a compound document to be stored in a separate physical data stream on the disk. Using multiple stream storage support improves file system efficiency and lays the groundwork for future storage enhancements.

Windows 2000 requires that a reparse point be placed on any file that utilizes NSS. The presence of the reparse point:

  • Indicates that the file has multiple streams.
  • Instructs a file system filter driver to translate the multiple streams to a single stream when the file is migrated to file systems that do not support NSS.

For more information about NSS, see “Storing and Managing Data” in this book.

The Change Journal

The change journal is used by NTFS 5.0 to provide a persistent log of all changes made to files on the volume. For each volume, NTFS 5.0 uses the change journal to track information about added, deleted, and modified files. With the change journal, a system administrator can view volume changes without resorting to namespace traversal. File system indexing, replication managers, remote storage, and incremental backup applications can benefit from the change journal. The change journal is much more efficient than time stamps or file notifications for determining changes in a given namespace.

The change journal is a sparse stream where only a small active range of the file uses any disk allocation. The active range initially begins at offset 0 in the stream and moves monotonically forward through the file. The Unique Sequence Number (USN) of a particular record represents its virtual offset in the stream. As the active range moves forwards through the stream, earlier records are deallocated and become unavailable. The size of the active range in a sparse file can be adjusted. See the Windows 2000 Software Developer’s Kit (SDK) for more information.

Encryption

File and directory-level encryption is implemented in NTFS 5.0 for enhanced security in NTFS 5.0 volumes. Windows 2000 uses Encrypted File System (EFS) to store data in encrypted form, which provides security when the storage media is removed from a system running Windows 2000.

EFS is implemented in Windows 2000 as a Microsoft Installable File System (IFS) filter for NTFS 5.0 that encrypts and decrypts file and directory data as it is read and written to the disk. For more information about EFS, see the Distributed Systems Guide of the Windows 2000 Resource Kit.

Sparse File Support

Sparse files allow programs to create very large files, but to consume disk space only as needed. A sparse file is a file with an attribute that causes the I/O subsystem to allocate the file’s meaningful (nonzero) data. All nonzero data is allocated in memory, whereas all nonmeaningful data (large strings of data composed of zeros) is not. When a sparse file is read, allocated data is returned as it was stored, and nonallocated data is returned, by default, as zeros in accordance with the C2 security requirement specification. For more information about C2 security, see Appendix A, “C2 Security.”

NTFS deallocates sparse data streams and only maintains non-sparse data as allocated. When a program accesses a sparse file, the file system yields allocated data as actual data and deallocated data as zeros.

NTFS 5.0 includes full sparse file support for both compressed and uncompressed files. NTFS handles read operations on sparse files by returning allocated data and sparse data. It is possible to read a sparse file as allocated data and a range of data without having to retrieve the entire data set, although by default, NTFS returns the entire data set.

You can set a user-controlled file system attribute to take advantage of the sparse file function in NTFS. With the sparse file attribute set, the file system can deallocate data from anywhere in the file and, when an application calls, yield the zero data by range instead of storing and returning the actual data. File system APIs allow for the file to be copied or backed as actual bits and sparse stream ranges. The net result is efficient file system storage and access. Figure 9.4 shows how data is stored with and without the sparse file attribute set.

Figure 9.4 Sparse Data Storage

Disk Quotas

Disk quotas are a new feature in NTFS 5.0 that provide more precise control of network-based storage. Disk quotas are implemented on a per-volume basis and enable both hard and soft storage limits to be implemented on a “per user” basis.

The introduction of distributed file system (DFS), NTFS directory junctions, and volume mount points create situations where logical directories do not have to correspond to the same physical volume. Available disk space is based on user context, and the space reported for a volume is not necessarily representative of the space available to the user. For this reason, do not rely on space queries to make assumptions about the amount of available disk space in directories other than the current one. For more information about NTFS directory junctions and volume mount points, see “Reparse Points” later in this chapter.

Link Tracking and Object Identifiers

Windows 2000 provides a link-tracking service that enables client applications to track link sources that have been moved locally or within a domain. Clients that subscribe to this link tracking service can maintain the integrity of their references because the objects referenced can be moved transparently. Files managed by NTFS 5.0 can be referenced by a unique Object ID (object identifier). Link tracking stores a file’s object identifier as part of its tracking information.

NTFS Compatibility Issues

If you are running Microsoft® Windows® NT version 4.0 Service Pack 3, you cannot read removable media formatted with NTFS 5.0. If you are running Windows NT version 4.0 Service Pack 4, you can read any basic (non-dynamic) volumes formatted with NTFS 5.0.

The Windows NT 4.0 Service Pack 4 NTFS driver allows Windows NT 4.0 users to mount NTFS 5.0 volumes. However, Windows NT 4.0 users cannot use any of the NTFS 5.0 features.

If you use an operating system in addition to Windows 2000, you can access files on NTFS volumes only from Windows NT or Windows 2000. You must use a file system other than NTFS for the system and boot partitions of the other operating system.

Important

Because NTFS data structures are not the same for Windows NT 4.0 and Windows 2000, Windows NT 4.0 disk tools such as CHKDSK and AUTOCHK do not work on volumes formatted with NTFS 5.0. These tools check the version stamp of NTFS before they perform their tasks. After installing Windows 2000, users must run the updated version of these disk tools.

Because of these compatibility issues, dual booting between Windows NT 4.0 and Windows 2000 is not recommend. The Windows NT 4.0 Service Pack 4 NTFS driver is provided only to assist in evaluating and migrating to Windows2000.

Upgrading to Windows 2000

An upgrade from any version of Windows NT to Windows 2000 (when you are not multiple booting) results in the following:

  • All volumes formatted with an earlier version of NTFS are converted to NTFS 5.0.
  • All boot/system volumes formatted with FAT16 are converted to NTFS 5.0.
  • All volumes formatted with FAT16 that are not boot/system volumes are not converted.

Converting from Windows NT 4.0 Service Pack 3 to Windows 2000

When you install Windows 2000 on a computer that is running Windows NT 4.0 Service Pack 3, your NTFS 4.0 volumes and FAT16 volumes are converted to NTFS 5.0 the first time you boot the new operating system. Setup then installs a new NTFS driver so you can access all of your drives.

Converting from FAT16 Volumes to NTFS 5.0 Volumes

Setup converts your boot/system partition from FAT16 to NTFS 5.0 under the following conditions:

  • If you are upgrading your system from Windows NT 4.0 to Windows 2000.
  • If the only operating system running on your workstation is Windows 2000 Professional.
  • If you are running only Windows 2000 on a multiple boot system.

The upgrade to NTFS 5.0 occurs during the installation of Windows 2000. Existing NTFS or FAT16 volumes can be converted to this format at any time.

Multiple Booting of Windows NT and Windows 2000

Your ability to access your NTFS volumes when you multiple boot Windows NT and Windows 2000 depends on which version you are using. (Redirected clients using NTFS volumes on file/print servers are not affected.)

  • If you multiple boot Windows 2000 and Windows NT 4.0 Service Pack 4, you are able to read any Basic (non-dynamic) volumes formatted with NTFS 5.0.
  • If you multiple boot Windows 2000 and Windows NT 4.0 Service Pack 3, a new NTFS driver is installed in the Windows NT 4.0 Service Pack 3 directory that enables Windows NT 4.0 Service Pack 3 to access volumes formatted with NTFS 5.0.
  • If you multiple boot Windows 2000 and a version of Windows NT that was released before Windows NT 4.0 Service Pack 3, you cannot access your NTFS volumes with the earlier version of Windows NT. Configurations affected by this scenario include:
    • Volumes on removable media.
    • Volumes used with multiple boot configurations.
    • Volumes shared within clustered configurations.

Windows NT Compatibility With NTFS 5.0

When a Windows 2000 volume is mounted on a Windows NT 4.0 Service Pack 4 system, most NTFS 5.0 features are not available. However, most read and write operations are permitted if they do not make use of any NTFS 5.0 features. Features affected by this configuration are as follows:

  • Reparse points. Windows NT cannot perform any operations on reparse points.
  • Disk quotas. When running Windows NT, Windows 2000 disk quotas are ignored. This enables you to allocate more disk space than is allowed by your quota.
  • Encryption. Windows NT cannot perform any operations on files encrypted by Windows 2000.
  • Sparse files. Windows NT cannot perform any operations on sparse files.
  • Change journal. Windows NT ignores the change journal. No entries are logged when files are accessed.
  • Object IDs. Windows NT is allowed full access to objects created by Windows 2000. Objects can be opened, read, written, copied and deleted.

Clean-Up Operations on Windows NT Volumes

Because files on volumes formatted with NTFS 5.0 can be read and written to by Windows NT, Windows 2000 may need to perform "clean-up" operations to ensure the consistency of the data structures of a volume after it was mounted on a Windows NT system. Features affected by clean-up operations are explained below.

  • Disk quotas

    If disk quota is turned off, Windows 2000 performs no clean-up operations. If disk quota is turned on, Windows 2000 cleans up the quota information.

    If a user exceeds their disk quota while the NTFS 5.0 volume is mounted by a Windows NT system, all further disk allocations of data by that user will fail. The user may still read and write data to any existing file, but will not be able to increase the size of a file. However, the user can delete and shrink files. When the user gets below their assigned disk quota, they may resume disk allocations of data. The same behavior occurs when a system is upgraded from a Windows NT system to a Windows 2000 system with quotas enforced.

  • Reparse points

    Because reparse points cannot be accessed by Windows NT systems, no clean-up operations are necessary.

  • Encryption

    Because encrypted files cannot be accessed by Windows NT systems, no clean-up operations are necessary.

  • Sparse files

    Because sparse files cannot be accessed by Windows NT systems, no clean-up operations are necessary.

  • Object IDs

    Windows 2000 maintains two references to the object identifier. One is on the file, the other is in the volume-wide object identifier index. If you delete a file with an object identifier on it, Windows 2000 must scan and clean up the left-over entry in the index. During this scan, an OpenByObjectID call can fail if the object was deleted.

  • Change journal

    Windows NT systems do not log file changes in the change journal. When Windows 2000 boots, the change journals on volumes accessed by Windows NT are reset to indicate that the journal history is incomplete. Applications that use the change journal must have the ability to accept incomplete journals.

Structure of an NTFS Volume

Like FAT, NTFS uses clusters as the fundamental unit of disk allocation, although with NTFS, the default cluster size depends on the volume size. In the Disk Management snap-in, you can specify a cluster size of up to 4 KB. If you use the command prompt program format to format your NTFS volume, you can specify any of the default cluster sizes shown in Table 9.3.

Table 9.3 Default Cluster Sizes for NTFS

Volume Size | Sectors Per Cluster | Cluster Size
512 MB or less | 1 | 512 bytes
513 MB - 1,024 MB | 2 | 1 KB
1,025 MB - 2,048 MB | 4 | 2 KB
2,049 MB - 4,096 MB | 8 | 4 KB
4,097 MB - 8,192 MB | 16 | 8 KB
8,193 MB - 16,384 MB | 32 | 16 KB
16,385 MB - 32,768 MB | 64 | 32 KB
> 32, 768 MB | 128 | 64 KB

Important

You cannot use NTFS compression when your cluster size is greater than 4 KB. For more information, see “File and Folder Compression” later in this chapter.

Boot Sector

The first information found on an NTFS volume is the boot sector. The boot sector starts at sector 0 and can be up to 16 sectors long. It consists of two structures:

  • The BIOS Parameter Block, which contains information on the volume layout and file system structures.
  • Code that describes how to find and load the startup files for the operating system being loaded. For Windows 2000 on x86-based computers, this code loads the file NTLDR. For more information about the boot sector, see “Understanding Disks” in this book.

Master File Table and Metadata

When a volume is formatted with NTFS, a Master File Table (MFT) and metadata are created. Metadata are the files NTFS uses to implement the file system structure. NTFS reserves the first 16 records of the MFT for metadata (approximately 1 MB). Table 9.4 lists and briefly describes the metadata stored in the MFT.

Table 9.4 Metadata Stored in the Master File Table

System File | File Name | MFT Record | Purpose of the File
Master file table | $Mft | 0 | Contains one base file record for each file and directory on an NTFS volume. If the allocation information for a file or directory is too large to fit within a single record, other file records are allocated as well.
Master file table2 | $MftMirr | 1 | A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure.
Log file | $LogFile | 2 | Contains a list of transaction steps used for NTFS recoverability. Log file size depends upon the volume size and can be as large as 4 MB. It is used by Windows 2000 to restore consistency to NTFS in the event of a system failure. For more information about the log file, see “NTFS Recoverability” later in this chapter.
Volume | $Volume | 3 | Contains information about the volume, such as the volume label and the volume version.
Attribute definitions | $AttrDef | 4 | A table of attribute names, numbers, and descriptions.
Root file name index | $ | 5 | The root directory.
Cluster bitmap | $Bitmap | 6 | A representation of the volume showing which clusters are in use.
Partition boot sector | $Boot | 7 | Includes the bootstrap for the volume if it is a bootable volume.
Bad cluster file | $BadClus | 8 | Contains bad clusters for the volume.
Security file | $Secure | 9 | Contains unique security descriptors for all files within a volume.
Upcase table | $Upcase | 10 | Converts lowercase characters to matching Unicode uppercase characters.
NTFS extension file | $Extend | 11 | Used for various optional extensions such as quotas, reparse point data, and object identifiers.
 |  | 12-15 | Reserved for future use.

The remaining records of the MFT contain the file and directory records for each file and directory on the volume.

Note

If the first MFT record is corrupted, NTFS reads the second record to find the MFT mirror file. The data segment locations for both $Mft and $MftMirr are recorded in the boot sector. A duplicate of the boot sector is located at the end of the volume.

NTFS creates a file record for each file and a directory record for each directory created on an NTFS volume. The MFT includes a separate file record for the MFT itself. These file and directory records are stored on the MFT. NTFS allocates space for each MFT record based upon the cluster size of the file. The attributes of the file are written to the allocated space in the MFT. Besides file attributes, each file record contains information about the position of the file record in the MFT.

Each file usually has one file record. However, if a file has a large number of attributes or becomes highly fragmented, it may need more than one file record. If this is the case, the first record for the file, called the base file record, stores the location of the other file records required by the file. Small files and directories (typically 1500 bytes or smaller) are entirely contained within the file’s MFT record. Figure 9.5 shows the contents of an MFT record for a small file or folder.

Figure 9.5 MFT Record for a Small File or Folder

Directory records contain index information. Small directory records reside entirely within the MFT structure, while large directories are organized into B-tree structures and have records with pointers to external clusters that contain directory entries that could not be contained within the MFT structure.

NTFS File Attributes

Every allocated sector on an NTFS volume belongs to a file. Even the file system metadata is part of a file. NTFS views each file (or folder) as a set of file attributes. Elements such as the file’s name, its security information, and even its data, are all file attributes. Each attribute is identified by an attribute type code and, optionally, an attribute name.

When a file’s attributes can fit within the MFT file record for that file, they are called resident attributes. Information such as file name and time stamp are always resident attributes. When the information for a file is too large to fit in its MFT file record, some of the file attributes are nonresident. Nonresident attributes are allocated one or more clusters of disk space elsewhere in the volume. NTFS creates the Attribute List attribute to describe the location of all of the attribute records.

Table 9.5 lists the file attributes defined by NTFS, although other file attributes may be defined in the future.

Table 9.5 NTFS File Attribute Types

Attribute Type | Description
Standard Information | Includes information such as time stamp and link count.
Attribute List | Lists the location of all the attribute records that do not fit in the MFT record.
File name | A repeatable attribute for both long and short file names. The long name of the file can be up to 255 Unicode characters. The short name is the MS-DOS–readable, eight-plus-three, case-insensitive name for the file. Additional names, or hard links, required by POSIX can be included as additional file name attributes.
Security Descriptor | Shows information about who owns the file and who can access the file.
Data | Contains file data. NTFS allows multiple data attributes per file. Each file typically has one unnamed data attribute. A file can also have one or more named data attributes, each using a particular syntax.
Object ID | A volume-unique file identifier. Used by the link tracking service. Not all files have object identifiers.
Logged Tool Stream | Similar to a data stream, but operations on a logged tool stream are logged to the NTFS log file just like NTFS metadata changes. Used by EFS.
Reparse Point | Used for directory junction points and volume mount points. They are also used by file system filter drivers to mark certain files as special to that driver.
Index Root | Used to implement folders.
Index Allocation | Used to implement folders.
Volume Information | Used only in the $Volume system file. Contains the volume version.
Volume Name | Used only in the $Volume system file. Contains the volume label.
Bitmap | Provides a map that represents records in use on the MFT or folder.
Extended Attribute Information | Used by file servers that are linked with OS/2 systems.
Extended Attributes | Used by file servers that are linked with OS/2 systems.

MS-DOS–Readable File names on NTFS Volumes

By default, Windows NT and Windows 2000 generate MS-DOS–readable file names on all NTFS volumes. To improve performance on volumes with many long, similar names, you can use a registry editor to disable this feature by setting the value of the NtfsDisable8dot3NameCreation value name of the following subkey to 1:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem

Windows 2000 does not generate short (eight-plus-three) file names for files created by POSIX-based applications on an NTFS volume, regardless of the value of the NtfsDisable8dot3NameCreation registry entry. This means that MS-DOS–based and Windows-based applications cannot view these file names if they are not valid eight-plus-three filenames. Use standard MS-DOS eight-plus-three naming conventions if you want to use files that are created by a POSIX application with MS-DOS–based or Windows-based applications.


Using Long File Names

File names on Windows NT and Windows 2000 platforms can be up to 256 characters, and can contain spaces, multiple periods, and special characters that are forbidden in MS-DOS file names. Windows 2000 makes it possible for other operating systems to access files with long names by automatically generating an MS-DOS–readable (eight-plus-three) name for each file. Files are accessible over a network by computers using MS-DOS, Windows 3.x, and OS/2, as well as by computers using Windows 95, Windows 98, Windows NT and Windows 2000 operating systems.

By creating eight-plus-three file names for files, Windows 2000 also enables MS-DOS–based and Windows 3.x–based applications to recognize and load files that have long file names. In addition, when an application saves a file on a computer running Windows 2000, both the eight-plus-three file name and long file name are retained.

Caution

Use caution with MS-DOS–based or Windows 3.x–based applications when running them on Windows NT and Windows 2000. With these applications, if you save a file to a temporary file, delete the original file, and rename the temporary file to the original file name, the long file name is lost along with any unique permissions set on that file.

If the long name of a file or folder contains spaces, you must surround the name with quotation marks. For example, if you have a program called DUMP DISK FILES that you want to run from the command line and you enter the name without quotation marks, you get an error message that says “Cannot find the program DUMP or one of its components.”

You must also use quotation marks when a path typed at the command line includes spaces, as in the following example:

move "c:\This month's reports\*.*" "c:\Last month's reports"

Use wildcard characters such as * and ? carefully in conjunction with the del and copy command prompt commands. Windows 2000 searches both long and short file names for matches to the wildcard character combination you specify, which can cause additional files to be deleted or copied.

Both FAT and NTFS use the Unicode character set for their names, which contain several forbidden characters that MS-DOS cannot read in any file name. To generate a short MS-DOS–readable file name for a file, Windows 2000 deletes all of these characters from the long file name and removes any spaces. Because an MS-DOS–readable file name can have only one period, Windows 2000 also removes all extra periods from the file name. Next, Windows 2000 truncates the file name, if necessary, to six characters and appends a tilde (~) and a number. For example, each non-duplicate file name is appended with ~1. Duplicate file names end with ~2, then~3, and so on. After the file names are truncated, the file name extensions are truncated to three or fewer characters. Finally, when displaying file names at the command line, Windows 2000 translates all characters in the file name and extension to uppercase.

When there are five or more files that would result in duplicate short file names, Windows 2000 uses a slightly different method for creating short file names. For the fifth and subsequent files, Windows 2000:

  • Uses only the first two letters of the long file name.
  • Generates the next four letters of the short file name by mathematically manipulating the remaining letters of the long file name.
  • Appends ~1 (or another number, if necessary, to avoid a duplicate file name) to the result.

This method provides substantially improved performance when Windows 2000 must create short file names for a large number of files with similar long file names. Windows 2000 uses this method to create short file names for both FAT and NTFS files.

Table 9.6 shows the short file names for files that were created in the order test 1 through test 6.

Table 9.6 Short File Names Created by Windows 2000 - Example One

Long File Name | Short File Name
This is test 1.txt | THISIS~1.TXT
This is test 2.txt | THISIS~2.TXT
This is test 3.txt | THISIS~3.TXT
This is test 4.txt | THISIS~4.TXT
This is test 5.txt | TH0FF9~1.TXT
This is test 6.txt | THFEF5~1.TXT

If the long file names in Table 9.6 are created in a different order, their short file names are different, as shown in Table 9.7.

Table 9.7 Short File Names Created by Windows 2000 - Example Two

Long File Name | Short File Name
This is test 2.txt | THISIS~1.TXT
This is test 3.txt | THISIS~2.TXT
This is test 1.txt | THISIS~3.TXT
This is test 4.txt | THISIS~4.TXT
This is test 5.txt | TH0FF9~1.TXT
This is test 6.txt | THFEF5~1.TXT

Windows 2000 displays the long names for folders and files. You can use Windows Explorer and My Computer to see the short name by selecting the file or folder and selecting Properties on the File menu.

To see both the long and short file names for each file in the folder, type the following command on the command line:

dir /x

Tip

To display both long and short file names automatically when using the dir command, use the System option in Control Panel to set the dircmd variable to the value /x.


Compact Disk File System

Windows 2000 provides support for the ISO 9660-compliant compact disk file system (CDFS), which supports long file names as listed in the ISO 9660 level two standards.

When creating a CD-ROM to be used on Windows 2000, you must adhere to the following standards:

  • All directory and file names must be less than 32 characters
  • All directory and file names must be in capital letters
  • The directory tree cannot exceed 8 levels from the root
  • File extensions are not mandatory

Important

CDFS adheres to ISO 9660 standards and therefore does not support lowercase file names. When you use CDFS to access a file or directory with a lowercase file name on a CD-ROM, you get a “File not found” error message.


Universal Disk Format

The Universal Disk Format (UDF) is new for Windows 2000. UDF is a ISO 13346-compliant, standards-based file system designed for interchanging data on DVD and CD-ROM. The primary function of UDF is to support read-only DVD-ROM media.


Comparing FAT16, FAT32, and NTFS

You can use either FAT16, FAT32, NTFS, or a combination of these file systems. The one you choose for a computer, or for an individual volume on a computer, depends on such things as:

  • How the computer is used.
  • The hardware platform.
  • The size and number of hard disks.
  • Security considerations.

Important

Microsoft recommends that you format all Windows 2000 partitions with NTFS except for the system partition of a DIGITAL Alpha computer and multiple boot configurations. For more information, see “Advantages of NTFS” later in this chapter.


Comparing FAT File Systems

The numerals in the names FAT12, FAT16 and FAT32 refer to the number of bits required for a file allocation table entry.

  • FAT12 uses a 12-bit file allocation table entry (212 allocation units).
  • FAT16 uses a 16-bit file allocation table entry (216 allocation units).
  • Windows 2000 reserves the first 4 bits of a FAT32 file allocation table entry, which means FAT32 has a maximum of 228 allocation units. However, this number is capped at 32 GB by Windows 2000.


FAT16 vs. FAT32

Table 9.8 provides a comparison of FAT16 and FAT32 cluster sizes according to drive size.

Table 9.8 Cluster Sizes of FAT16 and FAT32

Drive Size | FAT16 Cluster Size | FAT32 Cluster Size
260 MB - 511 MB | 8 KB | Not supported
512 MB - 1,023 MB | 16 KB | 4 KB
1,024 MB - 2 GB | 32 KB | 4 KB
2 GB - 8 GB | Not Supported | 4 KB
8 GB - 16 GB | Not Supported | 8 KB
16 GB - 32 GB | Not Supported | 16 KB
>32 GB | Not Supported | 32 KB

There are additional differences between FAT32 and FAT16/FAT12:

  • FAT32 allows finer allocation granularity (216 allocation units per volume).
  • FAT32 allows the root directory to grow (FAT12/16 holds, usually, a maximum of 200 or 400 entries in the root).
  • FAT32 does not support Extended Attributes.

Advantages of FAT16

Advantages of FAT16 are:

  • MS-DOS, Windows 95, Windows 98, Windows NT, Windows 2000, OS/2, and UNIX are designed to implement and use it.
  • There are many tools available to address problems and recover data.
  • If you have a startup failure on an x86-based computer, you can start the computer with an MS-DOS bootable floppy disk.
  • It is efficient, both in speed and storage, on volumes smaller than 256 MB.

Note

Use NTFS to format larger volumes. For more information about why Microsoft recommends that you format all Windows 2000 partitions with NTFS, see “Advantages of NTFS” later in this chapter.

Disadvantages of FAT16

Disadvantages of FAT16 are:

  • The boot sector is at a specific location. If that sector becomes corrupt or damaged, the system may not boot.
  • The root directory size is limited based on the media used, and is also fixed in its location. Bad sectors can reduce the amount of available entries.
  • FAT16 is limited to 65,525 clusters, with each cluster fixed in a size relative to the logical drive. If both the maximum number of clusters and their maximum size (32 KB) is reached, the largest drive is limited to 2 GB.
  • FAT16 can waste file storage space in larger drives as the size of the cluster increases. The space allocated for storing a file is based on the size of the cluster allocation granularity, not the file size. A 10 KB file stored in a 32 KB cluster wastes 22 KB of disk space.

Advantages of FAT32

FAT32 allocates disk space much more efficiently than previous versions of FAT. This results in tens and even hundreds of megabytes more free disk space on larger hard drives. In addition, FAT32 provides the following enhancements:

  • It supports drives up to 2 terabytes.
  • It uses space more efficiently than FAT16. FAT32 uses smaller clusters (4 KB for drives up to 8 GB), resulting in 10 to 15 percent more efficient use of disk space relative to large FAT16 drives. FAT 32 also reduces the resources necessary for the computer to operate.
  • FAT 32 is more robust. FAT32 has the ability to relocate the root directory and use the backup copy of the FAT instead of the default copy. In addition, the boot record on FAT32 drives has been expanded to include a backup of critical data structures. This means that FAT32 volumes are less susceptible to a single point of failure than FAT16 volumes.
  • Programs load up to 50% faster.


Advantages of NTFS

Microsoft recommends that you format all Windows 2000 partitions with NTFS except for:

  • The system partition of a DIGITAL Alpha computer.
  • Multiple boot configurations.

Formatting your Windows 2000 partitions with NTFS instead of FAT allows you to use features that are available only on NTFS. These include:

  • Recoverability

    The recoverability designed into NTFS is such that a user should seldom have to run a disk repair program on an NTFS volume. NTFS guarantees the consistency of the volume by using standard transaction logging and recovery techniques. In the event of a system failure, NTFS uses its log file and checkpoint information to automatically restore the consistency of the file system. Always maintain your system and boot partitions by using backup tapes and creating an Automatic System Recovery Disk, as described in “System Recovery” in this book.

  • Compression

    Windows 2000 supports compression on an individual file basis for NTFS volumes. Files that are compressed on an NTFS volume can be read and written by any Windows-based application without first being decompressed by another program. Decompression happens automatically during the read of the file. The file is compressed again when it is closed or saved.

In addition, formatting your volumes with NTFS instead of FAT16 or FAT32 provides the following advantages:

  • NTFS supports all Windows 2000 operating system features.
  • Faster access speed. The B-tree structure used by NTFS minimizes the number of disk accesses required to find a file.
  • File and folder security. On NTFS volumes, you can set file permissions on files and folders that specify which groups and users have access to them, and what level of access is permitted. NTFS file and folder permissions apply both to users working at the computer where the file is stored and to users accessing the file over the network when the file is in a shared folder. With NTFS you can also set share permissions which operate on shared folders in combination with file and folder permissions.

Formatting the System Partition on DIGITAL Alpha Computers

You must format the system partition on a DIGITAL Alpha with FAT. You can use NTFS on your boot partition, which needs to be large enough for all Windows 2000 system components.

Securing your system partition with the Disk Management snap-in prevents anyone who does not have administrative privileges from accessing the system partition. For more information, see Windows Help for the Disk Management snap-in.

Formatting the System Partition in Multiple Boot Configurations

If you want to start another operating system on x86-based computers, such as Windows 95, Windows 98, Windows for Workgroups, MS-DOS, or OS/2, use FAT for your system partition and the boot partition(s) for the other operating system(s). You can use NTFS for your Windows 2000 boot partition and other volumes on the computer, as long as those volumes will not be accessed by an operating system other than Windows 2000 Professional or Windows 2000 Server.


Which is Faster, FAT16, FAT32, or NTFS

For small folders, FAT16 or FAT32 usually provide faster access to files than NTFS because:

  • The FAT structure is simpler.
  • The FAT folder size is smaller for an equal number of files.
  • FAT has no controls regulating whether a user can access a file or a folder, therefore, the system does not have to check permissions for an individual file or whether a specific user has access to the file or folder. This advantage is minimal because Windows 2000 still has to determine if the file is read-only, or whether the file is on a FAT or NTFS volume.

NTFS uses a B-tree structure for all folders, which minimizes the number of disk accesses (and time) required to find a file. In addition, if a folder is small enough to fit into the MFT record, NTFS reads the entire folder when it reads its MFT record.

A FAT folder entry contains an index of the file allocation table, which identifies the cluster number for the first cluster of the folder. To view a file, FAT has to search the folder structure.

In comparing the speed of operations performed on large folders containing both long and short file names, the speed of a FAT operation depends on the operation itself and the size of the folder. If FAT searches for a file that does not exist, it has to search the entire folder—an operation which takes longer on a FAT structure than on the B-tree structure used by NTFS. In mathematical terms, the average time to find a file on a FAT folder is a function of N/2, where N is the number of files. On an NTFS folder, the average time is a function of Log N.

Several factors affect the speed with which Windows 2000 reads or writes a file:

  • Fragmentation of the file. If a file is badly fragmented, NTFS usually requires fewer disk accesses than FAT to find all of the fragments.
  • Cluster size. For both file systems, the default cluster size depends on the volume size, and is always a power of two. FAT16 addresses are 16 bits, FAT32 addresses are 32 bits, and NTFS addresses are 64 bits.
  • The default FAT cluster size is based upon the fact that the file allocation table can have at most 65,535 entries, so the cluster size is a function of the volume size divided by 65,535. Therefore, the default cluster size for a FAT volume is almost always larger than the default cluster size for an NTFS volume of the same size. The larger cluster size for a FAT volume means that there might be less fragmentation in files on a FAT volume.
  • Location of small files. With NTFS, small files are entirely contained within the MFT record. The file size that fits in the MFT record depends upon the cluster size and the number of attributes for the file.


Maximum Volume Sizes

The maximum size of a volume depends on the file system used to format the volume. Windows 2000 allows you to format volumes with three different file systems: NTFS, FAT16, and FAT32.

Windows 2000 has the capability to combine discontiguous disk areas when creating volume sets and stripe sets, but these volumes have the same maximum size limitations of a single volume.

Maximum Sizes on FAT16 Volumes

On Windows 2000, the maximum file size for FAT16 is 232 bytes, and the maximum volume size is 4 GB. FAT16 can support a maximum of 65,535 clusters per volume.

Important

For FAT16 volumes between 2 GB and 4 GB, the cluster size is 64 KB. This cluster size is known to create compatibility issues with some applications. For this reason, it is recommended that FAT32 be used on volumes that are between 2 GB and 4 GB. One of the known compatibility issues involves setup programs that do not compute volume free space properly on a volume with 64 KB clusters and will not run because of a perceived lack of free space. The Format program in Windows 2000 displays a warning and asks for a confirmation before formatting a volume with 64 KB clusters.

Maximum Sizes on FAT32 Volumes

In Windows 2000, the maximum file size and volume size for FAT32 is 32 GB. The FAT32 volume must have at least 65,527 clusters. The maximum number of clusters on a FAT32 volume is 268,435,445.

Maximum Sizes on NTFS Volumes

In theory, it is possible to have an NTFS volume 264 bytes in size. However, even if there were hardware available to supply a logical volume of that capacity, there are other limitations to the maximum size of a volume.

One of these limitations is partition tables. By industry standards, partition tables are limited to 232 sectors. Sector size, another limitation, is a function of hardware and industry standards, and is typically 512 bytes. While sector sizes might increase in the future, the current size puts a limit on a single volume of 2 terabytes (232 * 512 bytes, or 241 bytes).

For now, 2 terabytes should be considered the practical limit for both physical and logical volumes using NTFS.

With NTFS, you can have a maximum of 232 clusters per file. This is an implementation limitation, not a file size restriction.

There is no specific limit to the number of files on an NTFS volume. However, you cannot create any new files when your volume is so full that Windows 2000 cannot allocate another entry in the MFT.


Controlling Access to Files and Folders

On NTFS volumes, you can set file permissions (No Access, List, Read, Add, Add and Read, Change, Full Control, Special Directory Access, Special File Access) on files and folders that specify which groups and users have access to them, and what level of access is permitted. NTFS file and folder permissions apply both to users working at the computer where the file is stored and to users accessing the file over the network when the file is in a shared folder. With NTFS you can also set share permissions (No Access, Read, Change, Full Control), which operate on shared folders in combination with file and folder permissions. File attributes (Read Only, Hidden, System) also limit file access.

FAT16 and FAT32 allow you to set file attributes on files but they do not provide file permissions.

Important

To preserve permissions when you copy or move files between NTFS folders, use the Scopy program on the Windows 2000 Resource Kit companion CD.

You can back up and restore data on FAT and NTFS volumes. However, if you back up data from an NTFS volume and then restore it to a FAT volume, you lose security settings and other file information.

You can restore hierarchical storage management (HSM) data only to an NTFS volume. For more information about HSM, see “Storing and Managing Data” in this book.

Although NTFS provides access controls to individual files and folders, users can perform certain actions to files or folders even if permissions are set on a file or folder to prevent access to users.

For example, you have a folder (Dir1) containing a file (File1), and you grant Full Control to a user for the folder Dir1. If you specify that the user has No Access to File1, the user can still delete File1. This is because the user’s Full Control rights in the folder allow the user to delete the contents (files or subfolders) of the folder.

To prevent files from being deleted, you must set permissions on the file itself, and you must set permissions for the folder containing the file.

Anyone who has List, Read, or greater permissions in a folder can view file properties on any file in the folder, even if file permissions prevent them from seeing the contents of the file.

With FAT volumes, you cannot set any permissions on the individual files and folders. The only security available are the share permissions that are set on the entire share, affect all files and folders on that share, and only function over the network. Once a folder is shared, you can protect the shared folder by specifying one set of share permissions for all files and subfolders of the shared folder. Share permissions are set in much the same way as file and folder permissions are set in NTFS. But because share permissions apply globally to all files and folders in the share, they are significantly less versatile than the file and folder permissions used for NTFS volumes.

Share permissions apply equally to NTFS and FAT volumes. They are enforced by Windows 2000, not the individual file system. However, when you move or copy a file from an NTFS to a FAT volume, permissions and other attributes unique to NTFS are lost.


POSIX Compliance

If you want POSIX compliance, you must use NTFS. POSIX compliance permits UNIX programs to be ported to Windows 2000. Windows 2000 is fully compliant with the Institute of Electrical and Electronic Engineers (IEEE) standard 1003.1, which is a standard for file naming and identification.

The following POSIX-compliant features are included in NTFS:

  • Case-sensitive naming. For example: README.TXT, Readme.txt, and readme.txt are all different files under POSIX.
  • Hard links. A file can be given more than one name. This allows two different file names, which can be located in different folders, to point to the same data.
  • Additional time stamps. These show when the file was last accessed or modified.

Caution

You must use POSIX-based programs to manage file names that differ only in case. POSIX-based programs allow you to create and manage case-sensitive file names.

You cannot use standard commands to manage file names that differ only in case. (Standard commands include those used at the command-line, such as copy, del, and move, and their equivalents in My Computer and Windows Explorer.) For example, if you type the following at the command prompt:

del AnnM.Doc

Both annm.doc and AnnM.Doc are deleted.


File and Folder Compression

Windows 2000 supports compression on individual files and on folders for NTFS volumes. Files compressed on an NTFS volume can be read and written by any Windows-based application without first being decompressed by another program. Decompression occurs automatically when the file is read. The file is compressed again when it is closed or saved. Compressed files and folders have an attribute of C when viewed in My Computer or Windows Explorer.

Only NTFS can read the compressed form of the data. When an application like Microsoft Word or an operating system command like Copy requests access to the file, NTFS decompresses the file before making it available. For example, if you copy a compressed file from another Windows 2000 computer to a compressed folder on your hard disk, the file is decompressed, copied, and recompressed.

This compression algorithm is similar to that used by MS-DOS 6.0 DoubleSpace® and MS-DOS 6.22 DriveSpace®, with one important difference—the MS-DOS functionality compresses the entire primary partition or logical drive, while NTFS enables the user to compress individual files and folders within the NTFS volume.

Note

Windows 2000 does not support DoubleSpace or DriveSpace compression.

NTFS compression performs well on cluster sizes up to 4 KB. Beyond that size, the savings in disk space is not worth the decrease in performance. When the cluster size is greater than 4 KB on an NTFS volume, none of the NTFS compression functions are available.


Compressing and Uncompressing Folders and Files

Files and folders on an NTFS volume are either compressed or uncompressed. The compression state of a folder does not reflect the compression state of the files in that folder. For instance, a folder may be compressed, yet all or some of the files in that folder could be uncompressed.

You can set the compression state of folders and compress or uncompress files by using My Computer, Windows Explorer, or a command-line program called Compact. When using My Computer or Windows Explorer, you can set the compression state of an NTFS folder without changing the compression state of existing files in that folder. If you have read or write permission, you may change the compression state locally or across a network.

To set the compression state of the folder

  1. Select the folder you want to compress or uncompress.
  2. On the File menu, click Properties to display the Properties tab.
  3. Select or clear the Compressed check box.

My Computer or Windows Explorer then pops up a dialog box asking whether all the files and subfolders in the folder should be compressed or uncompressed. Existing files or subfolders in the NTFS folders will retain their compression state unless you select Yes in this dialog box.

To compress or uncompress individual files

  1. Select the folder you want to compress or uncompress.
  2. On the File menu, click Properties to display the Properties tab.
  3. Select or clear the Compressed check box.

You can also use the Properties tab to view the compressed size and compression ratio of the selected file.

Note

Windows 2000 allows closed page files to be compressed. However, when you restart Windows 2000, the page files automatically revert to an uncompressed state. For information about page files, look at topics for virtual or virtual memory in Windows Help.

You can set My Computer and Windows Explorer to display alternate colors for compressed files and folders with the following procedure:

To display alternate colors for compressed files and folders

  1. On the View menu, click Options.
  2. On the View tab, select or clear the Display compressed files and folders with alternate color check box.

Using the Compact Program

The Compact program is the command line version of the compression functionality in My Computer or Windows Explorer. The Compact command displays and alters the compression of folders and files on NTFS volumes. It also displays the compression state of folders.

There are two reasons why you may want to use Compact instead of My Computer or Windows Explorer:

  • You can use Compact in a batch script.
  • If the system fails during compression or uncompression, the file or folder is marked as Compressed or Uncompressed. If the operation did not complete, Compact forces the operation to complete.

Note

Unlike My Computer or Windows Explorer, the Compact program does not prompt you on whether you want to compress or uncompress files and subfolders when you set the compression state of a folder. It automatically does the compression or uncompression of any files that are not already in the compression state you set for the folder.

For more information about the Compact program, type compact /? at the command prompt, or see “File System Tools” later in this chapter.


Effects of Compression on Moving and Copying Files

Moving and copying files and folders in disk volumes can change their compression state. The compression state of these files and folders, and the file system in which they were created, can impact the way they are affected while being moved or copied. The compression state of an NTFS file or folder is controlled by its compression attribute.

Moving Files or Folders on NTFS Volumes

When you move an uncompressed file or folder to another folder, the file remains uncompressed after the move, regardless of the compression state of the folder it was moved to. For example, if you move an uncompressed file to a compressed folder, the file remains uncompressed after the move. See Figure 9.6.

Figure 9.6 Moving an Uncompressed File to a Compressed Folder

When you move a compressed file or folder to another folder, the file remains compressed after the move, regardless of the compression state of the folder it was moved to. See Figure 9.7.

Figure 9.7 Moving a Compressed File to an Uncompressed Folder

Copying Files or Folders on NTFS Volumes

When you copy a file to a folder, the file takes on the compression attribute of the target folder. For example, if you copy a compressed file to an uncompressed folder, the file is automatically uncompressed when it is copied to the folder. See Figure 9.8.

Figure 9.8 Copying a Compressed File to an Uncompressed Folder

When you copy a file to a folder that already contains a file of the same name, the file that is copied takes on the compression attribute of the target file, regardless of the compression state of the folder. See Figure 9.9.

Figure 9.9 Copying a File to a Folder that Already Contains a File of the Same Name

Moving and Copying Files Between FAT16, FAT32, and NTFS Volumes

Like files copied between NTFS folders, files moved or copied from a FAT folder to an NTFS folder always assume the compression attribute of the target folder. Because Windows 2000 supports compression only for NTFS files, any compressed NTFS files moved or copied to a FAT volume are automatically uncompressed. Similarly, compressed NTFS files copied or moved to a floppy disk are automatically uncompressed.

Adding Files to an Almost Full NTFS Volume

When adding files to an NTFS volume that is almost full, you can get error messages that indicate there is not enough disk space to write the entire file if the file cannot be compressed, regardless of the degree of compression in the file when it is opened. For this reason, it is possible to get a read error when you are trying to open a compressed file.

If you copy files to a compressed NTFS folder that does not have enough room for all of the files in their uncompressed state, you will receive a message indicating that there is not enough space on the disk even though the files will all fit when compressed. Because NTFS allocates space based upon the uncompressed size of the file, you can get this error even if the files are already compressed. This situation occurs because compression is handled asynchronously and Windows 2000 uses lazy write file system techniques.

NTFS does not wait for the compression and writing of one file to complete before it begins work on subsequent files, and the system does not get the unused space back from compression until after the buffer is compressed.

When you are running a program and saving files to a compressed folder on a volume that is almost full, the success of the save depends on factors such as how much the file compresses and whether the beginning of the file compresses well.

If you cannot delete any files or do not have any files that you can compress, you can usually copy all of the files if you first copy the largest or the ones that compress best. You can also try copying them in smaller groups rather than all at once.


The NTFS Compression Algorithm

NTFS compression uses a 3-byte minimum search rather that the two-byte minimum used by DoubleSpace. This search enables much faster compressing and uncompressing (roughly two times faster), while only sacrificing two percent compression for the average text file.

Each NTFS data stream contains information that indicates if any part of the stream is compressed. Individual compressed buffers are identified by “holes” following them in the information stored for that stream. If there is a hole, then NTFS knows to uncompress the preceding buffer to fill the hole.

NTFS provides real-time access to a compressed file, uncompressing the file when it is opened and compressing when it is closed. When writing a compressed file, the system reserves disk space for the uncompressed size. The system gets back unused space as each individual compression buffer gets compressed.

Note

Some programs do not allocate space before beginning a save, and only display an error message when they run out of disk space.


Compression Performance

NTFS compression might cause performance degradation because a compressed NTFS file is uncompressed, copied, and then recompressed as a new file, even when copied inside the same computer. Similarly, on network transfers, the file is uncompressed, which affects bandwidth as well as speed.

The current implementation of NTFS compression runs more efficiently on Windows 2000 Professional than on Windows 2000 Server. Compression on a computer running Windows 2000 Professional does not seem to produce a substantial performance degradation; however, computers running Windows 2000 Server have experienced a considerable drop in performance while using NTFS data compression. This performance drop depends on the server’s usage. Heavily loaded servers with considerable write traffic are poor candidates for data compression, while read-only or read-mostly servers, or lightly loaded servers, may not see a severe performance penalty.

The two ways to measure the performance of NTFS data compression are size and speed. You can tell how well compression works by comparing the uncompressed and compressed file and folder sizes. For more information about using the DirUse program to see the compressed size of folders see “File System Tools” later in this chapter.


Other Compression Methods

Compression tools other than NTFS compression are available to compress files on computers running Windows 2000. These tools differ from NTFS compression in the following ways:

  • They usually run only from the command line.
  • Files cannot be opened when they are in a compressed state—the file must first be uncompressed by using the companion program to the one used to compress the file. When you close the file, it is saved in an uncompressed state, and you must use a program to compress it.

The Windows 2000 Resource Kit includes a compress tool, which can only be run from the command line, and two expand tools: one runs from the command line, and the other is a Windows 2000–based program. For more information about these tools, see “File System Tools” later in this chapter.

As mentioned earlier, the DoubleSpace and DriveSpace compression features in MS-DOS cannot be used when running Windows 2000.


NTFS Recoverability

NTFS is a recoverable file system that guarantees the consistency of the volume by using standard transaction logging and recovery techniques. In the event of a disk failure, NTFS restores consistency by executing a recovery procedure that accesses information stored in a log file. The NTFS recovery procedure is exact, guaranteeing that the volume is restored to a consistent state. Transaction logging requires a very small amount of overhead.

NTFS ensures the integrity of all NTFS volumes by automatically performing disk recovery operations the first time a program accesses an NTFS volume after the computer is restarted following a failure.

NTFS also uses a technique called cluster remapping to minimize the effects of a bad sector on an NTFS volume. For more information, see “Cluster Remapping” later in this chapter.

Important

If either the master boot record or boot sector are corrupted, you might not be able to access any data on the volume. Recovery from errors with the master boot record or the boot sector are discussed in “System Recovery” in this book.


Recovering Data with NTFS

NTFS views each I/O operation that modifies a file on the NTFS volume as a transaction and manages each one as an integral unit. Once started, the transaction is either completed or, in the event of a disk failure, rolled back (such as when the NTFS volume is returned to the state it was in before the transaction was initiated).

To insure that a transaction can be completed or rolled back, NTFS records the suboperations of a transaction in a log file before they are written to the disk. When a complete transaction is recorded in the log file, NTFS performs the suboperations of the transaction on the volume cache. After NTFS updates the cache, it commits the transaction by recording in the log file that the entire transaction is complete.

Once a transaction is committed, NTFS ensures that the entire transaction appears on the volume, even if the disk should fail. During recovery operations, NTFS redoes each committed transaction found in the log file. Then, NTFS locates the transactions in the log file that were not committed at the time of the system failure and undoes each transaction suboperation recorded in the log file. No incomplete modifications to the volume are allowed.

NTFS uses the Log File Service to log all redo and undo information for a transaction. NTFS uses the redo information to repeat the transaction. The undo information enables NTFS to undo transactions that are not complete or that have an error.

Important

NTFS uses transaction logging and recovery to guarantee that the volume structure is not corrupted. For this reason, all system files remain accessible after a system failure. However, user data can be lost because of a system failure or a bad sector.


Caching and Data Recovery

The cache is the area of RAM that contains data. When you write data to disk, Windows NT’s lazy-write technique indicates that the data is written when, in fact, it is still in the cache. There can also be cache memory on the disk controller or on the disk itself. The following information will help you decide whether you want to enable the disk or controller cache:

  • Turning on write-caching improves disk performance, particularly if the disk is being heavily written.
  • Control of the write-back cache is a firmware function provided by the disk manufacturer. See the documentation supplied with the disk. You cannot configure the write-back cache from Windows 2000.
  • Write caching does not impact the reliability of the file system’s own metadata. NTFS instructs the disk device driver to insure that metadata writes get written regardless of whether write caching is enabled. Non-metadata is written to the disk normally, so such data can be cached.
  • Read caching in the disk has no impact on file system reliability.


Cluster Remapping

In the event of a bad sector error, NTFS implements a recovery technique called cluster remapping. When Windows 2000 returns a bad sector error to NTFS, NTFS dynamically replaces the cluster containing the bad sector and allocates a new cluster for the data. If the error occurred during a read, NTFS returns a read error to the calling program, and the data is lost. If the error occurs during a write, NTFS writes the data to the new cluster, and no data is lost.

NTFS puts the address of the cluster containing the bad sector in its Bad Cluster File so the bad sector is not reused.


Reparse Points

A reparse point is a file or a directory that has user-controlled data stored in the system-administered reparse attribute. The reparse attribute is used by file system filters to enhance the normal behavior of files or directories present in the underlying file system. Thus, a file or a directory that contains a reparse point acquires additional behavior not present in the underlying file system.

Reparse points enable layered file system filters to add user-controlled behavior to a file or to a directory. The underlying mechanism in a reparse point modifies the typical file name parsing process, forcing its re-start with a new, user-controlled, context. If the reparse point contains private reparse data, this reparse data is returned in an appropriate buffer and made available to all file system filters in the system.

Reparse tags are used to differentiate reparse points. When a file system object with a reparse point attribute is encountered during pathname resolution, it is passed back up the file system driver stack for an I/O reparse. The file system filter handles the I/O reparse, which includes identifying the reparse tag.

When used in conjunction with installable file system (IFS) filters, reparse points enable a wide variety of enhanced file and directory functionality. The following examples show Windows 2000 functionality based on reparse points.

  • Hierarchical Storage Management (HSM)

    HSM uses reparse points to mark files that have some of their state stored remotely. The corresponding file system filter uses the information stored in the reparse point to access, when needed, the part of the state that does not reside in the same location as the file. When a reparse point is used by HSM to denote that part of the state of a file is in remote storage, the reparse point data becomes an extension of the data needed by NTFS to retrieve a file. The reparse point has all the allocation information necessary to identify and retrieve the state of the file that is stored remotely.

  • Directory Junctions

    Windows 2000 uses reparse points to mark NTFS directories that denote a surrogate name. When these directories are encountered during name resolution, they provides a new name to graft into the original name and the name parsing procedure is started again.

  • Volume Mount Point

    This feature enables multiple disk volumes to be linked into a single tree, similar to the way DFS (Distributed File System) links together remote network shares. You can have mayny disk volumes linked together, with only a single drive letter pointing to the root volume.

Note

In Windows 2000, only NTFS directories are marked as junctions that provide a mapping function from one directory name to another. NTFS files are not marked in this manner.

The Windows 2000 I/O subsystem is extensible by installing kernel-level file system filters that enrich the base operations provided by NTFS. These filters are installed in a system-controlled stack. Each filter in the stack has two opportunities to inspect the requests. The first opportunity is when a request is descending through the stack and passes the corresponding layer. The second opportunity is when the request is returning from lower layers ascending the stack. Figure 9.10 illustrates this. Explanations of the numbered steps follow Figure 9.10.

Figure 9.10 Reparse Point Flow Diagram

  1. A user opens Windows Explorer and double clicks on a directory in an NTFS 5.0 volume. The directory happens to have a NTFS Directory Junction reparse point associated with it.
  2. The call goes from user mode to kernel mode where it reaches the file system object and encounters the matching reparse point attribute.
  3. Each installable file system filter driver in the Windows 2000 I/O stack examines the tag associated with the reparse point. If there is a match, the associated file system filter driver intercepts the call. (File system filters examine calls both inbound and outbound. In this example, there is no functionality associated with the inbound call so it is not referenced in the diagram.)
  4. The NTFS directory junction filter driver intercepts the call and executes the enhanced functionality associated with the reparse point. In the case of an NTFS directory junction, the driver mounts another namespace.
  5. The file system driver returns the call to the calling application. Because this example involves an NTFS directory junction, the file system driver mounts another namespace and returns a handle to the calling function.

There are two points to consider in the previous example:

  • If the NTFS directory junction is removed, the reparse point will not be present. The call to open a directory, therefore, will not be intercepted by one of the file system filter drivers in the I/O stack, resulting in normal behavior.
  • If the flag FILE_OPEN_REPARSE_POINT is passed to the CreateFile() call, then the call will bypass the enhanced functionality and simply return a handle to reparse point data, enabling the call to process it directly.

Windows 2000 allows the relative order of the file system stack to be altered. Using information stored in the registry, a filter can be placed above or below another filter. NTFS is always placed below the file system filters that require NTFS as service, and above the device drivers that are used by NTFS.

The Windows 2000 I/O subsystem builds the appropriate data structures to service requests and orchestrates the calling of the layers in turn. After a function has been processed by the stack, the Windows 2000 I/O subsystem examines the result of the operation and either issues further work requests, or fails work requests that have been executing normally.

The value of the reparse point may be modified after it is returned to the calling function. This can happen if there is a handle on the file that did not require exclusive access and one of the following conditions occurs:

  • An IRP arrives and sets the reparse point to a different value.
  • An IRP arrives and deletes the reparse point.


Reparse Point Creation

Reparse points can be established at an empty directory or at a file. NTFS does not create directories or files in a directory that is a reparse point. NTFS also does not create a reparse point when EA attributes are present. If this is attempted, the error status code returned is STATUS_EAS_NOT_SUPPORTED. In addition, NTFS cannot create an EA attribute on reparse points.


Reparse Point Processing

When a file system encounters a reparse point while parsing a file name, it returns its user-controlled contents to the Windows 2000 I/O subsystem, uses the return code STATUS_REPARSE to signal this result, leaves unaltered the file name that was being parsed, and returns the length of the file name that remained to be parsed.

A layered filter in the Windows 2000 I/O stack then has the opportunity to identify and process this information. At the top of the Windows 2000 I/O stack, the Windows 2000 I/O subsystem identifies the name grafting operations and begins the parsing again. The Windows 2000 I/O subsystem fails the file name parsing operation when a reparse point that does not correspond to a name grafting operation reaches the top of the stack of file system filters without having been processed by any of them.

The Windows 2000 I/O subsystem expects the appropriate layered file system filters to handle the appropriate tag. A reparse point with a tag that corresponds to a Windows 2000 system service that is not available during a given period of time cannot be accessed using the open call in normal mode until the service is again available. These reparse points can, however, be enumerated with \$Extend\$Reparse index and be accessed using the FILE_OPEN_REPARSE_POINT flag.


Setting, Deleting and Getting Reparse Points

Reparse points are created by using a set operation; eliminated by using a delete operation, and their contents are retrieved using a get operation. The set, get, and delete operations verify the internal consistency of NTFS as it relates to reparse points.

  • Set Reparse Point

    Windows 2000 I/O has a maximum size constant that limits the amount of data that can be placed in a reparse point to (16 * 1024) bytes. A set operation fails if the amount of data to be placed in the reparse point exceeds this limit.

  • Delete Reparse Point

    The delete operation requires the caller to specify the tag of the reparse point to be deleted. The delete operation fails if the tag specified does not match the one found at the reparse point. When the reparse point delete operation succeeds on a file or directory, the state that identifies it as a reparse point is deleted. The underlying file or directory remains in NTFS, losing its status as a reparse point.

  • Get Reparse Point

    Reparse points are retrieved using a get operation. When the length of the buffer used by the get operation is less than the length of the reparse point data, the reparse point data and the tag field are returned as part of the reparse point data. The information field is used to return the exact amount of bytes copied to the buffer. Thus, layered filters can quickly decode reparse point type by inspecting the tag value returned in the information field.


Reparse Point Access Control

Access control to a reparse point in Windows 2000 follows the existing Windows NT model. While traversing directories, the same checks of traversal rights are made for reparse points as for normal directories. When a reparse point file is found during name resolution, it is checked for read access rights.

Using the existing access control mechanisms of Windows NT, a user who creates directories and files can control whether reparse points may be established or not. A user who establishes a reparse point can control whether the reparse point can be traversed, read, or modified; and by whom.


Reparse Point Issues

Reparse points introduce the following issues:

  • There is no guarantee that a reparse point will successfully resolve. The open call will fail if the corresponding IFS filter driver is not installed. However, Direct CreateFile with the FILE_OPEN_REPARSE_POINT attribute, DeleteFile, and RemoveDir calls will succeed even if the appropriate IFS filter driver is not present or if the reparse point is not resolvable.
  • During directory rename operations, you must differentiate between changing the name of a directory that is the source of a name grafting (thus renaming an underlying reparse point) versus changing the name that is referred to by the name grafting.
  • On individual open operations, Windows 2000 detects file name cycles (cycles created by multiple, consecutive open operations). File name cycles are not a problem on any individual open operation. However, file name cycles caused by files that are opened by multiple, consecutive open operations require detection routines in the application itself. See the Windows 2000 Software Developer’s Kit (SDK) for more information.
  • When HSM is used to store files, system components such as Windows Explorer and applications such as virus detectors must identify RSS reparse points to avoid undesired recalls of high latency migrated files.
  • A directory must be empty for a reparse point to be established there.


NTFS Directory Junctions

Directory junctions provide a very powerful tool for system administrators. An NTFS directory junction is an NTFS directory in which a reparse point with the tag IO_REPARSE_TAG_MOUNT_POINT has been set. The Windows 2000 I/O subsystem uses user-controlled data stored in the reparse attribute to change the name of the object being opened and begin the parse process again. Directory junctions can be resolved to any target namespace—local or remote.

Awareness of NTFS Directory Junctions

When a path name of a file is traversed, all information about a volume where a directory junction was encountered (file system type, free disk space, etc) becomes invalid, as the junction may enter a new namespace. Attributes that might be affected include free disk space, compression, and other known characteristics.

NTFS Directory Junctions vs. Distributed File System Shares

Though Microsoft Distributed File System (DFS) Shares and NTFS directory junctions have some features in common, there are important differences:

  • NTFS directory junctions are tools for grafting local storage volumes or network shares into a single local namespace. DFS is designed to graft network shares into a single DFS namespace.
  • DFS functionality is integrated with the Microsoft Active Directory Service, while NTFS directory junctions are not.
  • NTFS directory junctions rely on NTFS 5.0. DFS does not rely on a file system and is compatible with Windows NT 4.0.
  • NTFS directory junctions do not require a client component, but DFS does.
  • DFS hierarchies offer balancing and fault tolerance via replication across systems; NTFS directory junctions have no inherent load balancing or fault tolerance features as they only resolve to one possible target volume. An NTFS directory junction, however, can resolve to a DFS share.


Volume Mount Points

Volume mount points are new system objects in the internal namespace of Windows 2000 that represent storage volumes in a persistent, robust manner. The combination of an NTFS junction and a Windows 2000 volume mount point can be used to graft multiple volumes into the namespace of a host NTFS volume. Windows 2000 offers this new mounting feature as an alternative to drive letters. This ability allows system administrators to transcend the 26-drive letter limit that exists in Windows NT. Volume mount points are robust against system changes that occur when devices are added or removed from a machine.

Important

A volume is a self-contained unit of storage administered by a file system. The file system that administers the storage in a volume defines a namespace for the volume. A volume mount point is a directory name in an NTFS file system that denotes the root of an arbitrary volume. A volume mount point can be placed in any empty directory of the namespace of the containing NTFS volume. Because volumes may be denoted by arbitrary directory names, they are not required to have a traditional drive letter.

Placing a volume mount point on an NTFS 5.0 directory causes the storage subsystem to resolve the directory to a specified local volume. This “mounting” is done transparently and does not require a drive letter to represent the volume. A Windows 2000 mount point always resolves to the root directory of the desired volume. Volume mount points require NTFS 5.0 because they are based on NTFS reparse points.

Multiple volume mount points can target any volume. Windows 2000 automatically prevents resolution problems due to changes in the internal device name of the target volume name. A mount point is the target volume in the same way a drive letter is the target volume.

The call GetVolumeNameForVolumeMountPoint can be used to retrieve the volume name to which a mount point resolves. In Windows 2000, this volume name does not have to be a drive letter.

Important

To obtain a handle to a volume (as opposed to a handle to the root directory within the volume), omit the trailing backslash of the name that represents the root of the volume. For volume mount points, remove the trailing backslash from the name by using the call GetVolumeNameForVolumeMountPoint.

No additional precautions are required for mount points beyond those already discussed for NTFS directory junctions.


File System Tools

The tools described in this section are available on either the Windows 2000 product companion CD, or the Windows 2000 Resource Kit companion CD. Table 9.9 shows where to find the tools.

Table 9.9 Location of File System Tools

Tool | Location
Cacls | Product CD-ROM
Compact | Product CD-ROM
Compress | Resource Kit companion CD
Convert | Product CD-ROM
Diruse | Resource Kit companion CD
Expand | Product CD-ROM
Expndw32 | Resource Kit companion CD


Cacls: Displays and Modifies NTFS Access Control Lists

You can use Cacls to display or modify access control lists (ACL) of files or folders. Table 9.10 follows the command format and describes the command options. The format of the command is:

CACLS <filename|folder> [/t] [/e] [/c] [/g user:perm] [/r user [...]]
[/p user:perm [...]] [/d user [...]]

Table 9.10 Cacls Tool Options

Option | Description
file name or folder name | Displays ACLs.
/t | Changes ACLs of specified files in the current folder and all subfolders.
/e | Edits ACL instead of replacing it.
/c | Continues on access denied errors.
/g user:perm | Grants a specified user access rights, where perm can be: R (Read) C (Change (write)) F (Full control)
/r user | Revokes a specified user’s access rights (only valid with /e).
/p user:perm | Replaces a specified user’s access rights, where perm can be: N (None) R (Read) C (Change (write)) F (Full control)
/d user | Denies access to a specified user.

Wildcard characters can be used to specify more than one file in a command. You can also specify more than one user in a command.

If you already have permissions set for multiple users on a folder or file and do not use the /e option, all user permissions are removed except for the user and permissions specified on the command line. Use the following syntax when modifying user permissions to include read, change, and full control:

cacls <filename|folder> /e /r <username>
cacls <filename|folder> /e /g <username>:<permission>
cacls <filename|folder> /e /p <username>:<permission>

The Cacls tool does not provide a /y option that answers automatically with Y to the ARE YOU SURE? Y/N prompt. However, you can use the echo command to pipe the character Y as input to the prompt when you are running cacls in a batch file. Use the following syntax to automatically answer Y:

echo y| cacls <filename|folder> /g <username>:<permission>

Important

Do not enter a space between the Y and the pipe symbol (|). If you do, Cacls will not make the permission change.


Compact: Compresses and Uncompresses NTFS Files and Folders

Compact is the command line version of the compression functionality in My Computer or Windows Explorer. Compact displays and alters the compression of folders and files on NTFS volumes. It also displays the compression state of folders. For more information about this tool, type compact /? at the command prompt. Table 9.11 describes the options available with Compact. The format of the command is:

compact [/c] [/u] [/s[:folder]] [/a] [/i] [/f] [/q] [filename [...]]

Table 9.11 Compact Tool Options

Option | Description
none | Displays the compression state of the current folder.
/c | Compresses the specified folder or file.
/u | Uncompresses the specified folder or file.
/s[:folder] | Specifies that the requested action (compress or uncompress) be applied to all subfolders of the specified folder, or to the current folder if none is specified.
/i | Ignores errors.
/f | Forces a specified folder or file to compress or uncompress.
/a | Displays files with the hidden or system attribute.
/q | Reports only the most essential information.
filename | Specifies a pattern, file, or folder. You can use multiple file names and wildcard characters.

There are reasons why you would want to use this tool instead of My Computer or Windows Explorer:

  • You can use Compact in a batch script. Using the /i option enables you to skip files that cannot be opened when you are running in batch mode, such as files already in use by another program.
  • If the system failed during compression or uncompression, the file or folder is marked as Compressed or Uncompressed, even if the operation did not complete. You can force the operation to complete by using Compact with the /f option (with either the /c or /u).

Note

Compact automatically compresses or uncompresses all of the files and subfolders when you change the compression state of a folder. It does not ask whether you want to change the compression state of the files or subfolders in it.


Compress: Compresses Files or Folders

Compress is a command line tool that can be used to compress one or more files. You cannot open a file that has been compressed by using this tool until you have expanded it with Expand or Expndw32. To use this tool, type compress with the appropriate options at the command line. Table 9.12 describes the options available with Compress. The format of the command is:

compress [-r] [-d] source [destination]

Table 9.12 Compress Tool Options

Option | Description
-r | Renames compressed files.
-d | Updates compressed files only if out of date.
source | Specifies the source file. The * and ? wildcard characters can be used.
destination | Specifies the destination file or path. The destination can be a folder. If source specifies multiple files and the -r option is not specified, then destination must be a folder.

Note

Do not use Compress to compress files or folders on NTFS volumes. Instead, compress NTFS files and folders with Compact or by setting or clearing the Compressed attribute in My Computer or Windows Explorer. For information about using My Computer or Windows Explorer, see “Compact: Compresses and Uncompresses NTFS Files and Folders” earlier in this chapter.

Volume Compression Requirements

When you attempt to compress a volume that is very low on free space, the following dialog box may appear:

   Compression Error
   File Manager/Explorer cannot change compress attributes for:
   "path\filename"

Or, if you are running Compact from the command line, the following message may appear:

   "path\filename": There is not enough space on the disk.

These messages indicate that the system needs additional free space to perform a compression. The system is not designed to manipulate the data in place on the disk. Additional space is needed to buffer the user data and to possibly hold additional file system metadata. The amount of additional free space required depends on the cluster size, file size, and available space.


Convert: Converts a Volume From FAT to NTFS

You can use Convert to convert a volume from FAT to NTFS. This tool performs the conversion within the existing volume. You do not need to back up and restore the files when you use this tool.

You cannot convert the Windows 2000 boot partition while you are running Windows 2000, so Convert allows you to convert the partition the next time you start Windows 2000. When you convert the partition this way, Windows 2000 restarts twice to complete the conversion process. The format of the command is:

convert drive: /FS:NTFS [/v]

To use this tool, type convert with the appropriate options at the command line. Table 9.13 describes the options available with Convert.

Table 9.13 Convert Tool Options

Option | Description
drive | Logical drive that you want to convert.
/FS | Specifies that you want to convert to NTFS.
/v | Runs the tool in verbose mode.

Free Space Required to Convert FAT to NTFS

The conversion of a disk partition from FAT to NTFS requires a sufficient amount of available free disk space in order to build the NTFS disk structures. For information about the process Convert uses to convert FAT to NTFS and the space required for conversion, see the Microsoft Knowledge Base.

Converting NTFS and FAT Volumes

FAT and NTFS use very different on-disk structures to represent the allocation of space for files. These structures are often referred to as metadata or file system overhead. Another kind of overhead associated with FAT and NTFS is related to the fact that both file systems allocate disk space in clusters of a fixed size. The exact size of these allocation units or clusters is determined at format time, and the defaults are dependent on the size of the volume.

Like FAT, NTFS has a certain amount of fixed size overhead and a certain amount of per-file overhead. In order to support the advanced features of NTFS, such as recoverability, security, and support for very large volumes, the NTFS metadata overhead is somewhat larger than the FAT metadata overhead. However because NTFS cluster overhead is smaller than FAT cluster overhead, it is often possible to store as much, if not more data on an NTFS volume as on a FAT volume, even without using NTFS file compression.

Convert builds the NTFS metadata using space that is considered free space by FAT. Thus, if the conversion fails to complete, the FAT representation of the user files is still valid.


DirUse: Provides Information About Usage of Disk Space

You can use DirUse to determine the actual usage of space for compressed files and folders in NTFS volumes. The format of the command is:

diruse [/s | /v] [/q:#] [/m | /k | /b] [/a] [/l] [/d] [/o] [/c] [/,] [/*] [dirs]

The important option for compressed folders and files is /c, which causes the display of compressed file or folder size instead of apparent size. For example, if your D drive is an NTFS volume, type diruse /s /m /c d: at the command prompt to get the disk space actually used (in MB) and the number of files in each of the folders. To see compression information for an individual file, open My Computer or Windows Explorer, select the file, and select Properties from the File menu.

For more information about DirUse, type diruse /? at the command line, or see the Windows 2000 Resource Kit Tools Help for information about this tool.


Expand and Expndw32: Expand Compressed Files

You can use Expand and Expndw32 to expand one or more compressed files from your Windows 2000 Resource Kit companion CD or any file compressed by the Compress tool. If you installed the Windows 2000 Resource Kit, you can open the tools one of the following ways:

  • Double-click the Expand Files icon in the File Tools program group.
  • From My Computer or Windows Explorer, open the Expndw32.exe file. This tool is in the folder where you installed the Windows 2000 Resource Kit, and on the Windows 2000 Resource Kit companion CD. Use the version that corresponds to the hardware platform you are using.

For help while you are using the tool, choose the Help button or press F1.

The MS-DOS–based Expand tool runs from the command line. Type the expand command with the appropriate options as shown in Table 9.14. The format of the command is:

expand [-r] source [destination]

Table 9 14 Expand and Expndw32 Tool Options

Option | Description
-r | Renames expanded files.
source | Specifies the source file. The * and ? wildcard characters can be used.
destination | Specifies the destination file or path. The destination can be a folder. If source specifies multiple files and the -r option is not specified, then destination must be a folder.


Planning a Reliable Configuration

Planning a configuration well facilitates data backup and security, maintenance and record-keeping, and the prevention or handling of contingencies, such as system failure or natural disaster. The following discussion includes realistic scenarios and checklists that you can adapt to your organization.

In This Chapter

Planning Considerations

Establishing a Backup Plan

Related Chapters in the Resource Kit

  • For more information about file systems, see the chapter “File Systems” in this book.
  • For more information about recovery, see the chapter “System Recovery” in this book.
  • For more information about the registry, see the chapter “Overview of the Registry” in this book.
  • For more information about security features and policies, see the Microsoft® Windows® 2000 Distributed Systems Guide.


Planning Considerations

When planning a configuration that includes computers running Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Professional, consider the following questions:

  • How many computers running Windows 2000 Server and how many computers running Windows 2000 Professional do you need for your company?
  • Are there computers running operating systems other than Windows 2000 Server and Windows 2000 Professional in your enterprise?
  • Where should the computers be located, and how should they be connected?
  • How many single points of failure can you tolerate in your enterprise?
  • What methods can you implement for fault tolerance—the ability of a system to function when a computer component fails?
  • What data on the computers needs to be backed up, and what is your backup strategy?
  • What records do you need to maintain to troubleshoot problems or recover from failures?
  • Have you developed and tested solutions for emergencies such as fire, flood, or power outage?

For each computer that uses Windows 2000 Server or Windows 2000 Professional, consider these questions:

  • What file system(s) are appropriate?
  • How many controllers and disks are needed, and how should they be configured?
  • Should some data be configured on fault tolerant volumes?
    • If so, should fault tolerant hardware be used on a computer running Windows 2000 Professional or Windows 2000 Server?
    • Or do you want to use the fault tolerant features available with Windows 2000 Server?


Approaches to Planning

Three proven approaches to planning include: top-down execution and responsibility, bottom-up execution and responsibility, and top-down policy and bottom-up planning and execution. Whatever approach you use, ongoing improvement and updates are better than total revision when new information, policies, or procedures occur.

  • Top-down execution and responsibility

    One department in the company is responsible for planning and coordinating policies and procedures. A centralized operations staff might be responsible for all or most computers running Windows 2000 and for executing backups. This method allows for creating a specialized group to develop procedures, procure and install hardware, conduct tests, and train personnel. Two disadvantages to this approach are that the specialists might not understand how data from the various departments relates to the overall business, and each department might not get appropriate attention.

  • Bottom-up execution and responsibility

    Each department is responsible for developing and implementing its own plans. Each department might also be responsible for the computers that its members use and for developing backup procedures. It is the department manager who best understands the impact of data loss. However, this approach can be costly because each department must train its own personnel and do its own research.

  • Top-down policy and bottom-up planning and execution.

    One department develops the planning policy, which includes overall planning guidelines. Each department is responsible for developing and implementing its own plans and procedures. This method offers a consistent approach, which helps to ensure that each department knows the important details for a successful operation.


Planning for Security

It is important to minimize the effects of human error or deliberate sabotage. If anyone can walk up to a computer running Windows 2000 and restart it, no amount of security software can protect your data from being damaged or stolen.

You can implement procedures that restrict physical access to your entire facility or just to certain areas to which various personnel need access. Some ways to protect data include keeping computers in secure offices and requiring a password for screen savers. You can run virus checks on a floppy disk before using it or disable a floppy disk, which can sometimes be done by using BIOS options. You can also run virus checks on a computer or physically disconnect it.

Windows 2000 allows you to create a profile for each user and restrict user access to files and servers. But no amount of planning covers all the ways that users can damage data or the computers themselves. Therefore, security is a crucial part of your backup and storage procedures. For more information about planning backup and storage procedures, see “Establishing a Backup Plan” later in this chapter.

Windows 2000 includes software to write information to a security log and to audit the log for attempts to breach security. You can log access to files and all logon attempts, valid or invalid. Your audit policy determines the types of events that are recorded in the security log. For more information, go to Windows 2000 Help.


Hardware and Software Upgrades

Even though you cannot avoid doing hardware and software upgrades, planning when and how to do them can minimize the time an upgrade takes and reduce the risk of failure. For upgrading information outside the scope of this chapter, see the chapter “System Recovery” in this book.

When doing hardware or software upgrades:

  • Never upgrade without backing up data files that you must have.
  • Be sure to back up the registry, master boot record, partition boot sector, and other critical system data.
  • Have a current Automatic System Recovery (ASR) disk for each computer.
  • Have records of the configuration of the computer, such as jumper and DIP switch settings, interrupt requests (IRQs), and the hard disk configuration.

See the Microsoft® Windows® 2000 Deployment Planning Guide for more information about deploying Windows 2000.


Maintenance and Record Keeping

Routine, planned maintenance can prevent problems or minimize their effects. For example, if there are file system problems, you might not know about them until you restart the computer, when the Chkdsk program tells you that there are errors. Backups can even be corrupt in some situations, because no backup program, including Backup, can detect corrupt user data.

Create a log book for every computer, which should contain information about the computer’s configuration. To make recovery easier, there are several system files that you should back up every time you make certain changes to your Windows 2000 configuration. For information about these topics, see the chapter “System Recovery” in this book.

If you are a system administrator, it is recommended that you check both the system and application event logs on a daily basis. Impending file system problems might show up as errors in the system log before the file system is corrupt. Be sure to investigate any messages in the event log from FtDisk or disk device drivers.

Disk fragmentation can cause performance problems. You should consider running a defragmentation program on a regular basis. There are third-party defragmentation utilities that run under Windows 2000 and can defragment the file allocation table (FAT) and Windows NT file system (NTFS) volumes. Be sure to only use utilities that are designed for Windows 2000. InfoSource, a Microsoft directory for Windows 2000, contains information about hardware and software programs, including defragmentation utilities. More information about InfoSource is available on the Web, at http://www.microsoft.com.


Maintaining Reference Information

It is strongly recommended that you create a technical reference library for all hardware and software documentation. This library can also include other documentation related to your computers that you want to have in a central location. The types of information for this library are:

  • Vendor documentation, including manuals, receipts, warranties, proofs of purchase, and so on
  • Insurance policy and any claims
  • Information about any kits, tools, and add-ons that you have installed
  • All internal documentation that you have generated, including policies, procedures, training guides, and so on
  • Hardware configuration information for each of the computers, including, but not limited to, the following:
    • Their location, cabling, intermediary devices, and external connections
    • Computer type as well as model and serial numbers of system components
    • Computer BIOS manufacturer and revision level for x86-based computers or firmware revision level for DIGITAL Alpha computers
    • Complementary metal-oxide semiconductor (CMOS) information for x86-based computers
    • Firmware information about DIGITAL Alpha computers
    • For each component, information such as IRQ, direct memory access (DMA) addresses, and the I/O port
    • Amount of parity or nonparity RAM
    • Information about the video display and the video card
    • Complete configuration of the disk subsystem, including the makes, models, and serial numbers of all disks and controllers, and their type, such as Small Computer System Interface (SCSI) or Enhanced Integrated Device Electronics (EIDE)
    • Configuration information for other storage media, such as tape, optical disk, or removable disk
    • Types and configuration of network cards
    • Configuration information about any other adapters, such as multiple port adapters
  • Software configuration information and backups for each computer, including:
    • Disk map, noting location and size of each partition and logical drive
    • Backups of each master boot record and partition boot sector
    • Windows 2000 startup floppy disk
    • Windows 2000 versions installed and the partitions on which they are installed
    • User information, including which users are allocated disk space and what utilities and application programs they are using
    • Backups of the system configuration files, including the registry
    • Which application programs are installed on which volumes
    • Licensing information
  • Current telephone numbers to contact, including:
    • Appropriate personnel for problems or emergencies
    • Administrators
    • Vendors and consultants
    • Managers
    • Critical users


Disaster Planning

Just as every business needs to plan and budget for future growth, you need to plan for dealing with total or partial loss of business data. To determine what provisions to make for partial or complete loss of data, you need to estimate the approximate cost in time and money to rebuild or replace critical data. Consider the following questions:

  • Do you know the cost of reconstructing your company’s financial, personnel, and other business data?
  • Do you know if your business insurance would cover any or all of the cost of replacing data?
  • Do you know how long it would take to reconstruct your business data? How might this affect future business?
  • Do you know the cost per hour of computer downtime?

To prevent a natural disaster or sabotage from becoming a financial disaster for your business, test your plan for recovering and restoring critical data. Keep copies of your disaster recovery plan at on- and off-site locations. It is also recommended that key personnel keep a copy of critical data at home.

Because many books and magazine articles discuss disaster planning and recovery in detail, this section suggests topics to explore further instead of presenting detailed disaster plans to implement. Your insurance company can provide you with current and specific information for your situation.

Following are some important issues to consider when you develop a comprehensive disaster plan to incorporate into your daily operations.

  • What data do you need to back up and how often should you do backups?
  • What critical computer or other hardware configuration information, not saved during normal tape backups, should be saved?
  • What data needs to stored on- or off-site, and how should it be stored?
  • What training enables operators and administrators to respond quickly and effectively in an emergency?

For more information about the preceding topics, see the chapter “System Recovery” in this book.


Contingency Planning

This section identifies topics you should consider in your contingency planning.

Estimating Replacement Costs

There are several ways to measure costs. Some are obvious and easy to calculate, such as:

  • Replacement of file servers, mail servers, or print servers
  • Replacement of servers running applications such as the Microsoft® SQL Server™ or the Microsoft® Systems Management Server
  • Replacement of gateway servers running Remote Access Service (remote access), Microsoft® SNA Server, Proxy Service, or Novell NetWare
  • Workstation replacement for personnel
  • Replacement of computer components, such as a hard disk or network card
  • Replacement of perishable products gone to waste

Far more difficult to measure, but just as devastating, are the invisible costs of computer downtime, such as:

  • Lost sales
  • Lost customer goodwill
  • Lost employee productivity and confidence
  • Increased costs because of makeup time
  • Missed contractual obligations or possible legal liabilities
  • Loss of competitiveness

If you have kept records of failures, you might find them useful in your contingency planning. You can investigate ways to avoid each failure, or to minimize the downtime associated with the failure. If you have cost information for the failures, you can then compare the cost of each failure to the cost of preventing or minimizing the failure. Table 11.1 describes two examples of failure.

Table 11.1 Examples of Failure

Example | Failure One | Failure Two
Failure description | File server in sales department down, network card failure. | Router failure between development and testing department.
Effect | Lost sales | Lost productivity of employees.
Total downtime last year. | 3 hours | 16 hours
Costs of failure per hour. | $10,000 | Average hourly wage of 10 affected employees is $18/hr.
Annual downtime costs. | $30,000 | $2,880
Possible resolution or workaround. | 3 spare network cards @ $500 each. | Put an alternate router in place or obtain a spare router.
Expected costs of resolution or workaround. | $1,500 | $500 – $2,000
Estimated savings during first year with resolution in place. | $28,500 | $880 – $2,380

Avoiding Computer Component Failure

Typically, server failure is the most costly for a business, whether it is a file server, a print server, or an applications server. The following discussion of computer components can help you make decisions about how to configure company computers and when to run diagnostic tests on various components.

Motherboard and Central Processing Unit

Motherboards consist of electronics that can and do fail, yet the motherboard and the CPU are the more reliable computer components. There is little you can do to avoid a motherboard failure or CPU fault, except to run regular system checks to ensure that the components are functioning correctly. Some vendors provide systems with built-in diagnostic tools that operate with Windows 2000.

RAM

There are three major types of RAM that deal with error detection and correction.

  • Parity RAM

    Parity RAM has an extra bit that indicates if each byte in the RAM is good or faulty. When parity RAM detects a parity difference, it signals the CPU through a nonmaskable interrupt (NMI). Depending on where and when detection happens, Windows 2000 determines if this is an input/output (I/O) board parity error, memory bus error, or some other kind of parity error. Windows 2000 can also report I/O channel parity errors from cards in slots. You get an error message in these cases, and sometimes the computer stops.

  • Error-corrective coding (ECC) RAM

    High-end systems often use ECC RAM, which can detect a two-bit failure and correct a single-bit failure in the system memory. Windows 2000 continues to run in spite of a single-bit failure. Depending on the hardware design, there might or might not be a report of this corrective action.

  • Nonparity RAM

    If you use nonparity RAM, Windows 2000 has no way to detect memory problems, and your computer might crash randomly. Nonparity RAM costs less than parity RAM, and parity RAM is not available for all computers. If you do not have parity RAM in your computers, ask your vendor if parity RAM can be installed or supported by the computer.

There are a few vendors that supply products that you can use to check the RAM in a computer.

Video Cards

Video cards drive the screen as well as render images for display. Video cards rarely cause a computer to fail, but rather, might cause the computer to behave erratically, which can be confusing to diagnose. More often, video cards cause screen painting problems, application page faults, and the like. Such problems are typically not critical enough to require you to shut down the computer. To minimize video problems, be sure that your computer is running with the most recent release of a supported video driver from Microsoft or the third-party vendor of the video card.

Disks and Disk Controllers

You should investigate Integrated Device Electronics (IDE), EIDE, and SCSI technologies because each offers different benefits for fault tolerance and recovery. You have many choices for your disk configuration, including fault tolerant configurations. The meantime between failures (MTBF) gives you a measure of expected disk and controller reliability. For more information, see the chapter “Fault Tolerant Systems” in this book.

Be sure to run disk and controller diagnostics during every preventive maintenance check. Diagnostics are typically available from your hardware vendor. Windows 2000 automatically runs the Chkdsk program every time you start up, and you can run a surface scan of the disks by specifying chkdsk /r.

Network Cards

Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), and Asynchronous Transfer Mode (ATM) network cards can have dual channel connections. If one channel fails, the other channel is automatically used.

Ethernet and Token Ring network cards do not have a dual channel capability. If the manufacturer provides a diagnostic program, it is recommended that you run diagnostics on the network cards during scheduled preventive maintenance or downtimes.

You can evaluate network segments with network packet trace programs, called sniffers. The Windows 2000 Network Monitor can check for:

  • Bad cyclic redundancy checks (CRC)
  • Corrupted packets
  • Bandwidth saturation caused by a broadcast intensive network card

Protection Against Power Failure

To protect data from damage or loss due to power outages or fluctuations, consider purchasing an uninterruptible power supply (UPS). Windows 2000 supports different kinds of UPS. Windows 2000 can send messages to users to save data and log off as soon as UPS signals an impending shutdown. For more information about the Windows 2000 UPS service, see “Avoiding Single Points of Failure” later in this chapter.

To prevent power surges that can destroy data, use quality power-surge suppressers.

Causes of Disrupted Network Connections

If users cannot connect to the computers in a configuration that runs Windows 2000 Server, that configuration is not fault tolerant. You need to consider what can fail in the connections between computers as well as within an individual computer.

Network Cabling

If your company is growing, the connections between the computers that make up your configuration could become saturated with network traffic. It is recommended that you evaluate network traffic regularly to determine your need to upgrade by adding equipment. You can also use newer technologies, such as FDDI, CDDI, ATM, or Fast Ethernet 100 Base T.

Intermediary Devices

Devices that connect different segments of your network, such as routers, bridges, hubs, and switches can also be bottlenecks and points of failure. It is recommended that you protect intermediary devices with a UPS.

For each device, find out whether you can get the vendor support you need. You also need to know the standards supported by each of the devices, and whether the vendor has a migration path for new standards. You should also find out if there are frequent software changes.

Electric Wiring and External Network Connections

If you lease an X.25 connection, an Integrated Services Digital Network (ISDN), or T1 line to connect to another building, branch, or subsidiary of your company, verify that your line vendor has recovery procedures in place that can guarantee minimum downtime for the line.

Climate Control

If the weather at the location of your company requires heating or cooling within the building to keep your computers and network devices within required operating temperatures, consider making the climate control system fault tolerant as well.

Software Failure

Find a vendor who can provide the support you need in case of software failure. If your company does not already have a technical support group to assist users when there are software problems, form one.

Assessing the Probability of Failure

MTBF information supplied by some equipment manufacturers is probably useless unless you do extensive analysis and modeling based on your company’s pattern of use. Thus, it is recommended that MTBF information be used only as a relative measure of reliability.

More useful than MTBF information is a record that you keep of past failures and their causes. That information can help you categorize failures by type, such as:

  • Hardware failure on a server, client, or network component
  • Software failure of the operating system or applications on a server or client
  • Administrative error
  • User error
  • Deliberate damage, such as sabotage or a virus

Some questions to ask about failures include:

  • Have you taken action to reduce the recurrence of each recorded failure?
  • What was done or could be done to solve the problem?
  • How long would or did the solution take?
  • What would or did the solution cost?
  • What changes have you made that might affect the number of failures?

    Changes might include the size of local area networks (LAN) or wide area networks (WAN), or the number of:

    • Servers
    • Clients
    • Users
    • Administrators
    • Intermediary devices
    • External connections

While it’s more difficult to manage many computers than just a few, a few computers all connected to just a few servers results in high-impact downtime.


Avoiding Single Points of Failure

Computers running Windows 2000 Server have fault tolerance features built-in to the operating system. Typically, fault tolerance applies to disk subsystems, but it can also apply to other parts of a system or an entire system. For example, fully fault tolerant computers use redundant disk controllers and UPS as well as fault tolerant disk subsystems.

Although data is always available and current in a fault tolerant disk configuration, you still need backups to protect data on a disk subsystem from:

  • User error
  • Sabotage
  • Software malfunction
  • Catastrophe such as a fire, earthquake, or flood

Disk fault tolerance is not an alternative to a backup strategy with off-site storage. For more information about disk fault tolerance, see the chapter, “Fault Tolerant Systems” in this book.

Keeping replacement disks and controllers available on-site is cost-effective. For example, SCSI controllers cost as little as a few hundred dollars, while the cost of keeping 50 to 500 users while waiting for a replacement can be thousands of dollars.

Consider providing UPS protection for individual computers and the network itself, including hubs, bridges, and routers. Windows 2000 has UPS support on individual computers. UPS support typically provides power from five to twenty minutes, long enough for Windows 2000 to do an orderly shutdown when power fails. If your company has a history of frequent or prolonged power outages, investigate alternative power sources for critical computers besides the local power company. It is important to remember that even a UPS for every computer on the network does not necessarily prevent data loss or corruption due to power fluctuations. The network is itself an electrical system. Intermediary devices such as routers, bridges, and hubs, require the same UPS protection in order to prevent loss of network functionality.

For more information about UPS, see the chapter “System Recovery” in this book.

Tip

Minimize the number of components whose failure can cause the computer to fail. For information about computer components and reducing the risk of failure, see “Contingency Planning” earlier in this chapter


Establishing a Backup Plan

Regular backup of servers and local hard disks prevents data loss and damage caused by disk drive failures, power outages, virus infection, and many other possible computer problems. Backup operations based on careful planning and reliable equipment make file recovery easier and less time consuming.

When developing your backup plan:

  • Be sure to have spare hardware in case of a failure in your backup device.
  • Test backed up data regularly to verify the reliability of your backup procedures and equipment.
  • Include stress testing of backup hardware (storage drives, optical drives, and controllers) and software (backup program and device drivers).

When you use Backup, determine the appropriate:

  • Data to back up
  • Hardware to get
  • Location for your tape drive or library
  • Type of backup procedure to use
  • Backup schedule to follow
  • Place to store backup media


Storage Devices and Media

Windows 2000 can back up files to a variety of storage devices, including a tape drive. Data can be backed up to a logical drive, removable disk, recordable CD, or a library of disks or tapes organized into a media pool and controlled by a robotic changer. If you do not have a separate storage device, you can back up to another hard disk or to a floppy disk.

Storage Devices

Storage technology changes rapidly, so it is important to research the merits of various media before you make a purchase. Consider drive and media costs, as well as reliability and capacity, when selecting a storage device. Ideally, a storage device has more than enough capacity to back up your largest server and can also detect and correct errors during backup-and-restore operations. For information about supported storage devices, see the Windows 2000 Hardware Compatibility List on the operating system CD.

Tip

The best way to make sure that your storage devices and media are working correctly is to verify your backups by doing test restores.

Tape

The most common medium for backups is magnetic tape. Tape is popular because it offers great capacity at low cost. The primary tape drives used for backup include a quarter-inch cartridge (QIC), digital audio tape (DAT), and 8-mm cassette. High-capacity, high-performance tape drives typically use SCSI controllers.


Backup Strategies

A good backup strategy is the best defense against data loss. Here are three backup strategies with questions to consider when determining what is appropriate for your computer system.

  • Network backup or server only

    Do you plan to back up your entire network, or to have storage devices attached to certain servers where users copy their important files?

  • Individual or local workstation backup

    Does each workstation need a storage device, and is each user responsible for backing up his or her data?

  • Server and workstation backup

    Does each department have a storage device and a designated user to back up all data for that department?

You can cable your storage device to a workstation or to a server. Tables 11.2 and 11.3 list some advantages and disadvantages to either configuration and point out important trade-offs to consider when implementing a strategy.

Table 11.2 Server-Only Backup

Advantages | Disadvantages
Fewer storage devices are needed. | Registries and event logs of remote computers are not backed up.
There is less media to manage because shared media stores multiple backups. | Backups and restorations are slower, due to network throughput.
If every server has more than one workstation, server-only backup costs less than backing up individual workstations. | Backups and restorations require greater planning and preparation. They must be scheduled when network traffic is at a minimum or when critical information can be backed up as quickly as possible.

Table 11.3 Local Workstation Backup

Advantages | Disadvantage
Fewer network resources are committed to a lengthy backup procedure. | Using more storage devices costs more.
File recovery is quicker. |

Server and workstation backup combines the advantages and disadvantages of server-only and local-workstation backups. Additional considerations include the following:

  • If you run backups from a server, you can back up and restore that server very quickly. But if your network has more than one server, the speed advantage is lost.
  • Servers typically operate 24 hours a day, so it is possible to run backups during off hours. However, if a problem with backup hardware occurs, you might have to turn off the server.
  • As a rule, if data is primarily on one server, it is better to run backups from that server.

Note

Whether you run remote backups from a workstation or a server, it makes sense to place the storage device on the portion of your network with the greatest bandwidth or highest transmission frequency. You might also consider keeping the storage device in a secure room.

Figure 11.1 illustrates local workstation and server-only backup options for a tape drive.

Figure 11.1 Workstation and Server Backup Configurations

Caution

Backups protect data against viruses. Because some viruses take weeks to appear, it is recommended that you keep normal backup tapes for at least a month to make sure that you can restore a system to its uninfected status.


Security Considerations

This section suggests ways to enhance the security and smooth operation of your backup-and-restore operations. Also included are suggestions for securing your backup media.

When you form a backup plan, consider implementing the following methods:

  • Secure both the storage device and the backup media. Data from stolen media can be accessed and restored to another server.
  • Back up an entire volume to prepare for the unlikely event of a disk failure. It is more efficient to restore the entire volume in one operation.
  • Always back up the registry on a domain controller to prevent the loss of user accounts and security information.
  • Keep three current copies of backup media. Store at least one copy off-site in a properly controlled environment. For more information about media storage, see the section titled “Storing Backup Media” later in this chapter.

Caution

If you implement physical security to protect your computers, but unauthorized people can access your backup tapes, your data is not protected.

Backup-and-Restore Rights

Backup-and-restore rights are independent of each other. However, you can grant both rights together.

If you are the system administrator, extend backup and restore rights only to persons responsible for backing up your network. In a minimum- or medium-security network, grant one user backup rights and another user restore rights. Train personnel with restore rights to perform all restore tasks in the event that you are unavailable. In a high-security network, only you should restore files.

Caution

A person who does not have permission to write to a file might have permission to restore the file. During restoration, such permission conflicts are ignored, and the existing file can be overwritten.

File Permissions

In Windows 2000, access to NTFS files is limited by NTFS file permissions, share permissions, and file attributes. You cannot backup or restore NTFS files you do not have access to unless:

  • You belong to the permissions group of administrators, backup operators, or restore operators
  • You have been granted user rights to Backup files and directories and Restore files and directories.

Note

Neither the FAT16 nor the FAT32 file systems provide file permissions.

Granting Rights at Large Sites

Large sites might have two groups of backup operators: one with backup rights only, the other with backup-and-restore rights. It is recommended that you:

  • Grant backup-only rights by creating a local group named Backup Operators and give members Backup files and directories user rights. Then, create a global group named Backup Only and add it to the local group.
  • Grant restore-only rights by creating a local group named Restore Operators and give members user rights Backup files and directories user rights. Then, create a global group named Restore Only and add it to the local group.

Storing Backup Media

Some kinds of information should be stored near your computers to be readily available. Some data should be stored off-site to be available in the event of a disaster or for long-term storage. This section is based on the assumption that you use Backup or a similar data backup program.

Caution

Backup media lasts longer in cool, humidity-controlled locations. Your storage area should also be free of magnetic fields, such as those near the backs of computer terminals and analog telephones.

On-Site Storage

Some data needs to be stored on-site and readily available in the event of a failure.

  • Daily backups, whether full or incremental

    Media should be stored in a fireproof safe or cabinet. Secure storage protects against natural disaster, theft, and sabotage.

  • Copies of the media

    CDs are not easily copied. If more than one copy of a software program is purchased, store one off-site if possible. If you have only one copy, you can back it up to media and label it as a backup of the application. If you need to reinstall software, you can restore from media to a computer running Windows 2000. You can then run the application program setup over the network and delete the software from the server.

Off-Site Storage

For highly confidential data that must be stored off-site, consider assistance from a company that specializes in secure data storage. Such companies lease space in underground vaults that remain impervious to just about everything. If the cost or logistics of such protection is too great, use an alternative solution, such as a bank safe-deposit box or an off-site fireproof safe, designed to protect magnetic media.

It is recommended that you store the following types of information off-site:

  • A full backup of the entire system, best done weekly
  • Original software installed on computers (only copies kept on site)
  • Documents required for processing an insurance claim, such as purchase orders or receipts for computer hardware and software (pertinent information available from your business insurance agent)
  • Information required to get network hardware reinstalled or reconfigured

Tip

Check with your phone company or other supplier of data transmission lines to find out how you can help them get your service back online as quickly as possible. Also, make sure that your off-site storage location is bonded.


Backup Strategies

There are two extremes when backing up data on computers running Windows 2000: One is having a small, simple network with a computer that must be backed up and also be available 24 hours a day, 7 days a week; the other is having a computer with a large amount of data to back up. This section discusses backup strategies for these two situations.

Small and Medium LANs

The following scenario illustrates a possible approach for backing up a small network comprised of a Windows 2000 Server computer and 20 client computers:

  • The situation

    The clients are a mix of computers running MS-DOS, Windows for Workgroups, Windows 95 or Windows 98, and Windows 2000. You plan to purchase one tape drive and a controller card and use Backup.

  • An approach

    You can work out a backup solution by following these four steps:

    1. Research and select a tape drive for its reliability, speed, capacity, cost, and compatibility with Windows 2000. The drive should support tape cartridges with more than enough space to back up your entire server.
    2. Locate your tape drive at the server so that you can back up the server registry and server backups can take place as quickly as possible. From the server, you can back up user files on remote computers running only Windows for Workgroups, Windows 95 or Windows 98, and Windows 2000.
    3. Install the tape controller card in the server, and attach the tape drive. Be sure that the tape drive is turned on before turning on the server so that the SCSI tape driver can be loaded properly.
    4. Establish a tape rotation schedule for backing up computers running Windows for Workgroups, Windows 95 or Windows 98, and Windows 2000 Professional. To conserve tapes, back up client computers less frequently than the server and, space permitting, encourage users to copy critical files to the server at the end of the day. Figure 11.2 shows a possible tape rotation schedule.

Figure 11.2 Possible Rotation Schedule for Backup

For examples involving media pools and changers, see the chapter “Storing and Managing Data” in this book.

Caution

Data from computers running Windows 2000 Professional must be backed up on the computer running Windows 2000 Server because no backup devices are connected to those computers.

Backup does not back up files on MS-DOS computers. Consider reserving some space on the server so that MS-DOS and Windows 3.1 users can copy important files. Those files would be backed up during regular server backups.

Methods for 24-Hour Operations or Very Large Backups

If you need to back up a great amount of data, such as an SQL database or a number of large graphics files, it may take a long time. Consequently, files being backed up may be locked when clients try to access them the next morning. When the time available for backups is short, the approach that works for small and medium-sized LANs is inadequate.

You can configure the disks that require daily backup separately from the Windows 2000 system disks by using redundant array of inexpensive disks (RAID) arrays. For critical computers, you can implement a software mirror of two separate hardware-controlled RAID arrays. With this configuration, if either a disk or an entire array fails, operations continue. If a component such as a network adapter, video device, IDE adapter, or power supply fails, it can be easily replaced. It is recommended that you have a spare computer with Windows 2000 Server installed as a back up for data, in case the computer running Windows 2000 Server fails.

Note

RAID arrays provide disk fault tolerance as part of the hardware that you purchase from a vendor. In RAID arrays, the controller interface handles the creation and regeneration of redundant information that is automatically used if a failure occurs in one of the disks in the array. For more information about RAID arrays, see the chapter, “Fault Tolerant Systems” in this book.

One approach to backing up data on a critical computer running Windows 2000 involves logically removing the computer from the network by:

  • Disconnecting all users
  • Interrupting the server service by using the Services option on Control Panel
  • Ensuring that all files are closed so that they can be accessed by the backup procedure

The following three methods are variations on the preceding approach. The first two methods can be used to back up data after you remove the critical computer from the network. In all three methods, the computer that contains the data to be backed up is called DATA. The computer that actually does the backup is called TARGET. Unlike the first two methods, the third method allows users to continue to access data on DATA while DATA is being backed up.

Backup Method One

To minimize the time that DATA is unavailable to users, copy the data to be backed up from DATA to TARGET. When the data is in NTFS volumes, you can use Scopy (a program on the Microsoft Windows 2000 Resource Kit companion CD) to copy permissions as well as data. If you do not need permissions, you can use Xcopy (a program on the Microsoft Windows 2000 Professional and Server Fundamentals Resource Kit companion CD) to copy data only. To copy database files, use the functions in the database application. If you expect the network to be busy when you copy data, you can dedicate a computer-to-computer link. After the data is copied to TARGET, you can bring DATA online and do a back up from TARGET to DATA.

Note

While Scopy does not support copying only the files that have been modified, Xcopy does. However, Xcopy does not copy the file permissions. You need to decide whether Scopy or Xcopy is better for your situation, or whether a different program is more appropriate.

It is recommended that you do a complete file comparison between the data on DATA and TARGET to verify the transferred data. However, comparing data takes about twice as long as copying data. Typically, Ethernet or Token Ring transfer speeds are 1 MB per second if the network is not busy. You can use this transfer rate and the total amount of data to transfer to estimate the transfer time. If necessary, you can use a faster network connection or a different backup method.

Backup Method Two

Copy the data that you want to back up to another disk or disks on DATA. Typically, copying files to DATA is faster than copying to another computer over the network. You can then bring DATA online and copy the data to be backed up by using a backup device connected to DATA. Or you can copy the data to TARGET and do the backup from TARGET.

Whether you want to do the backup from DATA or from TARGET depends on factors such as:

  • The availability of a target computer
  • Your backup policy, which might specify that all backups be performed on a few designated computers.
  • The time and cost of doing the backup from DATA versus the time and cost of transferring files to TARGET.

Backup Method Three

There are third-party utilities that mirror data across the network onto another computer running Windows 2000 while the files are being used on DATA. Mirroring data is best when you absolutely cannot risk losing data because a disk or RAID array fails. While there might be some downtime due to moving data from the mirror computer to DATA after a failure on DATA is fixed, downtime is preferable to losing all data created or changed since the last backup. Again, performance is better if a network link is dedicated to this task. The other advantage of method three is that the files being backed up remain available, and copying causes no downtime.


Establishing a Backup Schedule

The frequency with which you create backups depends on how often your data changes and how valuable your data is. Backups can consist of a weekly backup, a monthly backup, and an archive backup. The archive backup can be a simple copy rather than a complete backup. This section describes a twelve-week schedule and a one-year tape-alternation schedule.

The Twelve-Week Schedule

The twelve-week schedule uses a different backup tape each day for two weeks, and then the first tape is used again at the beginning of every third week. Incremental backups are performed Monday through Thursday after an initial normal backup. Normal backups are performed Friday, with the most recent normal backup stored on-site, as illustrated in Figure 11.3. The normal backup of the preceding week is stored off site. At the end of twelve weeks, the cycle starts over with a new set of tapes.

Figure 11.3 Backup Rotation for a Twelve-Week Schedule

The Twelve-Month Schedule

One popular tape-alternation schedule uses 19 tapes over the course of one year. Four tapes are used Monday through Thursday for incremental, or differential, backups, and three tapes are used for the weekly normal backups (performed Friday). Figure 11.4 shows one month of the twelve-month schedule. The remaining twelve tapes are used for monthly normal backups and are stored off-site.

Figure 11.4 Backup Rotation for One Month in a Twelve-Month Schedule

Note

You can lower backup costs by alternating backup media. The life cycle of a tape depends on the manufacturer and on storage conditions.


Developing Backup-and-Restore Procedures

Backup specifics and procedures vary according to the needs of a company. After you develop your procedures based on the considerations discussed in this section, it is important to test, document, and verify them. Periodically reviewing your backup-and-restore process is a key part of ensuring data security.

Considerations for Developing Procedures

This section offers a series of checklists—suggestions and questions—to serve as flexible guidelines when you develop a comprehensive backup-and-restore process for your company.

Delegation of Tasks

Being able to count on people for doing the tasks involved in maintaining your backup-and-restore operation is critical to its success. Consider these questions when deciding how to delegate tasks:

  • Who makes the policy that determines what files and computers are backed up, and how is the policy made known?
  • If the responsibility for doing backups is not part of someone’s job description, who is responsible?
  • If backups occur automatically, who handles interruptions such as error messages?
  • Who does the backup when the assigned backup operator is unavailable?
  • To whom is the success or failure of a backup reported?
  • Who notifies the users if a backup fails?

Important

Develop backup procedures specifically for the registry so that people understand its role in the backup process.

Time-Sensitive Backup Questions

In addition to determining when and how often backups take place, it is important to know how long it takes to retrieve backup media and perform a restore. To determine this, ask yourself the following questions:

  • Do all backups, both full and partial, occur outside regular business hours?
  • Should a backup occur immediately after or before regular business hours?
  • How often do you do full backups and incremental backups?
  • How long does it take to retrieve backups or copies from a local or remote storage area? Can the remote copies be obtained at any time or only during business hours?
  • How long does it take to do a full restore if the computer fails?

In the Event of a Backup Problem

Before a backup problem occurs, consider the following questions:

  • Who is notified if a problem or backup failure occurs, and what process should the notified person follow?
  • If backup fails because of hardware problems, is standby hardware on-site or available on loan from your vendor?
  • How long does it take to replace the failed hardware?
  • Is technical support for hardware available from the vendor at all times?
  • When is software technical support available?
  • Does your technical support staff have configuration information about computers running Windows 2000? If not, how long does it take to provide information when a problem occurs?
  • How do the policies of hardware or software vendors affect how long fixes take?
  • In the event of a backup failure, can the backup operator(s) contact the responsible person(s) by telephone or pager?
  • If trained personnel monitor overnight backups, how are they scheduled for the next day? Who covers their other duties while they troubleshoot backup problems or do lengthy restores?

Security Considerations

The security of your backup operations, as well as the security of the storage location, is of paramount importance. The following questions concern the security of company data:

  • Where are the backup tapes stored?
  • What has been done to make the backup location secure in the event of fire, flood, theft, or another disaster?
  • How is the backup location monitored?
  • Are the tapes that are stored on-site always accessible to the people who need them?
  • If there are copies of backup media, where are they stored?
  • Is the backup location bonded?

Policy Considerations

Developing a backup-and-restore process and deciding what to back up requires that you either set or comply with company policy. Ask yourself these questions:

  • What is the policy for backup, and how is your plan in compliance?
  • Are all modified files to be backed up, or does company policy specify only critical files or the files of certain users, groups, departments, or divisions?
  • Are some disks or volumes on the computer running Windows 2000 not to be backed up?
  • Are users responsible for backing up of their own client systems?
  • Is there a charge back system for the amount of storage used?
  • How is the backup process validated?

Technical Considerations

You also need to determine how your backups are done:

  • Are logs created and are they correct?
  • If the path is long, the filename odd, the file size very large, or the number of files large, does the backup still work? Can you restore files that have these characteristics?
  • Is the backup done to a local tape drive, remotely over the LAN, or remotely over the WAN?
  • How is the backup started—from the command line, an icon, or by batch?
  • How are the connections between data source and the storage device verified before the backup begins?
  • How are computers equipped for power outages if operators are not present when backups take place?
  • Do backups occur on schedule?
  • Does the tape verify that the backed up data is correct?
  • Does the system have to meet certain conditions before the backup starts?
  • What is the process for dealing with an unforeseen occurrence during a backup or restore?

Testing Considerations

Testing and verifying are vital to the success of the backup-and-restore process. The following questions are intended as a means to assess your verification strategy.

  • Has every option that you expect to use been tested?
  • If you use automated backup instructions, do they work?
  • Does the backup-and-restore process work properly?
  • After you make changes to the operating system (such as installing a service pack), or the backup program, does the backup-and-restore process work properly?
  • After you make hardware changes (such as installing a new controller or tape drive, or changing the BIOS on the motherboard) does the backup-and-restore process work properly?
  • When you change the hardware or software involved in a backup, how do you verify that you can use the old tapes?

Testing Backup-and-Restore Procedures

The importance of backups requires complete verification of the entire backup-and-restore process. Develop backup-and-restore strategies with appropriate resources and personnel, and then test them. Testing backup strategies also demonstrates how much time is required to restore data. A good plan ensures fast recovery of lost data.

Perform a trial restoration periodically to verify that your files are properly backed up. A trial restoration can uncover hardware problems that do not show up with software verifications.

After a backup strategy has been designed, it should be thoroughly tested with as many simulated failures as possible. You need to be sure that nothing can jeopardize the recovery of data. For example, you can implement disk mirroring with multiple disks in a computer so that if a mirrored disk drive fails, the disk it mirrors continues operating without interruption. Although disk mirroring is a good plan, it does not eliminate the need to do backups. For instance, a data recovery plan based on disk mirroring alone offers no protection if a computer is stolen.

Documenting Backup-and-Restore Procedures

Keeping accurate backup records is essential to finding missing information quickly, particularly if you have accumulated a large number of high-volume media. Thorough records include media labels, catalogs, and online log files and log books.

Media labels

Labels should contain a date, the type of backup (normal, incremental, or differential), and a list of contents. Indicating the type of backup is important. If you are restoring from differential or incremental backups, you need to locate the last normal backup and either the last differential backup or all incremental backups created since the last normal backup. Alternatively, you can label media sequentially and keep a log book of media content.

  • Catalogs

    Most backup software includes a mechanism for cataloging backup files. Backup automatically stores backup catalogs on the backup media and temporarily loads them into memory. Catalogs are created for each backup set (a collection of backed up files from one drive). Catalogs of the backup set cannot be printed or saved to disk.

  • Log files

    Log files include the names of all backed up and restored files and directories. A log file is useful when restoring data because you can print or read it from any text editor. Keeping printed logs in a notebook makes it easier to locate specific files. For example, if the tape containing the catalog of the backup set is corrupt, you can use the printed logs to locate a file.

Verify Operations

A verify operation compares the files on disk to the files on backup media. It occurs after all files are backed up or restored, and it takes about as long as the backup procedure itself. It is recommended that you perform a verify operation after every backup, especially if you back up to a set of media for long-term storage. A verify operation is also recommended after file recovery.

Note

If a verify fails for a given file, check the date that the file was last modified. If someone changes a file between a backup and a verify, the verify fails.


Evaluating Memory and Cache Usage

Use Performance Monitor and other Microsoft® Windows® 2000 tools to assess available memory and to observe the effects of a memory shortage, a common cause of poor computer performance. Examine the effectiveness of the file system cache — an area of physical memory where recently used data read from or written to the disk is mapped for quick access. In addition, use Windows 2000 tools to investigate memory problems caused by applications that have not been optimized.

In This Chapter

Overview of Memory Monitoring

Determining the Amount of Installed Memory

Understanding Memory and the File System Cache

Optimizing Your Memory Configuration

Establishing a Baseline for Memory

Investigating Memory Problems

Related Chapters in the Resource Kit

  • For information about Windows 2000 architecture, see “Windows 2000 Professional Architecture” in this book.
  • For general information about performance monitoring, see “Overview of Performance Monitoring” in this book.
  • For information about developer tools see the Microsoft Windows 2000 Server Resource Kit companion CD or see the Software Development Kit (SDK) documentation in the MSDN Library at http://msdn.microsoft.com.


Overview of Memory Monitoring

Low memory conditions can slow the operation of applications and services on your computer and impact the performance of other resources in your system. For example, when your computer is low on memory, paging — that is, the process of moving virtual memory back and forth between physical memory and the disk — can be prolonged, resulting in more work for your disks. Because it involves reading and writing to disk, this paging activity might have to compete with whatever other disk transactions are being performed, intensifying the disk bottleneck. (A disk bottleneck occurs when disk performance is reduced to the extent that overall system performance is affected.) In turn, all this work by the disk can mean the processor is used less or is doing unnecessary work, processing numerous interrupts due to repeated page faults. (Page faults occur when requested code or data cannot be located in the physical memory available to the requesting process.) In the end, applications and services become less responsive.

Figure 16.1 illustrates the sequence in which you conduct the monitoring process. Memory has such an important influence on system performance that monitoring and analyzing memory usage is one of the first steps you take when assessing your system’s performance.

Figure 16.1 Monitoring Memory as Part of an Overall Monitoring Routine

The first phase of analyzing memory usage involves understanding your current memory configuration and your workload, using the steps in the following list:

  • Determine the amount of physical memory that is currently installed, and compare it against minimum operating system requirements.
  • Read “Understanding Memory and the File System Cache” in this chapter for information about the relationship between system memory and the file system cache.
  • Establish a baseline for memory usage on your computer by determining performance ranges for low or idle, average, and peak usage periods.
  • Optimize the system memory configuration to the system workload, including verifying cache and paging file sizes.

Focus subsequent monitoring on how your system uses memory and on identifying memory shortages or other problems, using the following steps:

  • Look at memory characteristics of processes using the Process\Working Set and Process\Private Bytes counters. The Working Set counter reports the amount of committed memory allocated to the process. This might include shared and private bytes. The Private Bytes counter reports memory allocated exclusively to the process. Working set monitoring is important because, when memory is in short supply, working sets of processes are trimmed and paging occurs. (The working set of a process is the amount of physical memory assigned to that process by the operating system.)
  • Monitor the counters listed in “Investigating Disk Paging” later in this chapter to understand the relationship between the amount of paging and the amount of disk activity and their effect on overall performance. Excessive paging can burden the disk.
  • Determine the effectiveness of the file system cache. Your system performs better when it can find requested data in the cache, rather than having to read from the disk.
  • Learn how to tune the working sets of applications, if you have access to source code. Efficient applications maintain a small working set without generating page faults.


Determining the Amount of Installed Memory

Start your monitoring efforts knowing that you have at least the minimum amount of memory required to run Windows 2000. These requirements are as follows:

  • Microsoft® Windows® 2000 Professional: 32 megabytes (MB)
  • Microsoft® Windows® 2000 Server: 64 MB

The memory recommendation for Windows 2000 Professional is based on a typical desktop configuration including a business productivity application, such as a word processor or a spreadsheet program, an e-mail application, and a Web browser. The memory recommended for Windows 2000 Server is based on either a dedicated or a multiuse server with a low load, such as a small file-sharing and Web service configuration for a small office. If you are using a database management system such as Microsoft® SQL Server™ or a messaging server such as Microsoft® Exchange, consult the documentation for those products to determine the memory recommended for running them on Windows 2000 Server.

There are a few different ways to determine the amount of memory on your computer. You can find the amount of physical memory installed on your system by clicking the Performance tab in Task Manager. Or you can find the amount of available RAM by double-clicking System in Control Panel and then clicking the General tab.

Note

You can see the memory configuration on local or remote systems using System Information. For more information, see Windows 2000 Server Help.

The operating system distinguishes memory usage by applications and services depending on whether the usage involves the paged or the nonpaged pool. The paged pool contains memory for objects used by applications and services that can be paged to disk; objects in the nonpaged pool cannot be paged to disk. The size of each pool is determined by the operating system based on the amount of physical memory present. Memory pool usage can be an important factor in evaluating memory usage by your applications. For more information, see “Investigating User-Mode Memory Leaks” and “Investigating Kernel-Mode Memory Leaks” later in this chapter.

The file system cache, which is a subset of physical memory used for fast access to data, and the disk paging file, which supports virtual memory, influence the amount of memory used by the operating system and applications. (The disk paging file, also called a swap file, is a file on the hard disk that serves as temporary, virtual memory storage for code and data.) Virtual memory is the space on the hard disk that Windows 2000 uses as memory. For purposes of monitoring, the most important types of virtual memory are committed memory that is set aside for a process in the paging file and available memory that is not in use by a process. (Another type of memory managed by Windows 2000 is reserved memory, which is set aside for a process but might not be entirely used.) The following sections describe the influence of the cache and the paging file on performance and explain how best to adjust these for optimal memory usage.


Understanding Memory and the File System Cache

Windows 2000 allocates a portion of the memory in your system to the file system cache. The file system cache is a subset of the memory system that retains recently used information for quick access. The size of the cache depends on the amount of physical memory installed and the memory required for applications. On Intel-based systems the maximum size of the file system cache is 960 MB when the Maximize Data Throughput for File Sharing option is selected in the File and Printer Sharing for Microsoft Networks Properties dialog box (see the procedure “To adjust Server Optimization settings” later in this chapter), creating a large system cache. For more information about the large system cache setting, see “Optimizing Your Memory Configuration” later in this chapter.

Note

Even if the Maximize Data Throughput for File Sharing option is selected, be aware that using Terminal Server, described in the Microsoft® Windows® 2000 Server Resource Kit Internetworking Guide, or using the /3GB Boot.ini switch for Microsoft® Windows® 2000 Advanced Server (the 4GT feature associated with this switch is described in Windows 2000 Advanced Server Help) reduces the maximum available cache size.

Memory that is not required for the working sets of processes is available for the cache. The operating system dynamically adjusts the size of the cache as needed; it is not designed to be manually tuned. Therefore, rather than monitor the size, it is more useful to monitor the effectiveness of the cache. Do this by determining the number of times data was found (called a hit) in your cache. Because inadequate cache size increases the rate at which data fails to be found (called a miss), data misses can be another indication that you do not have enough memory. When a miss occurs, the disk must be accessed. To track cache hits and misses, use the Cache object counters as described in “Monitoring the Cache” later in this chapter.

To determine cache size

  • Use Performance Monitor to see the Memory\Cache Bytes value.

    –or–

  • Use Task Manager to see the File Cache value on the Performance tab.

Note

The values reported by Performance Monitor and Task Manager represent the currently mapped file cache plus pages in transition to disk.


Optimizing Your Memory Configuration

The configuration of your operating system can affect memory utilization and make it appear that you do not have enough memory. Modify the settings discussed in this section to improve your system’s performance.

Note

The Server Optimization tab, described in the following sections, is not available on computers running Windows 2000 Professional.


Adjusting Cache Size with Server Service Properties

The Server tab in the File and Printer Sharing for Microsoft Networks Properties dialog box controls memory buffer allocation for network connections and file system cache size. If you are using Windows 2000 Server, you might want to modify tab settings to optimize memory usage.

Windows 2000 Server Setup configures the cache to maximize file server performance by default. When configured in this manner, the Server service allocates a considerable amount of memory for internal buffers and tables, creating a large system cache. The Maximize Data Throughput for File Sharing option is useful for computers that typically run the Server service for file sharing. However, because memory has been set aside to maintain the large cache and is unavailable to applications, this setting can cause excessive paging on computers that run server applications. This might be especially noticeable when you are performing large copy operations.

If the computer running Windows 2000 Server is mainly used for application services, change the setting to Maximize Data Throughput for Network Applications to free this memory so that it is available for other components.

Note

Some applications such as SQL Server set this option by default because they do their own caching. In that case, this option should be disabled.

To adjust Server Optimization settings

  1. Click Start, point to Settings, and then click Control Panel.
  2. Double-click Network and Dial-up Connections.
  3. Double-click Local Area Connection, and then click the Properties button.
  4. In the Local Area Connection Properties dialog box, double-click File and Printer Sharing for Microsoft Networks.
  5. Under Optimization, if you are running Windows 2000 Server, the Maximize Data Throughput for File Sharing option is selected by default. To turn this option off to reduce paging activity, click Maximize Data Throughput for Network Applications.
  6. Click OK.

Figure 16.2 illustrates the user interface for configuring these settings.

Figure 16.2 File and Printer Sharing for Microsoft Networks Properties Dialog Box

If you are still experiencing excessive paging, selecting the Minimize Memory Used option (see Figure 16.2) can help to reduce paging activity. However, if you configure the Server service for too little memory, you might experience intermittent connection failures (receiving the error message, “Not enough server memory to process this request” or “Server refused the connection”).

Caution against resetting the secondary cache

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

The Windows 2000 registry contains configuration data important for memory usage. Some third-party sources have erroneously reported that modifying the registry entry named HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Control\Session Manager\Memory Management
\SecondLevelDataCache can enhance system performance. Although it is possible to reset this value to something other than the default value of 0, in most cases doing so does not improve performance. Microsoft does not recommend changing this setting. When this entry’s value is set to 0, the system attempts to retrieve the level-2 processor (L2) cache size from the HAL for the platform. If it fails to obtain this value, the system sets a default size of 256 KB for the L2 cache.

You should only consider editing the default value on computers with direct-mapped L2 caches. Pentium II and later processors do not have direct-mapped L2 caches. A slight performance improvement (two percent) can be detected in older computers (486 and earlier) with memory of 64 MB and more due to the fact that physical pages are distributed better in the address space, reducing L2-cache collisions. However, defeating the operating system’s default behavior and setting the value of the SecondLevelDataCache to 256 KB rather than 2 MB when the computer has a 2 MB L2 cache reduces performance slightly.


Adjusting Paging File Size

For virtual-memory support, Windows 2000 creates one paging file called Pagefile.sys on the disk or volume on which the operating system is installed. The default size is equal to physical memory plus 12 MB, which is sufficient for dumping the contents of the paging file, if necessary. A small paging file limits what can be stored and might exhaust your virtual memory for applications. If you are short on RAM, more paging occurs, which generates extra activity for your disks and slows response times for the system.

Note

Special considerations apply for sizing the paging file on Windows 2000 Advanced Server when you are using 4 gigabyte RAM tuning (4GT). For more information, see Windows 2000 Advanced Server Help.

Because the size and location of paging files can affect your system’s performance, you might want to modify these. Also, because maintaining multiple files on multiple drives can improve performance, you might want to add a paging file. Figure 16.3 shows the Virtual Memory dialog box, which you use to change your paging file settings. See Windows 2000 Server Help for specific instructions.

Figure 16.3 Virtual Memory Dialog Box

The following guidelines describe how to optimize the paging file.

Set the Same Initial and Maximum Size

Setting the paging file’s initial size and maximum size to the same value increases efficiency because the operating system does not need to expand the file during processing. Setting different values for initial and maximum size can contribute to disk fragmentation.

Expand the Default Size

Expanding the default size of the paging file can increase performance if applications are consuming virtual memory and the full capacity of the existing file is being used. To determine how large your paging file should be based on your system workload, monitor the Process (_Total)\Page File Bytes counter. This indicates, in bytes, how much of the paging file is being used.

You can also determine the appropriate size of a paging file by multiplying the Paging File\% Usage Peak counter value by the size of Pagefile.sys. The % Usage Peak counter indicates how much of the paging file is being used.

A large paging file uses disk storage space, so do not create a large paging file on a disk that is very active (for example, one that services heavy application or network activity) or one that has limited space. Change the file size gradually and test performance until you find the optimal balance between paging file and disk space usage. The operating system requires a minimum of 5 MB of free space on a disk. For more information, see “Examining and Tuning Disk Performance” in this book.

Before increasing the file size, make sure you have adequate disk space, particularly on your servers. For more information, see “Observing Network Performance” later in this book.

Move the Paging File

If disk space on your boot volume is limited, you can achieve better performance by moving the paging file to another volume. However, you might want to leave a minimal paging file on the boot volume and maintain a larger file on another volume with more capacity for the following reasons:

  • The system requires a minimum file size of 2 MB on the boot volume to write events to the system log, send an administrative alert, or automatically restart after a system Stop error occurs in the event of a system failure. A minimum of 12 MB plus the amount of installed RAM is required for dumping the paging file (as described earlier in this section). If performance is more critical than recoverability, you can put the paging file on a hardware-enabled stripe set separate from the operating-system volume.
  • For your system to write debugging information to a file, it needs a file that is equal to RAM plus 1 MB on the system root.

Use Multiple Disks

Although Windows 2000 supports a limit of 4,095 MB for each paging file, you can supply large amounts of virtual memory to applications by maintaining multiple paging files. Spreading paging files across multiple disk drives and controllers improves performance on most modern disk systems because multiple disks can process input/output (I/O) requests concurrently in a round-robin fashion.

Creating multiple paging files on a single logical volume or partition does not improve performance.

If you find that page writing and disk writing or page reading and disk reading are equivalent on a logical disk, splitting the paging file onto separate volumes is helpful.

Set a Smaller Default Size for Systems Running Windows 2000 Advanced Server

If you are working in an enterprise environment using the 4-GB RAM Tuning (4GT) option and have a system with more than 4 GB of physical memory, you might want to consider changing the default size of your paging file. In Windows 2000, the default paging file size is equal to the amount of physical memory on the system plus 12 MB. On a 4-GB computer, this might result in a paging file too large to be effective. A 256-MB paging file might be a more effective use of disk space. However, a smaller paging size affects the size of total committed memory for applications. For best results, review these settings with the Independent Software Vendor (ISV) for your applications that are being run with the 4GT option. For more information about 4GT, see Windows 2000 Advanced Server Help.

Note

To see how the paging file is used during memory shortages, start the LeakyApp tool on the Windows 2000 Resource Kit companion CD, designed to simulate memory leaks for monitoring purposes. While running LeakyApp, monitor Paging File\% Usage and Process(_Total)\Page File Bytes. Log these counters to get an idea of the rate of growth of the paging file.


Establishing a Baseline for Memory

After determining that you have an adequate amount of memory and that your configuration is appropriate, examine your memory usage under a normal workload to establish a baseline or reference point for memory usage. The baseline is generally not a single value but a range within which memory usage can fluctuate and still provide acceptable performance. You can use the baseline to identify trends, such as increasing memory demands over time, or to recognize problems that arise from a sudden change.

To determine a baseline for your system, use the following counters to create logs of memory usage over an extended period (from several weeks to a month).

  • \Memory\Pages/sec
  • \Memory\Available Bytes
  • \Paging File(_Total)\% Usage

As you monitor the values of these counters, you might see occasional spikes. Typically, you can exclude these from your baseline because it is the consistent, repetitive values with which you are most concerned; the range of values that seem to appear consistently constitutes your baseline. When values fall outside of these ranges for extended periods, follow the instructions provided in this chapter to investigate the variations.


Virtual Memory Usage

Even if your system exceeds the minimum memory requirements for the operating system, you might face situations in which you do not have enough memory. For example, if you run several memory-intensive applications or if several users share your computer, the available memory of your system could be consumed, affecting your system’s performance.

To see how much virtual memory your Windows 2000 Professional–based computer uses, start all applications and use Task Manager to see the Peak Commit Charge value. This value appears in the Commit Charge box on the Performance tab.

Peak committed memory is the highest amount of virtual memory (in bytes) that has been committed over this sample. To be committed, these bytes must either have a corresponding amount of storage available on disk or in main memory. Compare this value against the size of the paging file to determine if the paging file is sized appropriately.

On a computer running Windows 2000 Server, in addition to total committed memory, you need to consider the number of users sharing a system and the number of files they open to determine memory requirements for your workload.

Under Computer Management, use Shared Folders to view this information.

For information about additional recommendations pertaining to memory on server computers, see “Observing Network Performance” later in this book.


Default Services Memory Consumption

In general, Windows 2000 has been optimized so that only the most commonly used services run by default, and you should not have to turn off any services. However, you can reduce the memory requirements of your system by turning off some of the default services provided by the operating system.

To stop a service

  1. Click Start, point to Programs, and then click Administrative Tools.
  2. Click Computer Management, and then, in the console that appears, click System Tools.
  3. Under System Tools, double-click Services.
  4. Right-click the name of a service, and then click Stop.


Investigating Memory Problems

After you have observed memory usage under normal conditions and established your memory baseline, you might notice that the memory counters sometimes stray from the typical range. The following sections describe how to investigate conditions that cause memory values to deviate from the baseline.

The following activities help you to learn about and analyze memory usage and memory bottlenecks using Performance Monitor counters and other tools.

  • Investigating memory shortages
  • Investigating disk paging
  • Investigating user-mode memory leaks
  • Investigating kernel-mode memory leaks
  • Monitoring the cache
  • Resolving memory and cache bottlenecks

Table 16.1 summarizes the most important counters to monitor for analyzing memory usage.

Table 16.1Counters for Analyzing Memory Usage

To monitor for | Use this Object: Counter
Memory shortages | Memory\Available Bytes Process (All_processes)\Working Set Memory\Pages/sec Memory\Cache Bytes
Frequent hard page faults | Memory\Pages/sec Process (All_processes) \Working Set Memory\Pages Input/sec Memory\Pages Output/sec
Excess paging with a disk bottleneck | Memory\Page Reads/sec LogicalDisk or Physical Disk\Avg. Disk Bytes/Read
Paging file fragmentation | LogicalDisk or PhysicalDisk\Split IOs\sec
Memory leaks; memory-intensive applications | Memory\Pool Nonpaged Allocations Memory\Pool Nonpaged Bytes Process(process_name)\Pool Nonpaged Bytes Process\Handle Count
Cache efficiency | Cache\Copy Read Hits % Cache\Copy Reads/sec Cache\Data Map Hits % Cache\Data Maps/sec Cache\MDL Read Hits % Cache\MDL Reads/sec Cache\Pin Read Hits % Cache\Pin Reads/sec


Investigating Memory Shortages

Your system can develop a memory shortage if multiple processes are demanding much more memory than is available or you are running applications that leak memory. Monitor the following counters to track memory shortages and to begin to identify their causes.

  • Memory\Available Bytes indicates how much physical memory is remaining after the working sets of running processes and the cache have been served.
  • Process (All_processes)\Working Set indicates how much memory one or more processes uses when there is an ample amount of memory, including memory that is private to the specific process and memory shared with other processes. When memory is in short supply, working sets of some active processes must be trimmed to meet the memory needs of other processes, resulting in page faults.
  • Memory\Pages/sec indicates the number of requested pages that were not immediately available in RAM and had to be read from the disk or had to be written to the disk to make room in RAM for other pages. If your system experiences a high rate of hard page faults, the value for Memory\Pages/sec will be high.

To maintain a minimum number of available bytes for the operating system and processes, the Virtual Memory Manager continually adjusts the space used in physical memory and on disk. In general, if memory is ample, working set sizes can increase as needed. If the memory supply is barely adequate or very close to the amount required, you might see the operating system trim some working-set sizes when another process needs more memory—at start-up, for example. As working sets are trimmed, some page faulting can occur. Figure 16.4 shows how the system’s available bytes and one process’s working set are affected when a new process is started.

Figure 16.4 Graph of Available Bytes, Working Set, and Page Faults

If the value for Memory\Available Bytes is consistently below the system-defined threshold and the value for Memory\Pages/sec spikes continuously, it is likely that your memory configuration is insufficient for your needs. To confirm that a high rate of paging is related to low memory, see “Investigating Disk Paging” later in this chapter.

Note

You might see a low value for Memory\Available Bytes, which is not caused by a memory shortage, in the following situations:

  • During large file-copy operations such as a system backup. In this case, you can verify that the copy operation is the cause by monitoring Memory\Cache Bytes as well. You should see Memory\Cache Bytes rise as Memory\Available Bytes falls. Otherwise, you need to investigate the cause as described in this chapter.
  • The Maximize Throughput for File Sharing option is selected in the File and Printer Sharing for Microsoft Networks Properties dialog box. This allocates a large system cache, which might not be appropriate for how your computer is used. For more information about how this setting should be configured, see “Optimizing Your Memory Configuration” earlier in this chapter.

To identify processes associated with low-memory conditions, examine memory usage by specific processes, and determine if a process is leaking memory as described in “Investigating Memory Leaks” later in this chapter.

If available memory is consistently low, the computer becomes unresponsive because it is occupied exclusively with disk I/O operations. During paging due to low memory, the processor is idle while waiting for the disk to finish. Therefore, it is important, especially on server computers, to investigate and correct the cause of a low-memory condition. Notice which processes are running as well as the sizes of their working sets as you monitor memory counters. The processes might need to be updated or replaced if they are contributing to memory shortages and you do not want to acquire additional memory.

For information about how to address a memory shortage, see “Resolving Memory and Cache Bottlenecks” later in this chapter.


Investigating Disk Paging

Use memory counters that report paging activity to identify memory shortages resulting in disk bottlenecks. Start by monitoring the memory counters and working set values as you did when checking for a memory shortage in the preceding section. Confirm that hard page faults are occurring using the Memory\Pages/sec counter.

If hard page faults are occurring, monitor disk counters to assess how the disk is behaving during paging: whether it is busy with other work or with handling page faults. Monitor disk paging using the following steps and associated counters:

  1. To confirm hard page faulting use the following Memory and Process counters:
    • Memory\Pages/sec
    • Process (All_processes) \Working Set
    • Memory\Pages Input/sec
    • Memory\Pages Output/sec
  2. To understand the impact of page faulting on the disk, compare the number of reads and read bytes measured by the following counters:
    • Memory\Page Reads/sec
    • LogicalDisk\Disk Reads/sec
    • LogicalDisk or PhysicalDisk\Avg. Disk Read Bytes/sec

Confirming Hard Page Faults

To confirm hard page faults, examine the hard page fault rate using Memory\Pages/sec and the working sets of active processes using Process(process_name)\Working Set, as described in “Investigating Memory Shortages.” Memory\Pages/sec is the sum of Pages Input/sec and Pages Output/sec and reports the number of requested pages that were not immediately available in RAM and had to be read from the disk (resulting in hard page faults) or that had to be written to the disk to make room in RAM for other pages. Monitoring processes’ working sets enables you to correlate a given application’s memory usage with page faulting. When memory is in short supply, working sets are continuously trimmed and page faults are frequent.

Acceptable rates for Memory\Pages/sec range from 40 per second on older laptop computers to 150 per second for the newest disk systems. Use a shorter monitoring period on client computers than on server computers (updating once per second is appropriate) because paging activity can occur in bursts on client computers. Paging activity tends to reach a steady state on server computers; therefore, longer-term monitoring is appropriate.

Note

Page Fault Monitor (Pfmon.exe), a tool on the Windows 2000 Server Resource Kit companion CD in the Performance Tools group (\Perftool\Meastool), lists hard and soft page faults generated by each function call in a running process. You can display the data, write it to a log file, or both. For more information, see Rktools.hlp on the Windows 2000 Server Resource Kit companion CD.

You can also monitor page faults and memory management data using Trace Logs in the Performance snap-in. For more information, see the “Overview of Performance Monitoring” earlier in this book.

When values exceed the acceptable range for your type of disk, investigate disk activity to determine if the faulting is causing a disk bottleneck. Memory\Pages Input/sec reflects the rate at which pages were read from the disk and thus gives you data on hard page faults. Depending on the capabilities of your disk, high values can indicate a lack of memory sufficient to hurt system performance. See Figure 16.5 for an example of page faulting.

Note

You might see high levels of paging with Memory\Pages/sec when pages are read to and from noncached, memory-mapped files. When these files are used in this way, Memory\Pages/sec or Memory\Available Bytes is high but Memory\Paging File\%Usage and Memory\Cache Faults/sec are normal to low.

Figure 16.5 Paging Activity on a System with Low Memory

The other component of Memory\Pages/sec, Memory\Pages Output/sec, indicates the rate at which pages were written to the disk. Although this activity does not generate hard page faults, disk-write activity can indirectly reflect a memory shortage and indicates additional disk activity. This is because, as the Virtual Memory Manager needs to trim pages from a working set, it might find that some pages contain changed data. In this case the changed data must be written to disk to free the pages. When memory is in ample supply, Memory\Pages Output/sec is likely to be low because there is less need to free changed pages and write that data to disk. For more information about investigating applications that generate disk-write activity, see “Examining and Tuning Disk Performance” in this book.

Assessing the Effect of Page Faults on the Disk

To understand the impact of page faulting on the disk, examine the number of disk operations that occur as a result of paging. If paging activity dominates your disk’s workload, a memory shortage is causing a disk bottleneck. Start by looking at Memory\Page Reads/sec. This counter indicates the number of read operations by the disk that were required to retrieve faulted pages. Compare the number of reads performed with the number of pages faulted to determine how many pages are retrieved per read. A high ratio of reads to faults means a large number of pages are not found in physical memory and are being demanded from the disk, creating a disk bottleneck.

Next, determine what proportion of your disk’s overall work is occupied with reading pages from memory. To do this, compare page reads to disk reads. If there is a correlation between the values of Memory\Page Reads/sec and LogicalDisk\Disk Reads/sec, it is likely that paging activity makes up the majority of your disk activity and could be causing a disk bottleneck.

To see the relationship between paging and disk read operations from a different perspective, monitor the value of LogicalDisk\PhysicalDisk\Avg Disk Read Bytes/sec or PhysicalDisk\Avg Disk Read Bytes/sec while you are monitoring Page Reads/sec. The disk read bytes counter indicates the rate at which the disk is transferring data during reads. Because this is a measurement of bytes rather than of pages or of the number of reads, you need to convert to identical units. Use the following formula for this purpose: value of LogicalDisk\Disk Read Bytes/sec ÷ 4096 (number of bytes in a page).

If the result is approximately equal to the value of Page Reads/sec, paging activity is the bulk of your disk read activity, and the memory shortage represented by heavy paging activity could in turn be causing a disk bottleneck. To see if this activity is reaching a rate high enough to cause poor disk performance, see your disk manufacturer’s documentation for the number of I/O transactions per second you can expect from your disk. For more information about locating disk bottlenecks, see “Examining and Tuning Disk Performance” in this book.

Figure 16.6 illustrates disk activity associated with paging activity when memory is low.

Figure 16.6 Disk and Paging Activity When Memory is Low


Investigating User-Mode Memory Leaks

A memory leak occurs when applications allocate memory for use but do not free allocated memory when finished. As a result, available memory is used up over time, often causing the system to stop functioning properly. Therefore, it is important to investigate the causes of all memory leaks, particularly on server computers. This section describes how to identify memory leaks, including ones that affect the critical nonpaged memory pool, and where to find tools and information related to working with memory leaks.

Note

It is sometimes possible to mistake an increase in system load for a memory leak. To distinguish between these conditions, observe the Memory and Process counters over a number of days. If you see the system first reach a steady state, then attain a level of increased load (usually achieved during some peak portion of the day), and then fall again, it is likely you are seeing variations in load rather than a leak. On network computers, look at user sessions and throughput rates such as transferred bytes per second to eliminate workload as a factor.

Identifying a Memory Leak

The symptoms of a memory leak include the following:

  • A gradually worsening response time.
  • The appearance of an error message, shown in Figure 16.7, indicating that the system is low on virtual memory.

Figure 16.7 Out of Virtual Memory Error Message

  • The appearance of error messages indicating that system services have stopped.

If you suspect that a particular application or service is causing a memory leak, investigate the memory use of your applications using the following counters:

  • Memory\Available Bytes reports available bytes; its value tends to fall during a memory leak.
  • Process(process_name)\Private Bytes reports bytes allocated exclusively for a specific process; its value tends to rise for a leaking process.
  • Process(process_name)\Working Set reports the shared and private bytes allocated to a process; its value tends to rise for a leaking process.
  • Process(process_name)\Page Faults/sec reports the total number of faults (hard and soft faults) caused by a process; its value tends to rise for a leaking process.
  • Process(process_name)\Page File Bytes reports the size of the paging file; its value tends to rise during a memory leak.
  • Process(process_name)\Handle Count reports the number of handles that an application opened for objects it creates. Handles are used by programs to identify resources they must access. The value of this counter tends to rise during a memory leak.

Monitor these counters over a period ranging from two hours to a few days. Logging is recommended, both because of the overhead of monitoring multiple instances of the Process counters and because leaks tend to manifest themselves slowly.

In addition, to isolate the problem and avoid unnecessary overhead, monitor from a remote computer, if possible. Network activity or interaction with other computers can interfere with the results.

Memory Leaks and the Nonpaged Pool

Although any leak is serious, memory leaks are of particular concern when they involve the nonpaged pool. Many system services allocate memory from the nonpaged pool because the pool itself is smaller and because its contents cannot be paged out. To identify whether or not a leak affects the nonpaged pool, include the following counters in your monitoring:

  • Memory\Pool Nonpaged Bytes
  • Memory\Pool Nonpaged Allocs
  • Process(process_name)\Pool Nonpaged Bytes

Note

Because the internal counters used by Task Manager, Process Monitor, and Performance Monitor to measure the size of the nonpaged pool for each process are not precise, it is recommended that you monitor changes in the overall pool size over time (a few days, for example), rather than rely on the absolute, instantaneous values reported for each process. The counter values are estimates that count duplicate object handles as well as space for the object. Also, because the process pool size counts are rounded to page size, pool space is overestimated when a process uses only part of a page. In contrast, total pool size counts are precise. Therefore, the sum of pool sizes for each process might not equal the value for the whole system.

The counters on the Memory object monitor the total size of the nonpaged pool and the number of allocations of pool space for the whole system. The counter on the Process object monitors nonpaged pool space allocated to each process.

To use Performance Monitor to monitor the nonpaged pool for leaks, follow these steps:

  • Record the size of the nonpaged pool when the system starts. Then log the Memory and Process objects for several days; a 10-minute update interval is sufficient.
  • Review the log for changes in size of the nonpaged pool. You should be able to associate any increases in the size of the pool, as indicated by Memory\Pool Nonpaged Bytes, with the start of a process, as indicated by Process\% Processor Time.

    When processes are stopped, you should see a decrease in pool size. Any growth in the nonpaged pool is considered abnormal, and you need to distinguish which process is causing the change in pool size.

    You might also want to monitor the number of active threads before and after running the process (use the Performance tab in Task Manager or the Objects\Threads or Process(_Total)\Thread Count counters). A process that is leaking memory might be creating a large number of threads; these appear when the process starts and disappear when the process stops.

  • Watch the value of Memory\Pool Nonpaged Bytes for an increase of ten percent or more from its value at system startup to see if a serious leak is developing.

The following additional tools provide information about the paged and nonpaged memory pools as listed in Table 16.3. These tools collect their data from the same sources.

Tool Name | Description | Location
Memsnap (memsnap.exe)1 | Records system memory usage to a log file. | Windows 2000 Resource Kit companion CD
Process Monitor (pmon.exe)1 | Provides total and per process values for nonpaged and paged pool memory. Note Also monitor the committed memory values shown in the Pmon display for increases; the process with the leak should have an increasing Commit Charge. | Windows 2000 Resource Kit companion CD
1 These tools are useful because they show allocations on a per-process basis.

Working with Memory Leaks

For a quick demonstration of a memory leak, start LeakyApp, a test tool on the Windows 2000 Server Resource Kit companion CD, and observe the values of the monitored counters. Notice the steady increase in the following counters: Memory\Pages/sec, Process(process_name)\Working Set, and Process(process_name)\Private Bytes.

Figure 16.10 illustrates counter activity during a memory leak generated by the LeakyApp tool.

Figure 16.10 Process Memory Activity During a Memory Leak

Although the memory leak illustrated in Figure 16.10 has a systemic effect, the problem can be tracked to a single cause—the leaking application. If you have an application that exhibits similar behavior, it is recommended that you either modify it (if you have access to the source code) or replace it with another program.

Developer tools for analyzing and tuning memory usage by applications are available on the Windows 2000 Server Resource Kit companion CD and in the SDK (for more information, see the “Additional Resources” section at the earlier in this chapter). The following tools optimize memory-intensive applications.

  • Application Monitor (APIMON) on the Windows 2000 Server Resource Kit companion CD monitors page faults caused by an application and reports them by Win32 function calls.

  • The Working Set Tuner (WST) on the SDK analyzes the patterns of function calls in your application code and recommends a code organization that consumes the least possible physical memory. One objective of tuning your working set is to arrive at the smallest possible working set without causing page faults.

  • Virtual Address Dump (Vadump) on the SDK creates a list that contains information about the memory usage of a specified process, including address size, total committed memory for the image, the executable, each dynamic-link library (DLL), and heap usage.

    Although one strategy for avoiding leaks in the nonpaged pool might be to change the size of the pool, this solution is not recommended. The nonpaged pool size and the paged pool size are set by default during Windows 2000 Setup based on your memory configuration. The maximum nonpaged pool size is 128 MB on Intel-based computers and 96 MB on Alpha computers. The maximum paged pool size is 192 MB on Intel-based computers and 240 MB on Alpha computers. The registry subkey containing the entries for these sizes is HKEY_LOCAL_MACHINE\System
    \CurrentControlSet\Control\Session Manager\Memory Management. For information about these registry settings, see Regentry.hlp on the Windows 2000 Server Resource Kit companion CD.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Note

When this subkey is set to the default of 0, Windows 2000 dynamically adjusts the size of the paged and nonpaged memory pools for optimum performance. Specifying a pool size can degrade performance. Also, the system might not be able to open some large files, and those files can be corrupted. Therefore, Microsoft recommends that you retain the system-determined values for paged and nonpaged memory pools.


Investigating Kernel-Mode Memory Leaks

Kernel-mode processes such as device drivers can also cause memory leaks when bytes are allocated but not freed. Again, you typically track these over a period of several hours or days, but instead of relying on Performance Monitor counters, use Pool Monitor (Poolmon.exe) on the Windows 2000 Server compact disc.

Pool Monitor (Poolmon.exe) shows the amounts of nonpaged and paged memory that were allocated and freed, calculates the difference between these, and associates the data with a function tag to help you identify the process involved. Pool Monitor can be installed from the \Support\Debug folder on the Windows 2000 Server compact disc. By default, Windows 2000 is configured not to collect pool information because of the overhead. To use Poolmon, you need to change the value of the HKEY_LOCAL_MACHINE\System
\CurrentControlSet\Control\Session Manager\GlobalFlag in the registry. For information about editing the registry see “Overview of the Registry” in this book.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

To change the value of GlobalFlag without editing the registry manually, use Gflags.exe, a tool provided on the Windows 2000 Server Resource Kit companion CD. In Gflags, select the Enable Pool Tag check box. For information about using Gflags, see Rktools.hlp.

If you edit the registry manually, for Windows NT®3.51 and later and for Windows 2000, set the value of GlobalFlag to should be 0x00000400. This enables the pool tag, a mechanism for identifying the driver or other part of the kernel allocated to a particular portion of memory. These tags can be examined to reveal memory leaks and pool corruption, and the offending code component can be determined by finding which code component is allocated to which tag. Look for a tag with rapidly increasing byte counts that does not free as many bytes as it allocates, and verify that this tag corresponds to a function for which the increasing memory allocation might be appropriate. If it does not appear appropriate, it might be necessary to debug and tune the application to eliminate the leak.


Monitoring the Cache

The Windows 2000 file system cache is an area of memory into which the I/O system maps recently used data from disk. When processes need to read from or write to the files mapped in the cache, the I/O Manager copies the data from or to the cache, without buffering or calling the file system, as if it were an array in memory. Because memory access is quicker than a file operation, the cache provides an important performance boost to the processes.

The cache itself can never really have a bottleneck because it is just a part of physical memory. However, when there is not enough memory to create an effective cache, the system must retrieve more data from disk, resulting in I/O operations that can impact overall performance. Such a shortage of cache space can be considered a cache bottleneck.

Cache bottlenecks are of greatest concern to administrators of Windows 2000 Server–based computers and to users of Windows 2000 Professional–based computers running CAD/CAM applications or large databases accessing large blocks of multiple files that rely on the cache. Administrators of server computers need to monitor cache counters because these provide indirect indications of the memory supply. Windows 2000 Server defines a large system cache by default to maximize the likelihood that data is found in memory, rather than retrieved from disks. The cache counters can reveal that a small cache (based on a short supply of memory) is hurting system performance.

Note

Many Web servers or large database applications, such as SQL Server, maintain a separate cache and do not use the file system cache. In addition, they might have their own cache-monitoring counters.

With memory-mapped file I/O, an entire file can be opened without actually being read into memory. Only the views (smaller portions of the file) are mapped into the process’s address space just before I/O operations are performed. Memory-mapped I/O keeps the cache size small.

Developers who want to understand how their programs use the cache for read and write operations might also want to monitor the cache. Data requested by an application is mapped to the cache and then copied from there. Data changed by applications is written from the cache to disk by the lazy writer system thread or by a write-through call from the application. The lazy writer thread in the system process periodically writes changed pages from the modified page list back to disk and flushes them from the cache. When a page is flushed from the cache, changed data is written from the page in the cache to the disk and the page is deleted from the cache. Thus, monitoring the cache is like watching your application I/O. Remember, however, that if an application uses the cache infrequently, cache activity has an insignificant effect on the system, the disks, and on memory.

Cache object counters provide information about data hits and misses and about file I/O operations that reflect how efficiently their applications access data in the file system cache. (To determine the rate of misses, subtract the hit percentage from a possible 100 percent.)

Understanding the Cache Counters

Use the following Performance Monitor Cache and Memory counters to measure cache performance. For instructions based on specific symptoms, see “Interpreting Changes in Cache Counter Values” later in this chapter.

  • Cache\Copy Read Hits %

    Monitor this counter for hit rates and miss rates. Any value over 80% indicates that the application uses the cache very efficiently. Compare this counter with Cache\Copy Reads/sec to see how many hits you are really getting. Even though the hit percentage is small, if the rate of operations is high, this might indicate better cache effectiveness than a high percentage with a low rate of operations.

Note

For best results, monitor the Cache\Copy Read Hits % counter using the graph view rather than the report view. Hit percentage rates frequently appear as spikes that are hard to detect in a report. In general, a hit rate of over 80% is excellent. A 10% decrease in normal hit rates is cause for concern and probably indicates a memory shortage.

  • Cache\Copy Reads/sec

    Observe this counter to see the rate at which the file system attempts to find application data in the cache without accessing the disk. This is a count of all copy read calls to the cache, including hits and misses. Copy reads are the usual method by which file data found in the cache is copied into an application’s memory buffers.

  • Cache\Data Flush Pages/sec

    Review this counter for the rate at which applications change pages of cached data and the pages are written back to disk. This includes pages that have been written by the system process when many changed pages have accumulated, pages that have been flushed so that the cache can be trimmed, and disk writes that are caused by an application write-through request.

  • Cache\Data Flushes/sec

    Monitor this counter for the rate at which cache data is being written back to disk. This counter reports application requests to flush data from the cache and is an indirect indicator of the volume and frequency of application data changes.

  • Cache\Data Maps/sec

    Examine this counter for the rate at which file systems map pages of a file into the cache for reading. This counter reports read-only access to file system directories, the File Allocation Table (FAT) in the FAT file system, and the Master File Table in the NTFS file system. This counter does not reflect cache use by applications.

  • Cache\Fast Reads/sec

    Observe this counter for the rate at which applications bypass the file system and access data directly from the cache. A value over 50% indicates the application is behaving efficiently. Fast reads reduce processor overhead and are preferable to I/O requests.

  • Cache\Lazy Write Flushes/sec

    Review this counter for the rate at which an application changes data, causing the cache to write to the disk and flush the data. If this value reflects an upward trend, memory might be becoming low. Lazy write flushes are a subset of data flushes. The lazy writer thread in the system process periodically writes changed pages from the modified page list back to disk and flushes them from the cache. This thread is activated more often when memory needs to be released for other uses. This counter counts the number of write and flush operations, regardless of the amount of data written.

  • Cache\Lazy Write Pages/sec

    Examine this counter value for the rate at which pages are changed by an application and written to the disk. If the counter value is increasing, this can indicate that memory is becoming low. Cache\Lazy Write Pages are a subset of Data Flush Pages.

  • Cache\Read Aheads/sec

    Use this counter to monitor the rate at which the Cache Manager detects that the file is being accessed sequentially. Sequential file access is a very efficient strategy in most cases. During sequential file access, the Cache Manager can read larger blocks of data into the cache on each I/O, thereby reducing the overhead per access.

  • Memory\Cache Bytes

    Monitor this counter for growth or shrinking of the cache. The value includes not only the size of the cache but also the size of the paged pool and the amount of pageable driver and kernel code. Essentially, these values measure the system’s working set.

  • Memory\Cache Faults/sec

    Observe this counter for the rate at which pages sought in the cache were not found there and had to be obtained elsewhere in memory or on the disk. Compare this counter with Memory\Page Faults/sec and Pages Input/sec to determine the number of hard page faults, if any.

Note

Performance Meter (Perfmtr.exe), a tool on the Windows 2000 Server Resource Kit companion CD and the SDK lists, among other statistics, data about the file system cache. For more information, see the Rktools.hlp or the SDK documentation.

Interpreting Changes in Cache Counter Values

Administrators need to watch for signs from the cache counters that low memory is causing insufficient cache size and consequently that cache usage is resulting in unnecessary disk I/O, which degrades performance. Monitor for the following conditions, using the counters as described. (Options for improving these conditions include defragmenting the disk and adding memory.)

Reduction in Cache Size

When memory becomes scarce and working sets are trimmed, the cache is trimmed as well. If the cache grows too small, cache-sensitive processes are slowed by disk operations. To monitor cache size, use the Memory\Cache Bytes and Memory\Available Bytes counters. Note that the effect of a smaller cache on applications and file operations depends on how often and how effectively applications use the cache.

Frequent Cache Flushing

Frequent cache flushing might occur if data is written to the disk frequently in order to free pages. Data flush counters reflect cache output. Monitor the Cache\Data Flushes/sec and Cache\Lazy Writes Flushes/sec counters.

Cache\Pin Reads/sec tells you how often the cache is reading data with the intention of writing it. A pin read is when data is mapped into the cache just to be changed and is then written back to disk. It is pinned in the cache to be sure the data being changed is not written to disk until the update is complete. Creating a file or changing its attributes results in a pin read. Changing file contents does not result in a pin read. Cache\Pin Reads/sec can predict flushing activity.

High Rates of Cache Misses

High cache miss rates indicate that requested data is not available in physical memory and must be retrieved from the disk. Monitor the Cache object counters that record hit percentages and hit rates (such as Cache\Copy Read Hits % and Cache\Copy Read Hits/sec).

Make sure to review both hit percentage and hit activity counters to ensure that your data gives an accurate picture of cache efficiency. For example, you might notice that your hit percentage is very high (90% on average), implying that the cache is highly efficient. However, when you examine hit activity, you might notice that only a few copy reads have occurred during the sample. In this case, relying on the percentages would have given you a false impression of cache effectiveness. Therefore, examining hit percentages over a range of activity rates is recommended.

For computers running Windows 2000 Server, you might also want to monitor MDL Read Hits % and MDL Reads/sec. The Server service might use MDL reads rather than copy reads for large data transfers. MDL reads rely on direct memory access (DMA) for better overall performance.

High Rates of Cache Faults

Although you cannot tell from the Memory\Cache Faults/sec counter value alone, an increase in cache faults might mean that hard page faults are occurring, resulting in disk activity. Memory\Cache Faults/sec reports fault activity for the system working set, including hard and soft page faults. Because the cache counters do not provide conclusive information about this, you must monitor Memory\Pages Input/sec to determine if hard page faults are occurring as shown in Figure 16.8.

Figure 16.8 Cache Faults/sec and Memory Counters

If Cache Faults/sec values increase and hit-percentage counter values decrease, it is likely there is not enough memory to create an efficient cache. When insufficient memory forces the system to maintain a small cache size, disk I/O tends to increase.

You can see the impact of cache and memory activity on the disk by adding Memory\Pages Output/sec to Cache\Data Flush Pages/sec. This total is approximately equal to the page equivalent of Disk Write Bytes/sec for the LogicalDisk or PhysicalDisk counters. As the Pages Output/sec and Data Flush Pages/sec counter values increase, so does the value of Disk Write Bytes/sec, reflecting the increasing disk writing activity. (Differences in values can be attributed to the sampling behavior of Performance Monitor.) Similarly, there is a corresponding read impact: look at Memory\Pages Input/sec; this should equal the number of bytes of memory reported under Disk Read Bytes/sec but expressed in pages for the LogicalDisk or PhysicalDisk counters as described in “Assessing the Effect of Page Faults on the Disk” earlier in this chapter.


Resolving Memory and Cache Bottlenecks

While monitoring your memory and cache resources, you might discover memory and cache bottlenecks in your system. As a result, you might need to optimize cache usage, replace applications, or even add new memory. The following tips can assist you with your decision-making process.

Optimizing Cache Usage

Even though you cannot change the cache itself, there are a few things you can do to make the most of the cache.

  • For applications that you develop or maintain, improve the locality of reference in your application’s data structures. This improves its cache performance and minimizes its working set so that it uses less space in memory. In addition, it reduces disk access that can slow performance systemwide.
  • If you are running Windows 2000 Server, you can direct the Virtual Memory Manager to give the cache higher priority for space than the working sets of processes. See “To adjust Server Optimization settings” earlier in this chapter to change memory management settings. To favor the cache, choose Maximize Throughput for File Sharing. To favor working sets, choose Maximize Throughput for Network Applications.
  • Change the way work is distributed among workstations. Try dedicating a single computer to memory-intensive applications such as CAD/CAM and large database processors.
  • Add memory. When memory is scarce, the cache is diminished and cannot do its job. After the new memory is installed, the Virtual Memory Manager expands the cache to use the new memory.

Resolving a Memory Bottleneck

Although adding memory is the easy solution to a memory bottleneck, it should not be the first solution you undertake. Try the following, more cost-effective alternatives before spending money on additional memory. If you ultimately decide to add memory, note that the maximum amount of memory recommended for a computer running Windows 2000 Server is 4 GB for an Intel-based system and 32 GB for a Alpha configuration.

  • Monitor your applications and replace or correct those that leak memory or use it inefficiently.
  • Modify your application to improve the locality of reference. The Working Set Tuner, included in the Win32 SDK, recommends an optimal organization of code functions.
  • Increase the size of the paging file. In general, the bigger you can make it, the better it is. You can also have multiple paging files, though you should only have multiple paging files per physical drive when the drive is not partitioned into logical drives. Striped volumes can be used. This improves the read-write rates for the paging file because the work is distributed over multiple disks.
  • Check the available space on your disks. If you are using a large paging file and space is not available, this can produce the symptoms of a memory bottleneck.
  • To conserve memory, avoid using some display and sound features. Features that can drain memory include animated cursors, desktop icons, large-bitmap wallpaper, and some screen saver programs; removing or disabling them can offer some benefit on a memory-constrained system. Reducing display color depth and screen resolution can also save memory but to a lesser degree.
  • To free memory, turn off services you do not use. Stopping services that you do not use regularly saves memory and improves system performance. However, make sure you understand the ramifications of stopping a service before you do so.
  • Remove unnecessary protocols and drivers. Even idle protocols use space in the paged and nonpaged memory pools. Drivers also use memory. You can see how a driver uses memory with Pool Monitor (Poolmon.exe).
  • Replace 16-bit systems with 32-bit systems for better reliability and performance.
  • If you have other computers that are underutilized, move memory-intensive applications to those computers.


Measuring Multiprocessor System Activity

Managing the distribution of interrupt, thread, and deferred procedure call (DPC) activity for optimal performance means understanding factors that can limit and enhance the throughput on an symmetric multiprocessing (SMP) system.

In This Chapter

Overview of SMP Performance and Monitoring

Monitoring Activity on Multiprocessor Systems

Optimizing and Tuning Multiprocessor Installations

Application Design and Multiprocessor Performance

Network Load Balancing and Scaling

Related Chapters in the Resource Kit

  • For more information about general monitoring procedures, see “Overview of System Monitoring” earlier in this book.
  • For more information about monitoring uniprocessor systems, see “Analyzing Processor Activity” earlier in this book.
  • For more information about system problems that can effect performance, see “Troubleshooting Tools and Strategies” later in this book.


Overview of SMP Performance and Monitoring

Microsoft® Windows® 2000 is designed to implement symmetric multiprocessing (SMP). With symmetric multiprocessing, the operating system can run threads on any available processor. As a result, SMP makes it possible for applications to use multiple processors when additional processing power is required to increase the throughput capability of a system. Similarly, on Windows 2000, hardware interrupts and deferred procedure calls (DPCs), software interrupts at a low Interrupt Request Level (IRQL), may also run on any available processor determined by the hardware abstraction layer (HAL). Although most SMP systems running Windows 2000 dynamically distribute threads and hardware interrupts equally among all available processors, you may sometimes want to restrict threads and interrupts to one or more processors rather than distribute them in order to improve processor cache locality and overall system throughput.

The following overview describes workloads which benefit most from scaling to an SMP system. This chapter also provides an overview of the steps involved in monitoring SMP systems and discusses the impact of SMP on system resources.


Benefits of Scaling

The process of adding processors to your system to achieve higher throughput is called scaling. Applications that benefit from multiprocessor configurations are typically those that are processor-intensive, such as database servers, Web servers, and active file and print servers. Processor-intensive applications that use multiple processes or are multithreaded with asynchronous execution are also well suited to multiprocessor systems. Systems requiring heavy computation capability, including detailed calculation for scientific or financial applications, complex graphic rendering, computer aided design (CAD)– based modeling, or electrical-engineering design may also demand multiprocessor systems.

To understand the degree of benefit you can attain from scaling to multiple processors, determine the scale factor. The scale factor is a measurement of the increase in throughput you can expect to achieve. You can determine the scale factor of the system by comparing the throughput of one processor to the throughput of multiple processors.

The formula for computing scale factor is:

Number of transactions per second on n processors ÷ Number of transactions per second on 1 processor

For example, if a single-processor system is using 100% of the processor handling 100 transactions per second and, with the addition of three processors, the resulting four-processor system can handle 320 transactions per second, the scale factor of the system is 3.2.


Analyzing Performance on SMP Systems

You can monitor the activity of your SMP system by using Performance Monitor and its counters. To evaluate your system’s performance, look at the following factors:

  • Processor utilization and queue length. You may need to partition the workload so that a particular processor handles a particular workload in order to achieve better performance. For more information, see “Optimizing and Tuning Multiprocessor Installations” later in this chapter.
  • Processor performance data, such as context switches, interrupts, threads, and processes. Activity rates and usage levels for these types of data that are higher than expected for a particular throughput can reveal inefficiencies in how your processors handle their workload. You may need to partition these types of activity. For more information, see “Optimizing and Tuning Multiprocessor Installations” later in this chapter.
  • Overall resource utilization on your system. Scaling to multiple processors can increase the load on resources such as disk, memory, and network components and it might be necessary to increase the capacity of these components. For more information, see “SMP Impact on System Resources” later in this chapter.

Note

Application developers are in the best position to control how processes behave in an SMP environment. “Application Design and Multiprocessor Performance” later in this chapter provides guidelines for application developers who want to design programs that run well on multiprocessor systems.


SMP Impact on System Resources

The increased processing power and throughput on SMP systems can cause other system resources such as memory, the system bus, disks and network to have a heavier load. For example, arbitration among shared resources increases memory latency. This is because code running on SMP systems needs to lock shared data to ensure data integrity, and locking shared data may result in contention for shared data structures. Further, the synchronization mechanisms used to lock shared data structures will increase the processor code path. As a result, when the number of processors on a system is scaled up, it is generally necessary to increase other resources on the system, such as memory, disks, and network components, as described in the following.

Processors. A large processor cache delivers the best performance. In multiprocessor configurations, the cache can reduce memory latency on the shared system bus thereby reducing resource contention and access.

Memory. It is recommended that your SMP system have more than 64 MB of memory because it is likely that it carries a heavier workload than an single-processor system, and runs more processes and threads. In general, you should scale memory with processors. For example, if a uniprocessor system requires 64 MB of memory and a second processor is added to increase the throughput, the memory should be doubled to 128 MB. Although multiprocessor systems do require additional memory because of their per-processor data structures, the additional memory required is minimal compared to the typical demand of the working sets for the additional processes and threads running in a multiprocessing environment.

Disk and network components. When adding processors to the system it will generally be necessary to increase the disk and network capacity of the system.

For information about the adequacy of resources in your configuration, see the earlier chapters in the Optimization section of this book.


Monitoring Activity on Multiprocessor Systems

In addition to counters used to determine a baseline, as described in “Overview of Performance Monitoring,” and processor-specific counters, as described in “Analyzing Processor Activity,” the counters listed in Table 19.1 are useful for obtaining detailed information when evaluating the performance of multiprocessor systems.

Note

In regard to Pentium counters, the Pentium performance object includes counters that display data on interrupts and DPCs that are valuable for multiprocessor system monitoring. Pentium counters are counters designed to monitor systems based on the Pentium, Pentium Pro, Pentium II, and Xeon processors. The counters are described in Counters Help on the Microsoft® Windows® 2000 Resource Kit companion CD. You must install the Pentium counters before you can use them. These counters are provided on the Windows Resource Kit Web site.

If you have installed the Kernel Profiler (kernprof on the Windows 2000 Resource Kit companion CD), you can use the counters with interrupts, available on systems based on the Pentium Pro, Pentium II and Xeon processors, to conduct more precise profiling than using the timer interval clock. When the timer interval clock is used for sampling, some code paths are hidden, and events that are triggered by timer events may be missed. The Pentium counters with interrupts do not present the same problem because they are not synchronized with the interval clock.

Table 19.1 Multiprocessor System Counters and Descriptions

Object(Instance)\Counter | Description
Pentium\% Data Cache Misses | Analyzes the processor L1 data cache.
Pentium\% Code Cache Misses | Analyzes the processor L1 instruction cache.
Pentium\Bus Utilization (clks)/sec | Analyzes the system bus.
Pentium\Hardware interrupts received/sec (Pentium Pro processors only) | Shows the rate at which hardware interrupts are detected by the processor’s internal counters.
Pentium\Interrupts/sec (Pentium processors, excluding Pentium Pro) | Shows only maskable 1 hardware interrupt request pin (INTR) and non-maskable interrupt input (NMI) values from hardware.
Process(process_name)\Thread Counter | Shows the last observed value, not an average. You need to monitor it at various times to get an accurate picture of activity.
Processor\% DPC Time | Determines how much time the processor is spending processing DPCs. DPCs originate when the processor performs tasks requiring immediate attention, and then defers the remainder of the task to be handled at lower priority. DPCs represent further processing of client requests.
Processor\% Interrupt Time | Determines how much time the processor is spending processing interrupts. Interrupts are generated when a client requests a connection or sends data. If processor time is more than 90 percent and this value is greater than 15 percent, the processor is probably overburdened with interrupts.
Processor\DPCs Queued/sec | Monitors the rate at which DPCs are queued on a particular processor. (This counter does not measure the number of DPCs in the queue.)
Processor\Interrupts/sec | Reflects the rate at which the processor is handling interrupts.
System\Context Switches/sec | Indicates that the kernel has switched the thread it is running on a processor. A context switch occurs each time a new thread runs, and each time one thread takes over from another. A large number of threads is likely to increase the number of context switches. Context switches allow multiple threads to share time slices on the processors, but they also interrupt the processor and might reduce overall system performance, especially on multiprocessor computers. You should also observe the patterns of context switches over time.
System\System calls/sec | Monitors the frequency of calls to Windows 2000 system service routines. These are the services exported to applications from the kernel.
Thread(process_name\Thread #)\% Processor Time | Monitors processor time usage by threads on the system.
Thread\Context Switches/sec | Monitors context switches generated by individual threads.
1 A maskable interrupt occurs when the processor can defer or block handling of the interrupt. These are typically generated by external I/O devices. A nonmaskable interrupt is used when no block or delay is allowed.

The following sections describe how to monitor and analyze the values reported in specific areas:

  • Processor Time Data
  • Processor Queue Lengths
  • Interrupt and DPC Data
  • Thread and Context Switching Data


Examining Processor Time Data

The Processor\% Processor Time counter reports CPU utilization on your system. It is important to monitor this counter on SMP systems just as it is on uniprocessor systems. Observe processor usage patterns for individual processors and for all processors over an extended period. Also consider the number of threads in the system’s processor queue to determine if high processor usage is limiting the system’s ability to accomplish work.

Figure 19.1 depicts a high rate of processor use on a multiprocessor system.

Figure 19.1 Example of High Rate of Processor Usage on an SMP System

On multiprocessor systems, the Processor\% Processor Time value reported by Performance Monitor will never exceed 100 percent for any particular processor or thread. On the other hand, the value of the % Processor Time reported for the Process object can report values over 100 percent; if such values occur, this could indicate that threads of the process are cumulatively using more than 100 percent of a processor. To get more detailed information, use the Thread object counters to analyze the processor time each thread within a process is using. Investigating other data described in this section, such as DPC activity or context switching, may help you to interpret high processor-time values.


Observing Processor Queue Length

The System\Processor Queue Length counter is a rough indicator of the number of threads each processor is servicing. The processor queue length, sometimes called processor queue depth, reported by this counter is an instantaneous value that is representative only of a current snapshot of the processor, so it is necessary to observe this counter over a long period of time. Also, the System\Processor Queue Length counter is reporting a total queue length for all processors, not a length per processor.

The optimal processor queue length can vary based on processor utilization or other factors as follows:

  • For busy systems that experience processor utilization in the 80 to 90 percent range and use thread scheduling, the queue length should range from one to three threads per processor. For example, on a four-processor (4P) system, the expected range of processor queue length on a system with high CPU activity is 4 to 12.
  • On systems with lower CPU utilization, the processor queue length is typically 0 or 1.
  • For systems running services that use fiber scheduling, such as Microsoft® SQL Server™ version 7.0, the typical processor queue length will range between 0 and 1, because there is a single fiber that is scheduling threads per processor. (Fiber scheduling is enabled when the lightweight pooling option is selected.)

If the processor queue length exceeds the value recommended in the preceding list, it generally indicates that there are more threads than the current processor can service in an optimal way. Reducing the number of threads or providing more CPU power, either by adding processors or upgrading to faster processors, are optional methods of shortening the processor queue.

Figure 19.2 shows a long queue developing when processors are working at capacity.

Figure 19.2 Example of Long Queue Developing at High Processor Usage

When you begin to see longer queues, monitor additional counters for DPC and interrupt activity, as described in the following sections.


Analyzing Interrupt and DPC Activity

On a multiprocessor system, interrupt-activity rates on different processors indicate how your system is distributing its workload among the available processors. Similar to context-switching rates, interrupt-activity rates can reveal distribution of work in a way that is inefficient and costly in terms of overall performance.

Most SMP systems can distribute hardware interrupts for handling on any of the processors. This allows interrupts to be handled by all processors, rather than concentrating the load on a single processor for better throughput. However, the DPCs that arise from those hardware interrupts may run on different processors as well, meaning that their shared data is not cached but must be rewritten and reread. In addition, the assignment of a DPC to run on a different processor causes an interprocessor interrupt (IPI). An IPI is a high-Interrupt Request Level (IRQL) interrupt. Although it has a relatively low cost in terms of performance, like any interrupt, it reduces the efficiency of the processor cache of the target processor because cache lines are displaced by the interrupt.

At times when the system is developing a long processor queue or experiencing high rates of processor usage, observe the proportion of the processor's time that is spent servicing interrupts and DPCs. Compare the values of the Processor\% Interrupt Time and Processor\% DPC Time counters to Processor\% Processor Time.

Figure 19.3 shows heavy processing burden due to high rates of interrupts and DPCs.

Figure 19.3 Example of Processor Activity when Interrupts and DPCs are Frequent

If interrupt and DPC processor-time values are high, you need to investigate further:

  • Observe the rate of interrupts and DPCs for each processor.
  • Note whether interrupts and DPCs are distributed equally among all processors or whether one or more processors are servicing all of the interrupts or DPCs.

In general, a very high rate of interrupts may indicate a disk or a network adapter that needs upgrading or replacing. Test your components and rule out a hardware problem before proceeding. However, on a multiprocessor computer, the most common interrupt-related problem is its distribution among processors. It may be necessary to redistribute interrupts or DPCs or upgrade to a faster processor to avoid a bottleneck.

For information about how to manage interrupt, DPC, and other activity for better SMP performance, see “Optimizing and Tuning Multiprocessor Installations” later in this chapter.


Monitoring Context Switches and Threads

When examining a multiprocessor system, monitor Thread\Context Switches/sec and Thread\% Processor Time to observe which threads are running on which processors, and to find out how frequently they switch between them to do the work of a particular process. This is important to know because there can be occasions when the switching of threads impedes optimal performance.

Typically, Windows 2000 uses a soft affinity algorithm that favors running a thread either on the last processor that serviced it or its ideal processor, a processor specified by the program developer in the application code. Affinity is the mechanism for associating a process with a processor. With soft affinity, the association can vary between different processors; with hard affinity, the association is fixed to a specific processor. In general, software affinity is an optimal design that takes advantage of cache locality. However, when threads migrate from one processor to another processor, they may no longer have access to previously cached data and must re-read data from memory. At worst, thread migration may cause false sharing because, to the cache coherency hardware of the CPU, it may appear that multiple processors are sharing a cache line.

Therefore, monitoring context-switching activity and thread processor usage is useful to application developers in understanding thread behavior.


Optimizing and Tuning Multiprocessor Installations

One way to get maximum performance from a system is to partition your workload so that a specific processor is servicing all threads, interrupts, and DPCs associated with that work. This avoids the inefficiencies introduced when these items are distributed among processors, resulting in frequent context switching and loss of cache locality. Full partitioning, that is, partitioning threads and interrupts by processor, is extremely effective in providing linear scaling on SMP systems. Depending on your workload, you may use a combination of the partitioning strategies or implement one strategy at a time.

Strategies for managing threads, interrupts, and DPCs for better overall SMP performance are described in the following sections:

  • Thread Partitioning.
  • DPC (Software Interrupt) Partitioning.
  • Hardware Interrupt Partitioning.

Note

When using server applications, such as Microsoft SQL Server, Microsoft® Exchange Server, or Microsoft® Internet Information Services, consult the documentation provided with those servers, which might have built-in optimizations.


Thread Partitioning

Partitioning threads to specific processors is called setting a processor affinity mask. The affinity mask contains bits for each processor on the system, defining which processors a particular process or thread can use. When you set affinity for a process to a particular processor, all threads of the process inherit the affinity to the same processor.

By design, Windows 2000 uses soft processor affinity, determining automatically which processor should service threads of a process. The soft affinity for a thread is the last processor on which the thread was run or the ideal processor of the thread. The Windows 2000 soft affinity thread scheduling algorithm enhances performance by improving the locality of reference. However, if the ideal or previous processor is not available, soft affinity allows the thread to run on other processors, allowing all processors to be used to capacity.

Windows 2000 also provides hard processor affinity, meaning that the processor affinity mask restricts the threads affected by the affinity mask to the processor specified by the mask. Threads restricted by a hard affinity mask may not run on processors that aren’t included in the affinity mask. Hard affinity used with partitioning can improve performance of an SMP system substantially. However, be cautious when using hard affinity because it may cause the processors to have unbalanced loads. If processes that have had their affinity set to a specific processor are causing high CPU utilization on that processor while other processors on the system have excess processing capacity, the processes for which a hard affinity has been set may run slower because they cannot use the other processors.

If you want to ensure that a particular process or application doesn’t have to share processing power with other tasks, you can use hard affinity to dedicate that process to one processor, leaving the remaining ones available for other work. This is easy to do using the Set Affinity command in Task Manager. For more information on Task Manager, see “Overview of Performance Monitoring” earlier in this book.

Figure 19.4 shows the user interface for setting processor affinity.

Figure 19.4 Processor Affinity Dialog Box in Task Manager

Figures 19.5 and 19.6 show how partitioning a process may affect processor usage. Notice that, after partitioning, processor 1 is almost idle while processor 0 is heavily loaded.

Figure 19.5 Example of Processor Usage Before Partitioning

Figure 19.6 Example of Processor Usage After Partitioning

Another processor-partitioning option would be to divide discrete work items, such as tables in a database, among different processors. Consult the documentation accompanying your database software for information on partitioning databases for optimum performance.

Note

Using functions in the Platform SDK, application developers who create applications using job objects can specify that all processes associated with the job object use the same processor affinity.


DPC (Software Interrupt) Partitioning

In an environment with a large volume of network processing, you may want to control DPCs that arise from interrupts generated by your network adapters. The default handling of these DPCs may not allow you to attain optimal performance for your SMP configuration if you have a network-intensive workload.

Depending on the processor platform detected by the HAL, the operating system may configure different default settings to handle DPC distribution. If Windows 2000 detects that your system contains processors that support symmetric interrupt distribution (this includes PentiumPro or later processors, and some Pentium processors), the operating system defines a registry entry called ProcessorAffinityMask under HKEY_LOCAL_MACHINE
\System\CurrentControlSet\Services\NDIS\Parameters with a value of 0. This setting instructs the operating system to direct DPCs to the processor that handled the interrupt that generated the DPC. By doing so, the system improves processor cache locality and reduces interprocessor interrupts. For information about ProcessorAffinityMask and about editing the registry, see “Technical Reference to the Windows 2000 Registry,” in Registry Tools under Computer Management Tools on the Windows 2000 Resource Kit companion CD.

On computers containing Pentium processors that do not support symmetric interrupt distribution, Windows 2000 sets a default affinity that associates DPCs with installed network adapters that comply with Network Driver Interface Specification (NDIS). Most network adapters currently in use are NDIS-compliant. The first adapter is associated with the highest numbered processor, the second with the next highest-numbered processor, and so on. For example, in a system with five network adapters and four processors, the adapters would be associated with processors as shown in Table 19.2.

Table 19.2 Default Affinity Associations for Network Adapters and Processors

Network Adapters | Associated with Processor Number (Numbering Starts at 0)
0 | 3
1 | 2
2 | 1
3 | 0
4 | 3

This is the optimal configuration for many applications because it allows all DPCs to be handled on the high processor and have per-processor I/O completion ports handle the network traffic. I/O completion ports ensure that interrupts are handled on the processor that generated them, thereby optimizing processor-cache locality.

Note

I/O completion ports are synchronization mechanisms defined in the Win32 API that are used with asynchronous I/O to limit the number of threads that can share memory or hold a lock. The value defining that limit is called the concurrency value. When the concurrency value is set to 0, the completion port allows the number of active threads to be equal to the number of processors on a system. When there is one active thread per processor, there is no need for context switching or memory sharing. If a thread becomes blocked, the completion port allows another thread to be activated. On completion of a work item, the thread returns to the completion port for more work, thereby reducing context switching and improving locality of reference.

On a system with a relatively light network load, keeping the DPC processing on a single processor will improve the cache locality for the network DPCs and prevent network interrupts from occurring while a running thread has a lock on most of the processors. However, this distribution does not work well on systems with significant amounts of network traffic. In this case, you may want to use a registry editor to change the value of the ProcessorAffinityMask entry to 0 to ensure that all DPCs are serviced on the processor that initiated the corresponding interrupt.

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console whenever possible.

You can also add network adapters so that you have one network adapter card for each processor. Ndis.sys then distributes DPCs to all processors. On x86-based systems that comply with the Multiprocessor Specification (MPS), if the number of network adapter cards on your system equals the number of processors, best performance is generally obtained by using the IntBind tool to bind interrupts from each network adapter card to a particular processor and to set the value of the NDIS ProcessorAffinityMask registry entry to 0. Generally, you should only add a network adapter if you also need the bandwidth, because each additional network adapter has some intrinsic overhead.

However, if one of the processors is nearly always active (if Processor\% Processor Time consistently equals 100 percent) and more than half of its time is spent servicing DPCs (that is, if Processor\% DPC Time exceeds 50 percent), then adding a network card is likely to improve system performance.

If you are adding or upgrading network adapters, choose adapters with drivers that support interrupt moderation or avoidance. Interrupt moderation allows a processor to process interrupts more efficiently by grouping several interrupts to a single hardware interrupt. Interrupt avoidance allows a processor to continue processing interrupts without new interrupts queued until all pending interrupts are complete.

If your network adapter does not use NDIS miniport drivers, you cannot modify the distribution of DPCs for better performance. For this reason, and because other NDIS optimizations may be unavailable, you may want to consider upgrading your network adapter.

Note

By default, DPCs for disk interrupts remain on the processor that took the interrupt.


Hardware Interrupt Partitioning

Some processor platforms can distribute interrupts across available processors; this capability is called symmetric interrupt distribution. These platforms typically include PentiumPro and later processors; however, some Pentium processors also have this capability. Although symmetric interrupt distribution is designed as a way to balance interrupt activity, it can sometimes result in poor processor-cache performance. Partitioning interrupts to a specific processor is a strategy for addressing this problem. The IntBind tool on the Windows 2000 Resource Kit companion CD enables you to set the affinity for interrupts generated from disks or network adapters to a particular processor. This improves efficiency by taking advantage of cache locality, which can be lost when interrupts are serviced by any available processor, rather than the one on which they were queued.

Unfortunately, your hardware may limit your ability to make use of this tool. Support for partitioning interrupts depends on the characteristics of the processor and the interrupt assignment mechanism, such as the Advanced Programmable Interrupt Controller (APIC) on systems based on the Intel Pentium, PentiumPro, Pentium II and Xeon processors. Consult your processor vendor for details about the interrupt-distribution capabilities of your hardware. In addition, see Windows 2000 Professional Help for the Resource Kit tools for information about the requirements for using IntBind.

Note

If you find that your hardware does not support use of IntBind, you may want to consider upgrading to a processor that provides this support.

If you cannot upgrade your processor but still want to control the flow of interrupts on your SMP system, network adapter technology can provide an alternative. To help improve processor performance, some newer network adapter drivers provide an advanced feature known as interrupt moderation. When the driver detects a high rate of interrupts from the network adapter, the interrupt-moderation code disables interrupts and accumulates the interrupts in a buffer instead of sending them to the processor. When the processor has completed its work, the interrupts are re-enabled. Using a network adapter that supports interrupt moderation can provide better performance if your workload is network-intensive.


Upgrading or Adding Processors

If you cannot improve the efficiency of your SMP configuration through the preceding steps, you may want to add or upgrade system processors. When doing so, choose processors with a large secondary (L2) cache. File server applications, web servers, and databases are a few examples of the many workloads that benefit from a large processor cache. A large processor cache, ranging from 512K to 4MB or larger, is recommended to improve performance on active servers running web servers or other connection-intensive operations.


Application Design and Multiprocessor Performance

The design of applications and services has a significant influence on the performance of those programs in an SMP environment. This section is a brief summary of techniques that applications designers can implement to maximize the efficiency of their program on multiprocessing systems. More detailed discussions of writing applications that scale well to multiple processors appear on the Microsoft® Developer Network (MSDN).

Application developers can optimize application performance for SMP systems in following ways:

  • Keep the number of threads to a minimum. Generally, two to four application or server threads per processor works well.
  • Limit processor queue depth. Keep the processor queue length (the number of ready threads waiting to run) in the range of two to three per processor. Depending on the characteristics of the application, such as the time a thread spends blocked or waiting for an I/O operation, the number of threads can be adjusted.
  • Use a thread pool rather than one thread per client. It is more efficient to use a thread pool with an I/O completion port rather than to have a thread for each client, with the thread pool partitioned to each processor.
  • Use I/O completion ports. I/O completion ports control the number of active threads to yield optimal throughput and to ensure completion of a work item from start to finish on the same processor.
  • To minimize the cost of synchronization mechanisms, keep critical sections small and avoid shared data whenever possible. Synchronize shared data but do not try to synchronize code paths. Although critical sections — synchronization objects defined in the Win32 API — are a very fast method for mutual exclusion within a single multithreaded process, when contention arises, critical sections initiate context switching. Large numbers of critical section or spinlock acquisitions cause heavy data-access sharing and should be avoided.

    Spinlocks are an extension of IRQL on SMP systems. They are used to synchronize kernel and driver data structures among interrupts, DPCs or threads of execution running concurrently on an SMP machine. A thread acquires a spinlock before accessing protected resources. The spinlock keeps other processors from accessing the critical section (shared data) until the spinlock is released. A processor that is waiting for the spinlock loops until the spinlock is released.

    Another characteristic of spinlocks is the associated IRQL. Attempted acquisition of a spinlock temporarily raises the IRQL of the requesting processor to the IRQL associated with the spinlock. This prevents all lower IRQL threads on the same processor from running until IRQL is lowered. Interrupts at a higher IRQL can preempt the executing thread. Therefore, the spinlock may not be acquired on the same processor while it is held. In a driver, if IRQL is already at the desired level, use the spinlock acquire and release APIs that don’t change IRQL. For more information about spinlocks and associated IRQLs, see the Driver Development Kit documentation in the MSDN Library at http://msdn.microsoft.com..

  • Avoid nested locks. Nesting locks can cause performance problems and reliability problems, such as deadlock. Always try to avoid nesting critical sections and spinlocks.
  • Partition the workload, including interrupts. Whenever possible, partition the workload a server or application handles. Partitioning allows very effective use of system resources.

    In addition, intensive memory access due to copying, zeroing (for C2 security) and checksum operations reduce the ability to scale effectively across multiple processors. You can identify some of these problems through profiling. For more information about profiling tools, see the Software Development Kit (SDK) documentation in the MSDN Library at http://msdn.microsoft.com.

    Change applications to prevent data that may be used concurrently by threads on different processors from residing in the same cache block, or use processor affinity to force use of updated cache blocks only on a single processor.

  • Use asynchronous, overlapped I/O. In overlapped mode, a server application can initiate multiple I/O requests without waiting for previous requests to complete, thereby enabling it to service multiple clients asynchronously using a single thread.


Network Load Balancing and Scaling

Another scaling solution is provided by Network Load Balancing. With Network Load Balancing, two or more computers are combined to provide availability and scalability benefits to mission-critical applications.

A concept called shared nothing supports scalability in clusters. Clusters that use shared nothing have their own system bus and access to disks and networks. This reduces the sharing issues of SMP systems because additional resources are available without extra arbitration. In general, shared nothing is similar to partitioning in an SMP environment except that the resource access latency is lessened. However, if cluster members need to communicate, the latency of communication is much larger than in an SMP system. In addition, if sharing is necessary (that is, the cluster is not a shared-nothing environment), the cost of sharing in a cluster is much higher than the cost of sharing in an SMP system.

For information about Network Load Balancing, see “Network Load Balancing” in the Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide.


Windows 2000 Stop Messages

When it detects an error condition from which it cannot recover, Microsoft® Windows® 2000 generates a variety of system messages including hardware malfunction messages and Stop messages, commonly referred to as blue screen messages. Learning to interpret the meaning of various Stop messages, as well as taking appropriate action to resolve the problems that generated the errors, is critical in a production environment. In addition, it is vital that technical support personnel and power users know how to handle system hardware failure correctly. "Windows 2000 Stop Messages” contains general information and troubleshooting tips about Stop messages and is intended for advanced users, system administrators, and developers.

In This Chapter

System Messages

Stop Messages

Hardware Malfunction Messages

Related Chapters in the Resource Kit

  • For kernel debugging information, see “Setting Up the Kernel Debugger” in this book.

Additional Resources

  • For more information about Stop messages, see the Microsoft Knowledge Base, available through the Support Online Web site at http://support.microsoft.com/support/. To take advantage of this depository of technical information, you must be a registered user. If you attempt to view a Knowledge Base article and you are either not registered or are not recognized by the system, you are directed to a registration page where you can register for this free service or retrieve your online profile.
  • The Hardware Compatibility List (HCL) is available on the Microsoft® Windows® 2000 Resource Kit companion CD. The latest version of the HCL can be found on the Microsoft Web site at http://www.microsoft.com.
  • For more information about Stop messages, error messages, and the Resource Kits, see the ResourceLink Web site at http://mspress.microsoft.com/reslink.
  • The latest Service Packs and hotfixes for Windows 2000 are available from the Microsoft FTP site at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/.
  • The file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK) includes Windows 2000 status code definitions. To view this file, you must first download the DDK from http://www.microsoft.com/ddk.


System Messages

The two types of system messages generated by Windows 2000 depend on the event being reported.

Stop messages. Generated in character-mode. They occur when the Windows 2000 kernel detects a condition from which it cannot recover.

Hardware malfunction messages. Generated in character-mode. They occur when the processor detects a hardware condition from which the system cannot recover.

These messages were created to cover everything that could possibly happen to halt the system, so you will never see most of them. For example, the Stop message 0x0000003E, or “Multiprocessor Configuration Not Supported” is displayed only if multiple but asymmetric CPU types, such as a 486 and a Pentium, are installed on the same system.

To diagnose and resolve Stop messages, many users also need technical assistance from a person who has been trained to support Windows 2000. In some circumstances, running a kernel debugger on the faulty system might be required. For more information about the Windows 2000 debugger tools, see the chapter “Setting Up the Kernel Debugger” in this book.


Stop Messages

Stop messages occur when the Windows 2000 kernel detects a condition from which it cannot recover. They are always displayed on a full screen in character mode, as shown in Figure 25.1, rather than in a Windows-mode dialog box. Each message is uniquely identified by a hexadecimal number and a string indicating the error’s symbolic name. In addition, Stop messages are usually followed by a series of up to four additional hexadecimal numbers, shown in parentheses, which identify error parameters, as shown in the following example:

*** STOP: 0x0000001E (0xC0000005, 0xFDE38AF9, 0x00000001, 0x7E8B0EB4)
KMODE_EXCEPTION_NOT_HANDLED ***

To a trained technician, the content of the symbolic name string might suggest which part of the system is affected by the error that left the kernel no recourse but to stop. However, it is also possible that the cause might be in another part of the system. Figure 25.1 is an example of a complete Stop message screen generated by Windows 2000.

Figure 25.1 Stop Message Screen


Stop Message Screen Sections

As shown in Figure 25.1, a Windows 2000 Stop message screen contains three major sections: bugcheck information, recommended user action, and debug port information. Whenever a Stop message is displayed, first examine the bugcheck information section for assistance with troubleshooting. Second, examine the recommended user action section for troubleshooting information; Windows 2000 now incorporates troubleshooting tips, including some custom tips relevant to the particular error detected. Finally, check the debug port information section to see whether or not a memory dump file was saved for later use by a kernel debugger.

Bugcheck Information

The bugcheck information section includes the Stop code, also known as the bugcheck code, which contains up to four developer-defined parameters, enclosed in parentheses, and the symbolic name of the error. In Figure 25.1, the Stop code is 0x0000001E.

The bugcheck information section frequently, but not always, includes a line that lists the specific hexadecimal memory address of the source problem, along with the particular driver or device in question. The type of problem detected determines whether or not this information is displayed.

Under some conditions, the kernel displays only the first line of the Stop message. This can occur if vital services needed for the display have been affected by the error.

Recommended User Action

The recommended user action section gives suggestions for recovering from the error. In some cases, a simple restart may be all that is necessary because the problem is not likely to recur. In other cases, even after restarting, the Stop message returns and you are faced with getting back to an operable state. Often, this means either backing out of a recent change or, in the case of Windows 2000 setup, pinpointing and eliminating the source of the problem.

Tip

A generic list of troubleshooting tips is displayed when no specific text for a Stop message exists. For some Stop messages, tips specific to the problem are listed.

Debug Port Information

The debug port information section provides confirmation of the communications parameters (COM port and bits per second data transmission rate) used by the kernel debugger on the target computer, if the kernel debugger is enabled. It also indicates whether a memory dump file was saved (if that feature is enabled).

For more information about saving memory dump files to disk, see the chapter “Setting Up the Kernel Debugger” in this book.


Types of Stop Messages

Stop messages generally fall into one of four categories:

  • Messages that appear during general use of Windows 2000
  • Messages that appear during the installation of Windows 2000
  • Messages that appear only during Phase 4 of the Windows 2000 boot sequence, the relatively short Windows 2000 startup period
  • Messages that can be traced to a software condition, called a software trap, detected by the processor

General Stop Messages

The most common Stop messages are generated during daily operations. Even in a complex and robust operating system such as Windows 2000, catastrophic problems sometimes cause the system to stop responding and display a Stop message. In Windows 2000, a driver or file system can generate a system Stop message by introducing an unhandled error (exception) in the code or by performing some illegal operation.

For information about troubleshooting Stop messages, including detailed information about the most common errors, see the section “Troubleshooting Stop Messages” later in this chapter.

More Information

For the most comprehensive list of Stop messages in Windows 2000, along with useful information about diagnosing and troubleshooting these messages, refer to the Microsoft Knowledge Base article Q103059, titled “Descriptions of Bug Codes for Windows 2000.”

Note

You must be registered to use Microsoft Support Online and the Microsoft Knowledge Base. If you attempt to view a Knowledge Base article and are not registered or recognized by the system, you are directed to a registration page where you can register or retrieve your online profile.

Stop Messages During Installation

An unsuccessful attempt to install Windows 2000 can result in a Stop message. When this happens, first check that the computer and all of its peripheral hardware are compatible with Windows 2000. To do this, refer to the latest Windows 2000 Hardware Compatibility List (HCL), which Microsoft compiles through rigorous component and compatibility testing of computers and peripheral hardware to determine if they work well with Windows 2000. For more information about the HCL, see “Additional Resources” at the beginning of this chapter.

If the hardware you use is not included on the Windows 2000 HCL, contact the hardware manufacturer as a first-line resource for available information, newly tested hardware, and BIOS and firmware revisions. Reducing the number of hardware components by removing nonessential peripherals and devices can help you pinpoint installation conflicts as well.

Stop Messages That Occur Only at Executive Initialization

Some Stop messages occur only during the relatively short Windows 2000 startup period, Phase 4 of the Windows 2000 boot sequence. Initialization of the Windows 2000 Executive, a family of software components that provides basic operating system services, is one step during Phase 4. Executive initialization can be further broken down into two phases: Phase 0 and Phase 1. During Phase 0, interrupts are disabled and only a few Executive components, such as the Hardware Abstraction Layer (HAL), are initialized. During Phase 1 of Executive initialization, the system is fully operational, and the Windows 2000 subcomponents go through a full initialization.

Phase 0 Initialization Stop Messages

If you receive one of the Phase 0 initialization Stop messages listed in Table 25.1, run the hardware diagnostics provided by your system manufacturer.

Note

In many situations, hardware failures manifest themselves as errors that generate Stop messages. This is why troubleshooting many of the Stop messages includes running hardware diagnostics on the system.

If no hardware problems are found, reinstall Windows 2000 and try to initialize it again. If you get the same message, contact a technician.

Table 25.1 Phase 0 Initialization Stop Messages

Message ID | Symbolic Name
0x0031 | PHASE0_INITIALIZATION_FAILED
0x005C | HAL_INITIALIZATION_FAILED
0x005D | HEAP_INITIALIZATION_FAILED
0x005E | OBJECT_INITIALIZATION_FAILED
0x005F | SECURITY_INITIALIZATION_FAILED
0x0060 | PROCESS_INITIALIZATION_FAILED

Phase 1 Initialization Stop Messages

If you receive one of the Phase 1 initialization Stop messages listed in Table 25.2, reinstall Windows 2000 and try to initialize it again. If you get the same message, contact a technician.

Table 25.2 Phase 1 Initialization Stop Messages

Message ID | Symbolic Name
0x0032 | PHASE1_INITIALIZATION_FAILED
0x0061 | HAL1_INITIALIZATION_FAILED
0x0062 | OBJECT1_INITIALIZATION_FAILED
0x0063 | SECURITY1_INITIALIZATION_FAILED
0x0064 | SYMBOLIC_INITIALIZATION_FAILED
0x0065 | MEMORY1_INITIALIZATION_FAILED
0x0066 | CACHE_INITIALIZATION_FAILED
0x0067 | CONFIG_INITIALIZATION_FAILED
0x0068 | FILE_INITIALIZATION_FAILED
0x0069 | IO1_INITIALIZATION_FAILED
0x006A | LPC_INITIALIZATION_FAILED
0x006B | PROCESS1_INITIALIZATION_FAILED
0x006C | REFMON_INITIALIZATION_FAILED
0x006D | SESSION1_INITIALIZATION_FAILED
0x006E | SESSION2_INITIALIZATION_FAILED
0x006F | SESSION3_INITIALIZATION_FAILED
0x0070 | SESSION4_INITIALIZATION_FAILED
0x0071 | SESSION5_INITIALIZATION_FAILED

Stop Messages Caused by Software Traps

Software conditions detected by the processor, called software traps, can also generate Stop messages. A software trap occurs when a processor detects a problem with executing an instruction, which causes it to stop. For example, a processor does not carry out an instruction that contains invalid operands.

When you receive one of these messages, first write down the information displayed in the bugcheck information section of the Stop message, and then restart the computer. If the message recurs, you have four options for diagnosing the Stop condition, all of which should be handled by a trained technician at your own site:

  • Diagnose the problem by using the information and troubleshooting tips displayed in the Stop message. Additional information is found in the “Troubleshooting Stop Messages” section later in this chapter and in the Windows 2000 Error Messages HTML Help database file, where message explanations and recommended user actions for the most common Stop messages are listed. This file is located on the Microsoft® Windows® 2000 Resource Kit companion CD.

    For a regularly updated source of Windows 2000 error message explanations and recommended user actions, refer to the ResourceLink Web site. For more information about ResourceLink, see “Additional Resources” at the beginning of this chapter.

  • Contact your own or another technical support group to discuss the information in the Stop message. They might recognize a familiar pattern in the information and be able to offer assistance.

Important

If you use either of the following options, be sure Windows 2000 is in the debug mode before you restart your computer.

  • Set up the Windows 2000 kernel debugger to gather more information about the problem. For more information about setting up and configuring the kernel debugger, see the chapter “Setting Up the Kernel Debugger” in this book.
  • Contact your own or another technical support group for assistance in the remote use of the Windows 2000 kernel debugger.


Troubleshooting Stop Messages

Many problems can be resolved through troubleshooting procedures, such as verifying instructions, reinstalling key components, and verifying file dates. Also, diagnostic tools such as Winmsdp, Microsoft Network Monitor, Network General Sniffer, and Microsoft® Windows® 2000 Resource Kit tools, might help isolate and resolve these issues.


Generic Troubleshooting Procedures

For general troubleshooting of Windows 2000 Stop messages, follow these suggestions:

  • If new hardware has been added to the system recently, remove it or replace it to see if that resolves the error. Also, try running hardware diagnostics supplied by the system manufacturer. Check with the manufacturer to see if an updated system BIOS or firmware is available. Make sure that any expansion boards are properly seated and all cables are completely connected.
  • Confirm that any new hardware is listed on the Windows 2000 Hardware Compatibility List (HCL). For more information about the HCL, see “Additional Resources” at the beginning of this chapter.
  • If new device drivers or system services been added recently, remove them or update them to see if the problem is resolved. If you need to use Safe Mode to remove or disable components, restart your computer, press F8 to reach the Windows 2000 Advanced Options menu, and then choose Safe Mode.
  • Check the computer with an up-to-date virus scanner program that is compatible with Windows 2000. Viruses can infect both NTFS and FAT hard disks, and resulting disk corruption can generate system stops. Make sure the virus scanner checks the Master Boot Record for infections.
  • Verify that any recently added software is listed as compatible with Windows 2000. If it is not, check with the manufacturer to see if an update or a patch is available. Otherwise, remove the program to see if this resolves the error.
  • Verify that the system has the latest Service Pack installed. For information about downloading the latest Service Packs, see “Additional Resources” at the beginning of this chapter.
  • Disable BIOS memory options such as caching or shadowing.
  • Check the System Log and Application Log in Event Viewer to see if any additional error messages have been logged recently. These might pinpoint the cause of the error.
  • Check the Microsoft Knowledge Base using the keywords winnt and 0x0000001E. For information about the Microsoft Knowledge Base, see “Additional Resources” at the beginning of this chapter.

Kernel debugging is especially helpful when other troubleshooting techniques have failed, or when a problem repeats often. In these cases, it is possible to pinpoint the failing code in a driver or an application by using a kernel debugger. For kernel debugging, it is important to capture the exact text of the error message. Also, in order to isolate a complex problem and develop a viable workaround or a program replacement, it is essential to record the exact steps leading to the failure. For information about preparing your computer for kernel debugging, see the chapter “Setting Up the Kernel Debugger” in this book.


Troubleshooting Common Stop Messages

For the most commonly encountered Stop messages, troubleshooting tips and recommendations have been gathered together to help you resolve the problem on your own. If the error persists after you have tried all of the recommendations listed both here and within the Stop message display, contact your technical support group for further assistance.

Stop 0x0000000A or IRQL_NOT_LESS_OR_EQUAL

This Stop message, also known as Stop 0xA, indicates that a kernel-mode process attempted to access a portion of memory at an IRQL (Interrupt Request Level) that was too high. A kernel-mode process can access only other processes that have an IRQL lesser than or equal to its own.

Interpreting the Message

The four parameters listed in the Stop 0xA message are defined in order of appearance as follows :

  1. Memory address referenced
  2. IRQL
  3. Type of access (0 = read operation, 1 = write operation)
  4. Address that referenced memory in parameter 1

If the third parameter is the same as the first parameter, a special condition exists in which a work routine returned at a raised IRQL. In that case, the parameters are defined as follows:

  1. Address of the work routine
  2. IRQL
  3. Address of the work routine
  4. Address that referenced memory

Resolving the Problem

Buggy device driver, system service or BIOS. The error that generates Stop 0xA usually occurs after the installation of a buggy device driver, system service, or BIOS. To resolve it quickly, try restarting and, when prompted, press the SPACEBAR to invoke the Last Known Good option. Press L on the Hardware Profile/Configuration Recovery Menu to revert to the last successfully started system configuration. This option is most effective when only one driver or service is added at a time.

Incompatible device driver, system service, virus scanner or backup utility. If you encounter Stop 0xA while upgrading to a newer version of Windows, it might be caused by a device driver, a system service, a virus scanner, or a backup utility that are incompatible with the new version. If possible, remove all third party device drivers and system services and disable any virus scanners prior to upgrading. Contact the software manufacturer to obtain updates of these utilities.

For additional error messages that might help pinpoint the device or driver that is causing the error, check the System Log in Event Viewer. Disabling memory caching of the BIOS might also resolve this error. You should also run hardware diagnostics supplied by the system manufacturer, especially the memory scanner. For details on these procedures, see the owner’s manual for your computer.

If your system has SCSI adapters, contact the adapter manufacturer to obtain updated Windows 2000 drivers. Try disabling sync negotiation in the SCSI BIOS, checking the cabling and the SCSI IDs of each device, and confirming proper termination. For IDE devices, define the onboard IDE port as Primary only. Also, check each IDE device for the proper master/slave/stand-alone setting. Try removing all IDE devices except for hard disks.

If the message appears during an installation of Windows 2000, make sure that the computer and all installed peripherals are listed on the Microsoft Windows 2000 Hardware Compatibility List (HCL). For more information about the HCL, see “Additional Resources” at the beginning of this chapter.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed. For information about installing the latest Service Pack, see “Additional Resources” at the beginning of this chapter.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For information about downloading hotfixes and Service Packs, see “Additional Resources” at the beginning of this chapter.

More Information

For more troubleshooting information about the 0xA Stop message, refer to Microsoft Knowledge Base article “Troubleshooting ‘Stop 0x0A’ Messages in Windows 2000” at http://support.microsoft.com/support/kb/articles/q165/8/63.asp. To check for other articles specific to the 0xA error, refer to the Microsoft Knowledge Base at http://support.microsoft.com/support/ using the keywords winnt and 0x0000000A.

Note

You must be registered to use Microsoft Support Online and the Microsoft Knowledge Base. If you attempt to view a Knowledge Base article and are not registered or recognized by the system, you are directed to a registration page where you can register or retrieve your online profile.

Stop 0x0000001E or KMODE_EXCEPTION_NOT_HANDLED

This Stop message, also known as Stop 0x1E, indicates that a kernel-mode process tried to execute an illegal or unknown processor instruction. This error handler is a default error handler that catches errors not associated with other specific error handlers.

Interpreting the Message

The four parameters listed in the message are defined as follows (in order of appearance):

  1. Exception code that was not handled
  2. Address at which the exception occurred
  3. Parameter 0 of the exception
  4. Parameter 1 of the exception

The first parameter is a Windows 2000 error code, which is defined by the type of error encountered in the file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK). For information about the DDK, see “Additional Resources” at the beginning of this chapter. The second parameter identifies the address of the module in which the error occurred. Frequently, the address points to an individual driver or piece of faulty hardware, which is generally listed on the third line of the Stop message. Always make a note of this address, as well as the link date of the driver or image that contains it. The last two parameters vary, depending upon the exception that has occurred. You can typically find a description of the parameters that are included with the name of error code in Ntstatus.h. If the error code has no parameters, the last two parameters are listed as 0x00000000.

Resolving the Problem

Hardware incompatibility. First, make sure that any new hardware installed is listed on the Microsoft Windows 2000 Hardware Compatibility List (HCL). For more information about the HCL, see “Additional Resources” at the beginning of this chapter.

Buggy device driver or system service. In addition, a buggy device driver or system service might be responsible for this error. Hardware issues, such as BIOS incompatibilities, memory conflicts, and IRQ conflicts can also generate this error.

Disable or remove the driver or device identified by its address in parameter 2 (the driver in question might also be listed by name within the Stop message). Disable or remove any drivers or services that were recently added. If the error occurs during the startup sequence and the system partition is formatted with NTFS, you might be able to use Safe Mode to rename or delete the faulty driver. If the driver is used as part of the system startup process in Safe Mode, you need to start the computer by using the Command Console to access the file. For more information about Safe Mode and the Command Console, see the chapter “System Recovery” in this book.

If the problem is associated with Win32k.sys, the source of the error might be a third party remote control program. If such software is installed, the service can be removed by starting the system in a parallel installation of Windows 2000 and deleting the offending system service file.

Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing Stop 0x1E. Disabling memory caching of the BIOS might also resolve the error. You should also run hardware diagnostics, especially the memory scanner, supplied by the system manufacturer. For details on these procedures, see the owner’s manual for your computer.

One type of this error displays exception code 0x80000003. This error means a hard-coded breakpoint or assertion was hit, but the system was started with the /NODEBUG switch. This problem should rarely occur. If it occurs repeatedly, make sure a kernel debugger is connected and the system is started with the /DEBUG switch. For information about the kernel debugger, see the chapter “Setting Up the Kernel Debugger” in this book.

The error that generates this message can occur after the first restart during Windows 2000 Setup, or after Setup is finished. A possible cause of the error is lack of disk space for installation and system BIOS incompatibilities. For problems during Windows 2000 installation that are associated with lack of disk space, reduce the number of files on the target hard disk. Check for and delete any unneeded temporary files, Internet cache files, application backup files, and CHK files containing saved file fragments from disk scans. You can also use another hard disk with more free space for the installation. BIOS problems can be resolved by upgrading the system BIOS version.

On non-x86 systems, if the address of the exception is 0XBFC0304, this stop is the result of a cache-parity error on the CPU. If the error recurs frequently, contact the hardware manufacturer.

More Information

For more troubleshooting information about the 0x1E Stop message, refer to the Microsoft Knowledge Base at http://support.microsoft.com/support/ using the keywords winnt and 0x0000001E.

Note

You must be registered to use Microsoft Support Online and the Microsoft Knowledge Base. If you attempt to view a Knowledge Base article and are not registered or recognized by the system, you are directed to a registration page where you can register or retrieve your online profile.

Stop 0x00000024 or NTFS_FILE_SYSTEM

This Stop message, also known as Stop 0x24, indicates a problem occurred within Ntfs.sys (the driver file that allows the system to read and write to NTFS drives).

Interpreting the Message

The four parameters listed in the message are defined in order of appearance as follows:

  1. Source file and line number
  2. Optionally contains the address of the exception record
  3. Optionally contains the address of the context record
  4. Optionally contains the address where the original exception occurred

All stops due to problems with NTFS or FAT have encoded in their first parameter the source file and the line number within the source file that generated the stop. The high 16 bits (the first four hex digits after the 0x) identify the source file number, while the lower 16 bits (the last four hex digits of the parameter) identify the source line in the file where the stop occurred.

Resolving the Problem

Disk Corruption. Corruption in the NTFS file system or bad blocks on the hard disk can induce this error. Corrupted SCSI and IDE drivers can also adversely affect the system’s ability to read and write to disk, thus causing the error.

Check Event Viewer for error messages from SCSI and FASTFAT (System Log) or Autochk (Application Log) that might help pinpoint the device or driver that is causing the error. Try disabling any virus scanners, backup programs, or disk defragmenter tools that constantly monitor the system. You should also run hardware diagnostics supplied by the system manufacturer. For details on these procedures, see the owner’s manual for your computer. Run Chkdsk /f /r to detect and resolve any file system structural corruption.

Depletion of nanpaged pool memory. If you create a Services for Macintosh (SFM) volume on a large partition (7 gigabytes or larger) with a large number of files (at least 100,000) while the AppleTalk driver Apf.sys is loaded, the indexing routine consumes a large amount of nonpaged pool memory. If the nonpaged pool memory is completely depleted, this error can stop the system. However, during the indexing process, if the amount of available nonpaged pool memory is very low, another kernel-mode driver requiring nonpaged pool memory can also trigger this error. To resolve this error, either increase the amount of installed RAM, which increases the quantity of nonpaged pool memory available to the kernel, or reduce the number of files on the SFM volume.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

More Information

For more troubleshooting information about the 0x24 Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x24 Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x00000024, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x0000002E or DATA_BUS_ERROR

This message, also known as Stop 0x2E, typically indicates that a parity error in system memory has been detected. This error is almost always caused by a hardware problem—either a configuration issue, defective hardware or incompatible hardware. The exception is when a device driver has accessed an address in the 0x8xxxxxxx range that does not exist (does not have a physical address mapping).

Interpreting the Message

The four parameters listed in the message are defined in order of appearance as follows:

  1. Virtual address that caused the fault
  2. Physical address that caused the fault
  3. Processor status register (PSR)
  4. Faulting instruction register (FIR)

Resolving the Problem

Hardware problem. The most common cause of this error is a hardware problem, usually related to defective RAM, L2 RAM cache, or video RAM.

Stop 0x2E usually occurs after the installation of faulty hardware or when existing hardware fails. If hardware has recently been added to the system, remove it to see if the error recurs. If existing hardware has failed, remove or replace the faulty component. You should run hardware diagnostics supplied by the system manufacturer to determine which hardware component has failed. For details on these procedures, see the owner’s manual for your computer. Check that all adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure that adapter card contacts are clean.

If the problem occurs on a newly installed system, check the availability of updates for the following items: firmware on RISC systems, BIOS revisions on the motherboard, the SCSI controller or network cards. Updates of this kind, or at least the announcement of such, are typically available on the Web site or BBS of the hardware manufacturer.

If the error occurs after installing a new or updated device driver, the driver should be removed or replaced. If, under this circumstance, the error occurs during startup and the system partition is formatted with NTFS, you might be able to use Safe Mode to rename or delete the faulty driver. If the driver is used as part of the system startup process in Safe Mode, you need to start the computer using the Command Console in order to access the file. For more information about Safe Mode and the Command Console, see the chapter “System Recovery” in this book.

For additional error messages that might help pinpoint the device or driver that is causing the error, check the System Log in Event Viewer. Disabling memory caching of the BIOS might also resolve this error. In addition, check the system for viruses, using any up-to-date, commercial virus scanning software that examines the Master Boot Record (MBR) of the hard disk. Both FAT and NTFS file systems can be infected by viruses.

Hard disk corruption. This error can also be a result of hard disk corruption. If the system is formatted with the NTFS file system, run Chkdsk /f /r on the system partition. You must restart the system before the disk scan begins. If you cannot start the system due to the error, use the Command Console and run Chkdsk /r. For more information about the Command Console, see the chapter “System Recovery” in this book.

Warning

If your system partition is formatted with the FAT file system, the long filenames used by Windows 2000 can be damaged if Scandisk or another MS-DOS-based hard disk tool is used to verify the integrity of your hard disk from an MS-DOS prompt. (An MS-DOS prompt is typically derived from a MS-DOS startup disk or from starting MS-DOS on a multiboot system.)

If you have the wrong revision of the CPU module on a DEC Alpha computer, you might also encounter this error, which has been observed on an Alpha XL 266 using a revision of B02 or earlier. To resolve the error, update your system to a CPU module with a higher revision than B02.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

Finally, if all the above suggestions fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can also cause this error.

More Information

For more troubleshooting information about the 0x2E Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x0000002e, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x00000050 or PAGE_FAULT_IN_NONPAGED_AREA

This Stop message, also known as Stop 0x50, occurs when requested data is not found in memory. The system generates a fault, which normally indicates that the system looks for data in the paging file. In this circumstance, however, the missing data is identified as being located within a nonpageable area of memory, meaning the data cannot be swapped out to disk. The system faults, but cannot find, the data and is unable to recover. Faulty hardware, a buggy system service, antivirus software, and a corrupted NTFS volume can all generate this type of error.

Interpreting the Message

The four parameters listed in the message are defined in order of appearance as follows:

  1. Virtual address which caused the fault
  2. Type of access (0 = read operation, 1 = write operation)
  3. (zero)
  4. Opaque information about the stop, interpreted by the kernel

Resolving the Problem

Faulty hardware. Stop 0x50 usually occurs after the installation of faulty hardware or in the event of failure of installed hardware (usually related to defective RAM, be it main memory, L2 RAM cache, or video RAM). If hardware has been added to the system recently, remove it to see if the error recurs. If existing hardware has failed, remove or replace the faulty component. You should run hardware diagnostics supplied by the system manufacturer. For details on these procedures, see the owner’s manual for your computer.

Buggy system service. Often, the installation of a buggy system service is a culprit. Disable the service and confirm that this resolves the error. If so, contact the manufacturer of the system service about a possible update. If the error occurs during system startup, try restarting and, when prompted, press the SPACEBAR to invoke the Last Known Good option. Press L on the Hardware Profile/Configuration Recovery Menu to revert to the last successfully started system configuration. This option is most effective when only one driver is added at a time.

Antivirus software. Antivirus software can also trigger this error. Disable the program and confirm that this resolves the error. If it does, contact the manufacturer of the program about a possible update.

Corrupted NTFS volume. A corrupted NTFS volume can also generate this error. Run Chkdsk /f /r to detect and repair disk errors. If the hard disk is SCSI, check for problems between the SCSI controller and the disk.

Finally, check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. Disabling memory caching of the BIOS might also resolve it.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

More Information

For more troubleshooting information about the 0x50 Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x00000050, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x00000077 or KERNEL_STACK_INPAGE_ERROR

This Stop message, also known as Stop 0x77, indicates that the requested page of kernel data from the paging file could not be read into memory.

Interpreting the Message

The four parameters listed in the message are defined in order of appearance as follows:

  1. (zero)
  2. PTE (Page Table Entry) value at time of error
  3. (zero)
  4. Address of signature on kernel stack

These definitions apply only if the first and third parameters are both zero. Otherwise, the following definitions are applicable:

  1. Status code
  2. I/O status code
  3. Page file number
  4. Offset into page file

Frequently, the cause of this error can be determined from the second parameter, the I/O status code. Examples include:

  • 0xC000009A, or STATUS_INSUFFICIENT_RESOURCES, is caused by lack of nonpaged pool resources.
  • 0xC000009C, or STATUS_DEVICE_DATA_ERROR, is generally due to bad blocks on the hard disk.
  • 0xC000009D, or STATUS_DEVICE_NOT_CONNECTED, indicates defective or loose cabling, termination, or the controller not seeing the hard disk.
  • 0xC000016A, or STATUS_DISK_OPERATION_FAILED, is also caused by bad blocks on the hard disk.
  • 0xC0000185, or STATUS_IO_DEVICE_ERROR, is caused by improper termination or defective cabling on SCSI devices, or two devices attempting to use the same IRQ.

These codes are the most common ones for which specific causes have been determined. For information about other possible status codes that can be returned, see the file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK). For information about the DDK, see “Additional Resources” at the beginning of this chapter.

Resolving the Problem

Bad block. Stop 0x77 is caused by a bad block in a paging file or a disk controller error. In extremely rare cases, it is caused when nonpaged pool resources run out.

If the first and third arguments are zero, the stack signature in the kernel stack was not found. This error is caused by defective hardware. If the I/O status is C0000185 and the paging file is on a SCSI disk, the disk cabling and SCSI termination should be checked for problems.

Viruses. In addition, check your computer for viruses, using any up-to-date, commercial virus scanning software that examines the Master Boot Record (MBR) of the hard disk. Both FAT and NTFS file systems can be infected by viruses.

An I/O status code of 0xC000009C or 0xC000016A normally indicates that the data could not be read from the disk due to a bad block. If you can restart the system after the error, Autochk runs automatically and attempts to map out the bad sector. If for some reason Autochk does not scan the hard disk for errors, you can manually launch the disk scanner. If the system is formatted with the NTFS file system, run Chkdsk /f /r on the system partition. You must restart the system before the disk scan begins. If you cannot start the system due to the error, use the Command Console and run Chkdsk /r. For more information about the Command Console, see the chapter “System Recovery” in this book.

Warning

If your system partition is formatted with the FAT file system, the long filenames used by Windows 2000 can be damaged if Scandisk or another MS-DOS-based hard disk tool is used to verify the integrity of your hard disk from an MS-DOS prompt. (An MS-DOS prompt is typically derived from a MS-DOS startup disk or from starting MS-DOS on a multiboot system.)

Failing RAM. Another common cause of this error message is failing RAM. You should run hardware diagnostics supplied by the system manufacturer, especially the memory scanner. For details on these procedures, see the owner’s manual for your computer. Also, check that all the adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure adapter card contacts are clean.

In addition, check the System Log in Event Viewer for additional error messages that might help pinpoint the device that is causing the error. Disabling memory caching of the BIOS might also resolve this error.

Finally, if all the above steps fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can also cause this error.

More Information

For more troubleshooting information about the 0x77 Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x77 Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x00000077, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x00000079 or MISMATCHED_HAL

This message, also known as Stop 0x79, is displayed when the Hardware Abstraction Layer (HAL) and the kernel or the machine type do not match. This error most often occurs when single-processor and multiprocessor configuration files are mixed on the same system.

Interpreting the Message

The types of mismatch parameters are defined in order of appearance in the sets as follows. The first parameter determines which set is applicable.

  1. If this parameter is 1, the PRCB (pointer to processor control block) release levels mismatch (something is out of date).
  2. Major PRCB level of Ntoskrnl.exe.
  3. Major PRCB level of Hal.dll.

Or:

  1. If this parameter is 2, the build types mismatch.
  2. Build type of Ntoskrnl.exe.
  3. Build type of Hal.dll (Build Types: 0, free multiprocessor-enabled build; 1, checked multiprocessor-enabled build; and 2, free single-processor build).

Or:

  1. If this parameter is 3, Micro Channel Architecture (MCA) computers require a MCA-specific HAL.
  2. Machine type as detected by Ntdetect.com. A value of a 2 means that the computer is MCA.
  3. Machine type that HAL supports. A value of a 2 means the HAL is built for MCA.

Resolving the Problem

Stop 0x79 can occur if either the Ntoskrnl.exe or Hal.dll files have been manually updated. The error can also indicate that one of those two files is out of date (that is, the HAL is designed for Windows NT 4.0 and the kernel is for Windows 2000). Additionally, the machine might erroneously have a multiprocessor HAL and a single-processor kernel installed, or vice versa.

The kernel file Ntoskrnl.exe is for single-processor systems and Ntkrnlmp.exe is for multiprocessor systems. However, these filenames correspond to the file on the installation media; after Windows 2000 has been installed, the file is renamed to Ntoskrnl.exe, regardless of the source file used. The HAL file also uses the name Hal.dll after installation, but there are several possible HAL files on the installation media.

To resolve this error, use the Command Console to replace the incorrect system files on your computer. For more information about the Command Console, see the chapter “System Recovery” in this book.

More Information

For more troubleshooting information about the 0x79 Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x00000079, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter

Stop 0x0000007A or KERNEL_DATA_INPAGE_ERROR

This Stop message, also known as Stop 0x7A, indicates that the requested page of kernel data from the paging file could not be read into memory.

Interpreting the Message

The four parameters listed in the message are defined as follows (in order of appearance):

  1. Lock type that was held (value 1, 2, 3, or PTE [Page Table Entry] address)
  2. Error status (normally I/O status code)
  3. Current process (virtual address for lock type 3, or PTE)
  4. Virtual address that could not be paged into memory

For information about all possible status codes that might be returned, see the file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK). For information about the DDK, see “Additional Resources” at the beginning of this chapter.

Resolving the Problem

Stop 0x7A is usually caused by a bad block in a paging file, a virus, a disk controller error, or failing RAM. In rare cases, it is caused when nonpaged pool resources run out. It is also caused by defective hardware.

SCSI problems. If the I/O status is C0000185 and the paging file is on a SCSI disk, the disk cabling and SCSI termination should be checked for problems.

Viruses. In addition, check your computer for viruses, using any up-to-date, commercial virus scanning software that examines the Master Boot Record (MBR) of the hard disk. Both FAT and NTFS file systems can be infected by viruses.

Bad block. An I/O status code of 0xC000009C or 0xC000016A normally indicates the data cannot be read from the disk due to a bad block. If you can restart the system after the error, Autochk runs automatically and attempts to map out the bad sector. If for some reason Autochk does not scan the hard disk for errors, you can manually launch the disk scanner. If the system is formatted with the NTFS file system, run Chkdsk /f /r on the system partition. You must restart the system before the disk scan begins. If you cannot start the system due to the error, use the Command Console and run Chkdsk /r. For more information about the Command Console, see the chapter “System Recovery” in this book.

Warning

If your system partition is formatted with the FAT file system, the long filenames used by Windows 2000 can be damaged if Scandisk or another MS-DOS-based hard disk tool is used to verify the integrity of your hard disk from an MS-DOS prompt. (An MS-DOS prompt is typically derived from a MS-DOS startup disk or from starting MS-DOS on a multiboot system.)

Failing RAM. Another common cause of this error message is failing RAM. You should run hardware diagnostics supplied by the system manufacturer, especially the memory scanner. For details on these procedures, see the owner’s manual for your computer. Also, check that all adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure adapter card contacts are clean.

Check the System Log in Event Viewer for additional error messages that might help pinpoint the device that is causing the error. Disabling memory caching of the BIOS might also resolve it.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter.

Finally, if all the above steps fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can also cause this error.

More Information

For more troubleshooting information about the 0x7A Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x7A Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x0000007A, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x0000007B or INACCESSIBLE_BOOT_DEVICE

This Stop message, also known as Stop 0x7B, indicates that Windows 2000 lost access to the boot disk during the startup process. This error always occurs while the system is starting and cannot be debugged because it generally occurs before the operating system has loaded the debugger.

Interpreting the Message

The four parameters listed in the message are defined (in order of appearance) as follows:

  1. Address of a Unicode string data structure representing the ARC (Advanced RISC Computing) specification name of the device from which the startup was being attempted
  2. Status code
  3. (zero)
  4. (zero)

The first parameter contains something like 00800020, where 20 is the actual length of the Unicode string, and the next long word contains the address of the buffer. This address is in system space, so the high-order bit is set.

If the file system that is supposed to read the boot device failed to initialize or simply did not recognize the data on the boot device as a file system structure, the following parameter definition applies.

For information about all possible status codes that might be returned, see the file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK). For information about the DDK, see “Additional Resources” at the beginning of this chapter.

  1. Address of the device object that could not be mounted
  2. (zero)
  3. (zero)
  4. (zero)

This makes it obvious whether the argument is a pointer to an ARC name string (ARC names are a generic method of identifying devices within the ARC environment) or a device object, because a Unicode string never has an odd number of bytes, and a device object always has a Type code of 0003.

Resolving the Problem

Failed boot device. During I/O system initialization, the boot device driver might have failed to initialize the boot device (typically a hard disk). File system initialization might have failed because it did not recognize the data on the boot device.

Also, repartitioning the system partition or installing a new SCSI adapter or disk controller might induce this error. If this happens on x86 systems, the Boot.ini file must be edited; on Alpha systems, Setup must be run. For additional information about the Boot.ini file, see “Additional Resources” at the beginning of this chapter for instructions on how to access the Microsoft Knowledge Base and the article “BOOT.INI and ARC Path Naming Conventions and Usage” at http://support.microsoft.com/support/kb/articles/q102/8/73.asp.

Incompatible disk hardware. If the error occurred at the initial setup of the system, the system might have been installed on an unsupported disk or SCSI controller. Some controllers are supported only by drivers that are in the Windows Driver Library (WDL), which requires the user to do a custom installation. If Setup autodetected the controller, you might need to skip detection and use a specific manufacturer’s diskette to load the driver. Also, check the availability of updates for the system BIOS and SCSI controller firmware. Updates of this kind, or at least the announcement of such, should be available on the Web site or BBS of the hardware manufacturer.

Remove any recently added hardware, especially hard disks or controllers, to see if the error is resolved. If the offending piece of hardware was a hard disk, the disk firmware version might be incompatible with Windows 2000. Contact the manufacturer for updates. If the removal of another piece of hardware alleviated the error, IRQ or I/O port conflicts likely exist. Reconfigure the new device according to the manufacturer’s instructions.

Confirm that all hard disks, hard disk controllers, and SCSI adapters are listed on the Microsoft Windows 2000 Hardware Compatibility List (HCL). For more information about the HCL, see “Additional Resources” at the beginning of this chapter.

If a driver was recently added, try restarting and, when prompted, press the SPACEBAR to invoke the Last Known Good option. Press L on the Hardware Profile/Configuration Recovery Menu to revert to the last successfully started system configuration. This option is most effective when only one driver is added at a time.

In addition, check your computer for viruses, using any up-to-date, commercial virus scanning software that examines the Master Boot Record (MBR) of the hard disk. Both FAT and NTFS file systems can be infected by viruses.

This error can also be a result of hard disk corruption. If the system is formatted with the NTFS file system, run Chkdsk /f /r on the system partition. You must restart the system before the disk scan begins. If you cannot start the system due to the error, use the Command Console and run Chkdsk /r. For more information about the Command Console, see the chapter “System Recovery” in this book.

Warning

If your system partition is formatted with the FAT file system, the long filenames used by Windows 2000 can be damaged if Scandisk or another MS-DOS-based hard disk tool is used to verify the integrity of your hard disk from an MS-DOS prompt. (An MS-DOS prompt is typically derived from a MS-DOS startup disk or from starting MS-DOS on a multiboot system.)

If your system has SCSI adapters, contact the adapter manufacturer to obtain updated Windows 2000 drivers. Try disabling sync negotiation in the SCSI BIOS, checking the cabling and the SCSI IDs of each device, and confirming proper termination. For IDE devices, define the onboard IDE port as Primary only. Also check each IDE device for the proper master/slave/stand alone setting. Try removing all IDE devices except for hard disks. Finally, check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

Note

In order to install the latest Service Pack, you might need to install a second, parallel copy of Windows 2000, and then install the latest Service Pack to the new installation, and finally copy updated files to the original installation folders. For information about Service Packs, see “Additional Resources” at the beginning of this chapter.

More Information

For more troubleshooting information about the 0x7B Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x7B Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x0000007B, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0x0000007F or UNEXPECTED_KERNEL_MODE_TRAP

This Stop message, also known as Stop 0x7F, means that one of two types of problems occurred in kernel mode, either a kind of condition that the kernel is not allowed to have or catch (a bound trap), or a kind of error that is always fatal. Occasionally, this message can be caused by software problems, but the most common cause is hardware failure.

Interpreting the Message

The four parameters listed in the message are defined in order of appearance as follows:

  1. Processor exception code
  2. (zero)
  3. (zero)
  4. (zero)

The first and most important parameter (0x0000000x) can have several different values. The cause of this error can vary, depending on the value of this parameter. All conditions that cause a Stop 0x7F can be found in any Intel x86 microprocessor reference manual because they are specific to the x86 platform. Here are some of the most common ones:

  • 0x00000000, or Divide by Zero Error, is caused when a DIV instruction is executed and the divisor is 0. Memory corruption, other hardware problems, or software failures can cause this error.
  • 0x00000004, or Overflow, occurs when the processor executes a call to an interrupt handler when the overflow (OF) flag is set.
  • 0x00000005, or Bounds Check Fault, is generated when the processor, while executing a BOUND instruction, finds the operand exceeds the specified limits. A BOUND instruction is used to ensure that a signed array index is within a certain range.
  • 0x00000006, or Invalid Opcode, is generated when the processor attempts to execute an invalid instruction. This is generally caused when the instruction pointer has become corrupted and is pointing to the wrong location. The most common cause of this is hardware memory corruption.
  • 0x00000008, or Double Fault, is when an exception occurs while trying to call the handler for a prior exception. Normally, the two exceptions can be handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. This is almost always caused by hardware problems.

Other exception codes are defined as follows:

  • 0x00000001—A system-debugger call
  • 0x00000003—A debugger breakpoint
  • 0x00000007—A hardware coprocessor instruction with no coprocessor present
  • 0x0000000A—A corrupted Task State Segment
  • 0x0000000B—An access to a memory segment that was not present
  • 0x0000000C—An access to memory beyond the limits of a stack
  • 0x0000000D—An exception not covered by some other exception; a protection fault that pertains to access violations for applications

Resolving the Problem

Hardware failure or incompatibility. Stop 0x7F usually occurs after the installation of faulty or mismatched hardware (especially memory) or in the event that installed hardware fails. If hardware was recently added to the system, remove it to see if the error recurs. If existing hardware has failed, remove or replace the faulty component. Run hardware diagnostics supplied by the system manufacturer, especially the memory scanner, to determine which hardware component has failed. For details on these procedures, see the owner’s manual for your computer. Check that all adapter cards in the computer are properly seated. Use an ink eraser or an electrical contact treatment, available at electronics supply stores, to ensure adapter card contacts are clean.

If the error appears on a newly installed system, check the availability of updates for the following items: firmware on RISC systems and BIOS revisions on the motherboard, the SCSI controller or network cards. Updates of this kind, or at least the announcement of such, should be available on the Web site or BBS of the hardware manufacturer.

Confirm that all hard disks, hard disk controllers, and SCSI adapters are listed on the Microsoft Windows 2000 Hardware Compatibility List (HCL). For more information about the HCL, see “Additional Resources” at the beginning of this chapter.

If the error occurred after the installation of a new or updated device driver, the driver should be removed or replaced. If, under this circumstance, the error occurs during the startup sequence and the system partition is formatted with NTFS, you might be able to use Safe Mode to rename or delete the faulty driver. If the driver is used as part of the system startup process in Safe Mode, you need to start the computer using the Command Console in order to access the file. For more information about Safe Mode and the Command Console, see the chapter “System Recovery” in this book. Also try restarting and, when prompted, press the SPACEBAR to invoke the Last Known Good option. Press L on the Hardware Profile/Configuration Recovery Menu to revert to the last successfully started system configuration. This option is most effective when only one driver is added at a time.

Overclocking. Setting the CPU to run at speeds above the rated specification (also known as overclocking the CPU) can cause this error. If this has been done to the computer experiencing the error, return the CPU to the default clock speed setting.

Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. Disabling memory caching of the BIOS might also resolve it.

If you encountered this error while upgrading to Windows 2000, it might be caused by device drivers, system services, virus scanners, or backup utilities that are incompatible with the new version. If possible, remove all third party device drivers and system services and disable any virus scanners prior to upgrading. Contact the software manufacturer to obtain updates of these utilities.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

Finally, if all the above steps fail to resolve the error, take the system motherboard to a repair facility for diagnostic testing. A crack, a scratched trace, or a defective component on the motherboard can also cause this error.

More Information

For more troubleshooting information about the 0x7F Stop message, refer to the ResourceLink Web site or the Microsoft Knowledge Base, including the Microsoft Knowledge Base article “General Causes of STOP 0x0000007F Errors” at http://support.microsoft.com/support/kb/articles/q137/5/39.asp. To check for other articles specific to the 0x7F error, refer to the Microsoft Knowledge Base at http://support.microsoft.com/support/ using the keywords winnt and 0x0000007F. For information about the ResourceLink Web site or the Microsoft Knowledge Base, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x7F Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0x0000007F, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0xC000021A or STATUS_SYSTEM_PROCESS_TERMINATED

This Stop message, also known as Stop 0xC21A, occurs when a user mode subsystem, such as Winlogon or the Client Server Runtime Subsystem (CSRSS), is fatally compromised and security can no longer be guaranteed. The operating system switches into kernel mode and generates this error. Because Windows 2000 cannot run without Winlogon or CSRSS, this is one of the few situations where the failure of a user mode service can bring down the system. Running the kernel debugger is not useful in this situation because the actual error occurred in a user mode process.

Interpreting the Message

The first three parameters listed in the message are defined (in order of appearance) as follows:

  1. Status code
  2. (zero)
  3. (zero)

For information about all possible status codes that might be returned, see the file Ntstatus.h of the Windows 2000 Device Driver Kit (DDK). For information about the DDK, see “Additional Resources” at the beginning of this chapter.

Resolving the Problem

Device drivers, system services, and third party applications. Because Stop 0xC21A occurs in a user mode process, the most common culprits are third party applications. If the error occurred after the installation of a new or updated device driver, system service or third party application, the new software should be removed or disabled. Contact the manufacturer of the software about a possible update.

If the error occurs during system startup, try restarting and, when prompted, press the SPACEBAR to invoke the Last Known Good option. Press L on the Hardware Profile/Configuration Recovery Menu to revert to the last successfully started system configuration. This option is most effective when only one change is made at a time. If this does not resolve the error and the system partition is formatted with NTFS, you might be able to use Safe Mode to rename or delete the faulty software. If the faulty software is used as part of the system startup process in Safe Mode, you need to start the computer using the Command Console in order to access the file. For more information about Safe Mode and the Command Console, see the chapter “System Recovery” in this book. If a newly installed piece if hardware is suspected, remove it to see if this resolves the issue.

Try running the Automated System Recovery (ASR) disk and allow the system to repair any errors that it detects. For more information about the ASR disk, see the chapter “System Recovery” in this book.

Mismatched system files. Mismatched system files can also cause this error. Running a full system restore from tape might generate this error (some restore programs might skip restoring system files they determine are in use). Check if there is an updated version of the Backup/Restore program available from the manufacturer.

Microsoft periodically releases a package of product improvements and problem resolutions for Windows 2000 called a Service Pack. Because many problems are resolved by installing the latest Service Pack, it is recommended that all users install them as they become available. To check which Service Pack, if any, is installed on your system, click Start, point to Run, type winver, and then press ENTER. The About Windows 2000 dialog box displays the Windows version number and the version number of the Service Pack, if one has been installed.

Occasionally, remedies to specific problems are developed after the release of a Service Pack. These remedies are called hotfixes. Microsoft does not recommend that you install a post-Service Pack hotfix unless the specific problem it addresses has been encountered. Service Packs include all of the hotfixes released since the release of the previous Service Pack. The status of hotfix installations is not indicated in the About Windows 2000 dialog box. For more information about Service Packs and hotfixes, see “Additional Resources” at the beginning of this chapter

More Information

For more troubleshooting information about the 0xC21A Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x21A Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0xC000021A, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

Stop 0xC0000221 or STATUS_IMAGE_CHECKSUM_MISMATCH

This Stop message, also known as Stop 0xC221, indicates that a driver or a system DLL has been corrupted. Typically, the name of the damaged file is displayed as part of the message.

To remedy this error, run the Automated System Recovery (ASR) disk and allow the system to repair or replace the missing or damaged driver file on the NTFS partition. For more information about the ASR disk, see the chapter “System Recovery” in this book.

You can also run an in-place upgrade over the top of the existing copy of Windows 2000. This preserves all registry settings and configuration information, but replaces all system files. If any Service Packs and/or hotfixes had previously been applied, you need to reinstall them afterward in the appropriate order (latest Service Pack, then any post Service Pack hotfixes, if applicable). If a specific file was identified in the Stop message as being corrupted, you can try replacing that individual file manually. If the system partition is FAT, start from an MS-DOS floppy and copy the file from the original source onto the hard disk. If the partition is NTFS, you need to restart the system, press F8 at the OS Loader menu, and choose Safe Mode with Command Prompt. From there, copy a fresh version of the file from the original source onto the hard disk. If the file is used as part of the system startup process in Safe Mode, you need to start the computer using the Command Console in order to access the file. For more information about Safe Mode and the Command Console, see the chapter “System Recovery” in this book.If these methods fail, try reinstalling Windows 2000 and then restoring the system from a backup.

Disk errors can be a source of file corruption. Run Chkdsk /f /r to detect and resolve any file system structural corruption.

If the error occurred immediately after RAM was added to the system, the paging file might be corrupted or the new RAM itself might be either faulty or incompatible.

To determine if newly added RAM is causing a Stop message:

  1. Return the system to the original RAM configuration.

    If you have a FAT partition, start at DOS and delete the Pagefile.sys. If you have an NTFS partition, try to log back on as an administrator.

  2. Click Start, point to Settings, point to Control Panel, and then double-click System.
  3. From the System Properties dialog box, click the Advanced tab, and then click the Performance Options button.
  4. In the Performance Options dialog box, click the Change button located in the Virtual Memory area.
  5. From the Virtual Memory dialog box, click the individual hard disk(s) on which a paging file is located, and set the Initial Size and the Maximum Size of the paging file(s) to 0. Do not restart the system.
  6. Run Chkdsk /f /r on any hard disk that contained a paging file. If you have multiple paging files, run Chkdsk on nonsystem partitions first, because running Chkdsk on the system partition requires a restart.
  7. Restart the system.
  8. Set the paging file to an optimal level for the amount of RAM added.
  9. Shutdown the system and add your RAM.

    The new RAM must meet the system manufacturer’s specifications for speed, parity, and type (that is, FPM vs. EDO vs. SDRAM). Try to match the new RAM to the existing installed RAM as closely as possible. RAM can come in many different capacities, and more importantly, in different formats (SIMMs or DIMMs). The electrical contacts can be either gold or tin and it is not wise to mix these contact types.

If you experience the same error message after reinstalling the new RAM, run hardware diagnostics supplied by the system manufacturer, especially the memory scanner. For details on these procedures, see the owner’s manual for your computer.

When you can log on to the system again, check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. Disabling memory caching of the BIOS might also resolve this error.

More Information

For more troubleshooting information about the 0xC221 Stop message, refer to the Microsoft Knowledge Base or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.

For more troubleshooting information about the 0x221 Stop message, refer to the Microsoft Knowledge Base, using the keywords winnt and 0xC0000221, or the ResourceLink Web site. For information about these resources, see “Additional Resources” at the beginning of this chapter.


Hardware Malfunction Messages

Hardware malfunction messages are a form of Stop message. Like Stop messages, they are character-mode messages. They are caused by a hardware condition detected by the processor. The first one or two lines of the hardware malfunction message on one computer might differ from those on a different computer, even with the same failed component, depending upon the hardware abstraction layer (HAL) that is loaded at startup. However, these lines always convey the same idea, as shown in the following example for an x86-based computer:

Hardware malfunction.
Call your hardware vendor for support.

The installed HAL also determines how additional lines in each system’s message differ in format and content. Therefore, before doing what the hardware malfunction message recommends, contact a technician within your own organization to run hardware diagnostics on your computer. The information provided after the first two lines in the message helps your technician decide which hardware diagnostics to run. For example, for x86-based ISA bus computers, this information indicates whether it is a memory-parity error or a bus-data error. On x86-based EISA computers, if the hardware problem is in an adapter, the adapter slot number on the system board is displayed.

Important

In many situations, hardware failures first manifest themselves as errors that generate Stop messages. Software using the failing hardware can detect problems because of unexpected results before the hardware itself has been identified as faulty. This is why troubleshooting many of the Stop messages includes running hardware diagnostics on the system.

Under rare circumstances, hardware malfunction messages can be generated by software bugs—specifically driver problems. For example, if a problematic driver writes to the wrong I/O port, the actual device at the targeted port might generate a hardware malfunction message. However, most errors of this sort are detected and debugged before the software is released to the public.

If you need help from outside your organization to interpret the information on the screen, contact the hardware manufacturer for your specific brand of computer, adapter, or peripheral device.


Copywright

This is a preliminary document and may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unpublished work. © 1998 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, and other names of Microsoft products and/or services referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Any RFC excerpts are subject to the following statement:

Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.