| |
|
|
|
| |
|
| Landing Zone |
|
| An unused track on a hard disk drive’s surface on which the read/write heads can land when power is shut off. |
|
| |
|
| Large Mode |
|
A translation scheme used by the Award BIOS to translate the cylinder, head, and sector specifications of an IDE drive to those used by the enhanced BIOS. It does not produce the same translated values as LBA mode and is not recommended because other BIOS vendors do not support it.
See: CHS (Cylinder, Head, Sector), IDE (Integrated Drive Electronics), and LBA (Logical Block Addressing). |
|
| |
|
| Last Known Good Configuration |
|
Windows boots (and ends up with a specific set of registry entries that control how the operating system behaves, called control sets) by using a complex process that is heavily dependent on the registry. A specific set of registry keys and subkeys are used in the arrangement that can be inspected and modified if problems occur via the Service Control Manager (SCM) - (\System32\Services.exe).
Last Known Good Configuration (LKGC) is one of three Windows boot-problem recovery modes, the other two are the Recovery Console (RC) and Safe Mode (SM). If the current hardware settings, instability and startup problems prevent the computer from starting, the Last Known Good Configuration can allow the computer to be started and the configuration to be examined by reversing the most recent system and driver changes within a hardware profile. When the Last Known Good Configuration is used, restoring previous drivers and registry settings for the subkey HKLM\SYSTEM\CurrentControlSet looses all configuration changes that were made since the last successful logon. After a user logs on successfully, Windows updates the Last Known Good Configuration information to reflect the current configuration state. Pressing the F8 function key during the boot process (after the firmware POST process completes but before the Windows NT family operating system displays the graphical output) will give the user the Windows Advanced Option menu. From here the user can use the Last Known Good Configuration, which uses the last known good control set saved by the SCM, rolling back the system’s registry configuration back to a successful booting state.
Specifically, besides starting services, the system charges the SCM with determining when the system’s registry configuration, HKLM\SYSTEM\CurrentControlSet, should be saved as the Last Known Good Configuration control set. Once the successful auto-start process of services is complete, Winlogon notifies SCM when there is a successful logon, and SCM will save the current registry startup configuration as part of the last known good control set. The CurrentControlSet key contains the Services key as a subkey, so the CurrentControlSet includes the registry representation of the SCM. It also contains the Control key, which stores many kernel-mode and user-mode subsystem configuration settings. A successful boot consists of a successful startup of auto-start services and a successful user logon. A boot fails if the system halts because a device driver crashes the system during the boot or if an auto-start service reports a startup error message from either SERVICE_ERROR_SERVER or SERVICE_ERROR_CRITICAL.
Because the system’s configuration settings are stored in HKLM\SYSTEM\CurrentControlSet\Control and driver and services configuration is stored in HKLM\SYSTEM\CurrentControlSet\Services, changes to these parts of the registry can render a system unbootable. The Last Known Good Configuration is a useful mechanism for getting a system that crashes during the boot process back to a bootable state.
Although SCM will be aware when it has completed a successful startup of the auto-start service, it is Winlogon (\System32\Winlogon.exe) that will notify SCM when there is a successful logon. SCM will then save the current registry startup configuration.
Windows maintains several copies of CurrentControlSet, and CurrentControlSet as a symbolic registry link that points to one of the copies. The control sets have names in the form HKLM\SYSTEM\CurrentControlSetnnn, where nnn is a number such as 001 (contains the primary control set for Windows). It is used by default to boot the system, but this is copied to another CurrentControlSet) first or 002 (contains the backup control set for Windows). It is used to boot the system if CurrentControlSet 001 fails). The HKLM\SYSTEM\Select key contains the values that identify the role of each control set. The Last Known Good value under Select contains the number of the Last Known Good control set, which is the control set last used to boot successfully.
The Last Known Good Configuration is helpful in situations in which the change to CurrentControlSet, such as the addition of a service or device driver for example, causes the subsequent boot to fail.
Logging on to the computer in Safe Mode does not update the Last Known Good control set, so the Last Known Good Configuration remains an option even if Safe Mode is attempted first.
Note: Do not complete a normal logon if problems have been encountered, as logging on causes the Last Known Good Configuration control set to be overwritten. Instead, restart the computer and use the Last Known Good Configuration or Safe Mode unless it fails too.
One example is the problems that occur after the Windows splash screen displays, the desktop appears, or after logging on a BSoD occurs or hangs, or where the entire system is frozen or the mouse cursor tracks the mouse but the system is otherwise unresponsive are generally related to a device driver bug, corruption of a registry hive, with the exception of the System hive.
The first option is to use the Safe Mode or the Last Known Good Configuration. As mentioned in detail above, the Last Known Good Configuration consists of the registry control set that was last used to boot the system successfully. Because a control set includes core system configuration and the device driver and services registry database, using a version that does not reflect changes or newly installed drivers or services may avoid the source of the problem.
It is possible, as the Last Known Good Configuration saves the control set that the user wants to avoid and labels it as a failed control set, to ascertain the cause of the failure by comparing the control set of the successful boot and that of the failed control set as a pair of registry files. Run regedit.exe, and select HKLM\SYSTEM\CurrentControlSet, export from the File menu, and save as a file named successful.reg. Open, HKLM\System\Select, read the value of Failed, and select the subkey named HKLM\SYSTEM\Controlxxx, where xxx is the value of Failed. Export the contents of the control set to unsuccessful.reg. Use WordPad to globally replace all instances of “CurrentControlSet” in successful.reg with “ControlSet”. Using WordPad again, change all instances of “Controlxxx” (replacing xxx with the value of the Failed control set) in unsuccessful.reg with “ControlSet”. Run Windiff from the Microsoft Support Tools, and compare the two files.
The differences between the failed and good control set can be numerous, so examine changes beneath the Control subkeys as well as under the Parameters subkeys of drivers and services registered in the Services subkey, ignoring changes made to Enum subkeys of driver registry keys in the Services branch of the control set.
If the problem experienced is caused by a driver or service that was present on the system since before the last successful boot, the Last Known Good Configuration will not be of any value. Moreover, if a problematic configuration setting changed outside the control set or was made before the last successful boot, again the Last Known Good Configuration will not be of any value in making the system bootable. The alternative troubleshooting solution is Safe Mode. If the system boots successfully in Safe Mode and it is known that a particular driver is causing the normal boot to fail, the problem driver can be disabled using the Device Manage (devmgmt.msc, \System32\). The problem device driver can be disabled from the Action menu. In Windows XP/Server 2003 use the Roll Back Driver on the Drivers tab.
On Windows XP systems with System Restore enabled, there is an option in the Last Known Good Configuration.See: Recovery Console (RC), Safe Mode; Stop Error, Blue Screen of Death (BSoD), Blue Screen, Stop Message, Exception Error, or Fatal System Error; Windows NT-Based Startup Phases, and Windows Shutdown. |
|
| |
|
| LBA (Logical Block Addressing) |
|
A method used with SCSI (pronounced scuzzy) and IDE hard disk drives to translate the cylinder, head, and sector specifications of the drive to those useable by an enhanced BIOS. LBA is used with hard disk drives that are larger than 528MB (504GiB) and causes the BIOS to translate the hard disk drive’s logical parameters to those usable by the System BIOS.
See: Basic Input/Output System (BIOS), CHS (Cylinder, Head, Sector), and IDE (Integrated Drive Electronics). |
|
| |
|
| Library |
|
| A data-storage system, usually managed by Removable Storage. A library consists of removable media (such as tapes or disc) and a hardware device that can be read from or written to the media. There are two major types of library: robotic libraries (automated multiple-media, multi-drive devices called a jukebox or changer) and stand-alone drive libraries (manually operated, single-drive devices). |
|
| |
|
| Library Request |
|
| A request for an online library or stand-alone drive to perform a task. This request can be issued by an application or by Removable Storage. |
|
| |
|
| Local (standalone) Computer |
|
Standalone computers can be accessed directly without using a communications device, e.g., network adapter, or modem. Similarly, running a local program means running the program on a local computer, as opposed to running it from a server.
See: Server. |
|
| |
|
| Logical Disk Manager (LDM) Database |
|
The LDM database (or configuration database) resides in a 1MB reserved (private) space at the end of each dynamic disk of which the partitioning data resides also. The need for this space is as follows: Windows requires free space at the end of a basic disk before converting it to a dynamic disk. The LDM database consists of four regions: a header sector that LDM calls the Private Header, a table of contents area, a database records area, and a transactional log area. The Private Header sector resides 1MB before the end of a dynamic disk and anchors the database. Windows uses a GUID to identify almost everything. A GUID is a 128-bit value that various components in Windows use to uniquely identify objects. However, for dynamic volume, the LDM assigns each dynamic disk a DMIO-internal GUID, and the Private Header’s designation as information that is private to the disk. The Private Header also stores the concatenated name of the disk group (Windows LDM implementation includes only one disk group unlike LDM’s in UNIX which uses disk groups), and a pointer to the beginning of the database table of contents. For reliability, LDM keeps a copy of the Private Header in the disk’s last sector.
The database table of contents is 16 sectors in size and contains information regarding the database’s layout. LDM begins the database record area immediately following the table of contents with a sector that serves as the database record header. This sector stores information about the database record area, including the number of records it contains, the name and GUID of the disk group the database relates to and a sequence number identifier that LDM uses for the next entry it creates in the database. Sectors following the database record header contain 128-byte fixed-size records that store entries that describe the disk group’s partitions and volumes.
A database entry can be one of four types: partition, disk, component, and volume. LDM uses the database entry types to identify three levels that describe volumes. LDM connects entries with internal object identifiers. At the lowest level, partition entries describe soft partitions, which are contiguous regions on a disk; identifiers stored in a partition entry link the entry to a component and disk entry. A disk entry represents a dynamic disk that is part of the disk group and includes the disk’s GUID. A component entry serves as a connector between one or more partition entries and the volume entry each partition is associated with. A volume entry stores the GUID of the volume, the volume’s total size and state, and a drive-letter hint. Disk entries that are larger than a database record span multiple records; partition, component, and volume entries rarely span multiple records.
Note: For a dynamic volume to be assigned a drive letter, the Mount Manager (mountmgr) will make a request to the LDM first. There are a number of conditions that must be met in order for the LDM to permit the Mount Manager authorisation to assign a drive letter to a dynamic volume: if the Mount Manager database has a persistent drive letter for a volume, it ensures that only one volume is permitted the drive letter from the database; if the Mount Manager database does not have a persistent drive letter for a volume it will make a request to the LDM for one once the LDM searches for a recorded letter in it configuration database; if a suggested drive letter is already in use (or a foreign dynamic disk is imported, the Mount Manager will not have a record within its database, but has a drive letter stored in the LDM of the hard disk drive, on the local system) or there is no suggested drive letter from the LDM, the volume is assigned the next available drive letter.
See: Dynamic Disk, Dynamic Volumes, Mount Points, and Reparse Point. |
|
| |
|
| Log File |
|
A metadata file (filename: $LogFile) NTFS uses to record all operations that affect the NTFS volume structure, including file creation or any commands, such a Copy, that alter the directory structure. The log file is used to recover an NTFS volume after a system failure using the log file service (LFS). The LFS is a series of kernel-mode routines inside the NTFS driver that NTFS uses to access the log file. The caller – in this case NTFS – passes the LFS a pointer to an open file object, which specifies a log file to be accessed. The LFS either initialises a new log file or calls the Windows Cache Manager to access the existing log file through the cache. The LFS divides the log file into two regions: a restart area and an “infinite” logging area.
NTFS calls the LFS to read and write the restart area. NTFS uses the restart area to store context information such as the location in the logging area in which NTFS will begin to read during recovery after a system failure. The LFS maintains a second copy of the restart data in the event that the first restart data becomes corrupted or inaccessible. The remainder of the log file is the logging area, which contains transaction records NTFS writes to recover a volume in the event of a system failure. The LFS makes the log file appear infinite by reusing in a LILO (last in, last out) or FIFO (first in, first out) fashion, while guaranteeing that important information it needs is not lost. The LFS uses logical sequence numbers (LSNs) to identify records written to the log file. As the LFS cycles through the file, it increases the values of the LSN. NTFS uses 64-bits to represent LSNs, so the number of possible LSNs is virtually inexhaustible.
NTFS never reads transactions from or writes transactions to the log file directly. The LFS provides services NTFS calls to open the log file, writing log records, reads log records in forward or backwards order, flush log records up to a particular LSN, or set the beginning of the log file to a higher LSN. During recovery, NTFS calls the LFS to perform the following actions: read forward through the log records to redo any transactions that were recorded in the log file but were not flushed to disk at the time of the system failure: read backward through the log records to undo, or roll back, and transactions that were not completely logged before the system failure; and set the beginning of the log file or a record with a higher LSN when NTFS no longer needs the older transaction records in the log file. In other words, if filesystem modifications are unsuccessful, the corresponding transactions can be retrieved from the log file and can be either redone or undone as part of the filesystem recovery procedure.
Filesystem recovery occurs automatically the first time a program accesses an NTFS volume once booted. NTFS checks whether the transactions that were recorded in the log file before the failure were applied to the volume and if they were not redoes them. NTFS guarantees that transactions not completely logged before a failure are undone so that they do not appear on the volume.
The LFS allows for the writing of any kind of record to the log file, of which NTFS writes several types of record, two of which are update records and a checkpoint record. Update records are the most common type of record NTFS writes to the log file. Each update record contains two kinds of information: redo information (each record instructs NTFS how to reapply the sub-operations to the volume) and undo information (read record instructs NTFS how to roll back the sub-operations). Typically, update records that appear in the log file but proceeds the checkpoint operation begins and represents a modification to either the transaction or dirty page table. NTFS periodically writes a checkpoint record to the log file. The purpose of a checkpoint record is to assist NTFS in determining what processing would be needed to recover a volume if a failure were to occur immediately. After writing a checkpoint record (once every 5 seconds), preceding calls to the LFS to store a current copy of the transaction table and of the dirty page (two important tables NTFS maintains in memory that are necessary for recovery) are written in the log file. NTFS then records in the checkpoint record the LSN of the log records containing the copies of the tables. NTFS calls the LFS to locate the log records containing the most recent checkpoint record and the most recent copiers of the transaction and dirty page tables, and then copies them to memory, beginning at the restart area. The log file normally contains more update records following the last checkpoint record. These update records represent volume modifications that occurred after the last checkpoint record was written. NTFS must update the transaction and dirty page tables to include these operations. After updating these tables, NTFS uses the tables and the contents of the log to update the volume itself.
NTFS guarantees that recovery will return the volume to some pre-existing consistent state only and not necessarily immediately prior to a system failure.
See: Logging, NTFS (New Technology Filesystem), and Recoverable Filesystem. |
|
| |
|
| Logging |
|
A transaction-processing technique NTFS uses to maintain filesystem integrity and recoverability in the event of system crashes or other failures. In NTFS logging, the sub-operations of any transaction that alters the important filesystem data structures are recorded in a log file using the log file service (LFS) before they are carried through on the disk so that if the system crashes or other failures occur, partially completed transactions can be redone or undone when the system recovers. In transaction processing,this technique is known as write-ahead logging. In NTFS, transactions include writing to the disk or deleting a file and can be made up of several sub-operations.
See: Log File, NTFS (New Technology Filesystem), and Recoverable Filesystem. |
|
| |
|
| Logical Cluster Number (LCNs) |
|
The numbers of clusters from the beginning of the volume to the end with which NTFS refers to physical locations on a disk. To convert an LCN to a physical disk address, NTFS multiplies the LCN by the cluster factor to get the physical byte offset of the volume, as the disk driver interface requires.
See: Allocation Unit (or Cluster), Attribute (Resident & Non-Resident), Byte, Cluster (or Allocation Unit), Master File Table (MFT), NTFS (New Technology Filesystem), and Volume. |
|
| |
|
| Logical Drive |
|
A volume that is created within an extended partition on a basic Master Boot Record (MBR) disk and named by a DOS specifier, such as D or E. Logical drives are the equivalent primary partitions within an extended partition, except that there is a limit of four partitions on the MBR disk, whereas it is possible to create an unlimited number of logical drives per disk. A logical drive can be formatted and assigned a drive letter. A single physical drive can act as several logical drives, each enumerated with its own specifier. A primary partition can contain only one logical dos drive; an extended partition can contain one or more logical dos drives.
See: Primary Partition, Extended Partition, Master Boot Record (MBR), and MBR Disk. |
|
| |
|
| Logical Volume |
|
A volume created within an extended partition on a basic disk. It is possible to format and assign a drive letter to a logical drive. Only basic disks can contain logical drives. A logical drive cannot span multiple disks.
See: Basic Disk, Basic Volume, Partition, and Extended Partition. |
|
| |
|
| Long Name |
|
A folder name or file name longer than the 8.3 file name standard e.g., DOS (must be from one to eight characters long and can be followed by a filename extension, which can be from one of three characters long on the FAT filesystem). Windows 9x and above ease these constraints by allowing filenames of up to 255 (Windows 95 VFAT) and 260 (Windows NT family operating systems, NTFS) characters long characters including the directory path.
See: Filename. |
|
| |
|
| Lost Clusters |
|
| Clusters that have been marked accidentally as “unavailable” in the FAT even though they do not belong to any file listed in the directory. |
|
| |
|
| Low-Level Formatting |
|
Formatting that divides tracks into sectors on the platter surfaces. Places sector-identifying information before and after each sector and fills each sector with null data (usually hex F6). Specifies the sector interleave and marks defective tracks by placing invalid checksum (summation check) figures at each sector on a defective track.
See: Checksum (or Verification). |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
