| |
|
|
|
| |
|
| Real Mode |
|
In real mode, abbreviated as r-mode, (an operational mode (or processor mode or privileged levels) of 80286 and later x86-compatible central processor units (CPUs) placing restrictions on its operation), no virtual-to-physical translation of memory addresses occurs. Moreover, unlike protected mode, there is no direct software access to BIOS routines or peripheral hardware, no memory protection or multitasking at the hardware level unlike in protected mode. In other words, programs that use the memory addresses interpret them as physical addresses and that only the first 1MB of the computer's physical memory is accessible and addressable as it is characterised by a 20-bit segmented memory address space. All x86 CPUs start in real mode at power-on.
See: Protected Mode. |
|
| |
|
| Reboot (or warm boot) |
|
| The process of restarting a computer and reloading the operating system. To ascertain a warm boot or a cold boot the ROM BIOS starts up routines to check the value of two bytes located at memory location 0000:0472. Any value other than 1234h or 0x1234 (indicating a warm boot) indicates that it is a cold boot.
|
|
| |
|
| Recoverable Filesystem |
|
A recoverable filesystem ensures that if a catastrophic failure occurs or if there is an unexpected system halt, it will not be corrupted and disk modifications will remain complete. The structure of the disk volume is restored to a consistent state when the system restarts. If an unexpected system halt occurs, the metadata of a FAT volume can be left in an inconsistent state, leading to the corruption of large amounts of file and directory data. Conversely, NTFS implements recoverability by logging changes to metadata in a transactional manner so that the filesystem structures can be repaired to a consistent state with no loss of file or directory structure information.
NTFS limits its recovery procedure to filesystem data to ensure that a volume is not corrupted or lost due to filesystem corruption. Consequently, data loss is possible. Unless an application takes specific action (such as flushing cached files to disk), NTFS does not guarantee that recent data will not be lost. Transaction-based protection of data is available in most of the database products available for Windows so data loss should be minimal.
When there is a system failure, power failure, I/O operations in progress are immediately and often prematurely interrupted. Depending on what I/O operation or operations were in progress and how far along they were can result in filesystem inconsistencies (filesystem corruption). Severe corruption can render a volume completely inaccessible. At worst a failure will produce predictable, non-critical inconsistencies, which the NTFS can recover from swiftly or under extreme scenarios using Chkdsk and other troubleshooting techniques.
When any kind of filesystem receives a request to update the disk, it must perform several sub-operations before the update will be complete. The FAT filesystem uses the write-through algorithm that causes disk modifications to be immediately written to the disk. The write-through technique does not require the filesystem to order writes to prevent inconsistencies.
A recoverable filesystem such as NTFS tries to exceed the safely of a careful write approach while achieving the performance of the lazy write approach. A recoverable filesystem ensures volume consistency by using logging techniques or journaling. If the system fails, the recoverable filesystem restores consistency by executing a recovery procedure that accesses information that has been stored in a log file. Because the filesystem has logged its disk writes, the recovery procedure takes only a few seconds, regardless of the size of the volume.
The recovery procedure for the recovery filesystem is exact, guaranteeing that the volume will be restored to a consistent state. In NTFS, none of the inadequate restorations associated with the lazy write approach will occur.
A recoverable filesystem incurs some overheads for the safety it provides. Every transaction that alters volume’s structure requires that one record be written to the log for each of the transactions sub-operations. This logging overhead is reduced by the filesystem’s batching of log records – writing many records to the log file in a single I/O operation. In addition, the recoverable filesystem can employ the optimisation techniques of the lazy write approach. It can even increase the length of the intervals between cache flushes because the filesystem can be recovered if the system fails before the cache changes have been flushed to disk. This gain over the caching performance of the lazy write approach makes up for, and often exceeds, the overhead of the recoverable filesystem’s logging activity.
Neither the careful or lazy write approaches can guarantee protection of user data. If the system crashes while an application is writing a file, the file can be lost or corrupted.
The NTFS filesystem implements several strategies to improve reliability by guaranteeing the recoverability of the volume structure by ensuring that it will not be corrupted, so all files will remain accessible after a system failure. Although NTFS does not guarantee protection of user data in the event of a system failure – some changes can be lost from the cache – applications can take advantage of the NTFS write-through and cache-flushing capabilities to ensure that the file modifications are recorded on disk at appropriate intervals. Both cache write-though – forcing write operations to be immediately recorded to disk - and cache flushing – forcing cache contents to be written to disk – are efficient operations. NTFS does not have to do extra disk I/O to flush modifications to several different filesystem data structures because changes to the data structures are recorded – in a single write operation – in the log file. If the system failure occurs and the cache contents are lost, the filesystem modifications can be recovered from the log. Furthermore, unlike the FAT filesystems NTFS guarantees that user data will be consistent and available immediately after a write-through operation or a cache flush, even if it subsequently fails.
See: Check Disk (chkdsk.exe), Crash, FAT, Filesystem, Log File, Journaling, Log File, Logging, Metadata, NTFS (New Technology Filesystem), Stop Error, Blue Screen of Death (BSoD), Blue Screen, Stop Message, Exception Error, or Fatal System Error, and Volume. |
|
| |
|
| Recovery Console (RC) |
|
The Recovery Console (RC) is one of three Windows boot-problem recovery modes, the other two are the Last Known Good Configuration (LKGC) and Safe Mode (SM). The RC is a startable, text-only command interpreter environment separate from the Windows NT family operating system’s command prompt that allows an administrator access to the hard disk drive of a computer running Windows NT family operating systems, regardless of the file format used, for basic troubleshooting and system maintenance tasks using a limited set of administrative commands in concert with the Windows CD-ROM - unless the RC is installed directly to the hard disk drive.
Although SM is sufficient to use for systems that become unbootable because of device driver crashes during the boot sequence, in some scenarios a SM boot will not be sufficient to boot the system. For example, if a driver that prevents the system from booting is a member of the safe group, SM boot attempts will fail, or when a system module or critical device driver file that is part of a SM configuration becomes corrupted or when the system drive’s Master Boot Record (MBR) is damaged. All these problems can be circumvented and corrected using the RC.
The RC allows administrators to manage files and folders, start and stop services, and repair the system. It can also be used to repair the MBR and boot sectors and to format volumes. The RC also prevents unauthorised access to volumes by requiring the user to enter the system administrator password before using it.
To use RC a user must be logged on as an administrator.
To enter the RC start the computer from either the Windows 2000 or Windows XP setup CD-ROM, or their respective setup floppy diskettes, press ENTER at the “Setup Notification” screen, go to the “Welcome to Setup” screen, press R to repair a Windows installation, and then press C to enter and use the RC. Otherwise press F8, RC and press the ENTER key. RC will then scan the hard disk drive and find any Windows 2000 or Windows XP installations. Select the Windows installation to repair from the menu that was compiled when the hard disk drive was scanned. Type the number of the option, and the local administrator account password. Note: If no log-on Administrator password is present on your system, just press ENTER. The RC supports only a few specialised local command functions. The RC is a set of commands that can be used to manipulate the files and structures of the system partition and in particular on the system partition, as shown in the table of commands below.
cd or chdir |
Displays the current volume and directory or changes to the folder specified. Syntax:
Cd [path] [..] [drive:]
Chdir [path] [..] [drive:]
Path -- changes to the specified folder on the same volume.
.. -- changes to the parent folder.
drive: -- displays the active folder of the volume specified.
Using no switches displays the current volume and folder.
Cd treats spaces as delimiters, requiring that a space precede all arguments, including the use of double periods. Use quotation marks to enclose a path or file name that contains a space. |
Chkntfs.exe
(Windows XP Pro) |
Chkntfs.exe is new to Windows XP and Server 2003 and it is a command-line tool to disable the automatic running (at restart) of chkdsk on dirty volumes. In addition Chkntfs.exe can be used to cancel a session of chkdsk so it does not run when the computer restarts. |
chkdsk |
Checks a disk and, if needed, repairs and recovers the volume. chkdsk also marks bad sectors and recovers readable information. Syntax:
Chkdsk [drive:] [/p] [/r]
Drive: -- specifies the volume to check.
/p -- forces check if volume is not identified as bad.
/r -- locates bad sectors and recovers readable information (/p is automatic).
Chkdsk can be used without switches, and when no disk is specified the current volume is implied. Chkdsk requires that Autochk.exe be installed in the System32 folder or be available from the Windows 2000 through to Server 2003 operating system CD-ROM. Chkdsk.exe scans for and repairs physical problems, such as bad blocks, as well as logical structure errors, such as lost clusters, cross-linked files, or directory errors, on volumes on the hard disk drive. Note: Such corrections changes a volumes file allocation table and can cause data loss. Chkdsk.exe will prompt you prior to carrying out any of these types of corrections. |
cls |
Clears the screen. |
copy |
Copies a single file to a specified location. Syntax:
Copy sourse [target]
Source -- specifies the file to be copied.
Target -- specifies the destination folder and/or filename for the new file.
The use of wildcard characters (* and ?) is not permitted. If the target is not specified, it defaults to the current folder. If the file already exists, you will be prompted to overwrite it. Compressed files from the Windows 200 through to Server 2003 operating system CD-ROM are automatically decompressed as they are copied. |
dir |
Displays a list of files and folders within a folder. Syntax:
Dir [drive:] [path] [filename]
Drive: -- specifies the volume on which the files to be displayed reside.
Path -- specifies the location within the folder structure of the files to be displayed.
Filename -- specify file to be displayed.
Dir lists all the folder and files, including hidden and system files, which may have any of a number of attributes. Wildcards (* and ?) are also permitted. Conveniently, dir displays all files (within subdirectories too), hidden or not, and their attributes. |
fixboot |
Rewrites the boot sector code on a MBR disk. This is useful for repairing corrupted boot sectors. Running fixmbr overwrites only the master boot code, leaving the existing partition table intact. If corruption in the MBR affects the partition table, running fixmbr might not resolve the problem. Syntax:
Fixboot [drive:]
Drive: -- specifies the volume on which to rewrite a new boot sector.
If a drive is not specified, the default is the system boot volume. |
fixmbr |
Rewrites the master boot code of the MBR of the startup MBR disk. This command is useful for repairing corrupted MBRs. Running fixmbr might not resolve the problem and could make matters worse. Syntax:
Fixmbr [device-name]
Device-name -- specifies the name of the device needing a new MBR (such as \Device\HardDisk1).
If device-name is not specified, the default is disk0. If disk0 is not the device needing repair the device-name of the other disks can be obtained by using the command map. If fixmbr detects an invalid or non-standard partition table signature, you will be prompted for permission before rewriting the MBR. It is important to understand that this command can damage a partition table if a virus is present, if you have a third party operating system installed, if you have a non-standard MBR, or if a hardware problem exists this command may cause volumes to become inaccessible. It is recommended that a full up-to-date anti-virus scan be carried out prior to using fixmbr.
The equivalent Windows NT and 2000 RC feature to DOS 5+ and Windows 9x & Millennium FDISK /MBR (which rewrites a new boot code in the first 446 bytes of the MBR but leave the 64-byte table alone) is called FIXMBR. RC’s equivalent to FDISK is DISKPART |
map |
Lists all drive letters, filesystem types, volume size, and mapping to physical devices that are currently active. Syntax:
Map [] |
The command bootcfg /rebuild is specific to Windows XP and not Windows 2000.
Warning: Using the RC can damage a working or partly working operating system to the point that the only option is to reinstall. There is no undo or read-only feature, and not all the commands ask for confirmation. If you are unsure, review what you want to do and the tools you need to do it with before proceeding.
Other commands not shown are the commands to disable and enable drivers and services. If the registry is corrupted or missing or no valid installation(s) is found, the RC starts in the root of the startup volume without requiring a password.
Although access to folders is restricted, commands such as chkdsk, fixboot, and fixmbr are permitted for limited disk repairs.
The following folders are accessible by default:
- The root folder of any volume.
- %SystemRoot% and subfolders of the currently logged on Windows 2000 through to Server 2003 installations.
- \Cmdcons and subfolders (if they exist).
- Folders on removable media disks, e.g., CD-ROM and floppy diskette drive.
Nevertheless, the RC will not permit access to directories other than the root directory, the system directory of the installation logged on to, or directories on removable drives such as CDs and floppy diskettes unless local security policy settings stored in the SECURITY hive of the registry of the installation into which the user has logged and set is permitted. This prohibition provides a certain level of security for data that an administrator may not usually be able to access.
The RC uses the native Windows system call interface to perform file I/Os to support such commands as Cd, Rename, and Move. The Enable and Disable commands, which allow the changing of startup modes of device drivers and services, work differently by accessing the installation(s) Service key and manipulating the Start value of the specified driver’s key, changing the value to SEVICE_DISABLED. The boot driver will not load.
When accessing the RC using the Windows CD-ROM or boot diskettes etc, by the time the option to install or repair has been displayed, a copy of the Windows kernel, including all necessary supported device drivers, e.g., NTFS or FAT drivers, SCSI drivers and a video driver etc are available. The first user-mode program the kernel executes is the Session Manager (Smss.exe). When the RC is run, Smss loads and starts two drivers that implement the RC: Spcmdcon.sys (MBR code exists in this system file for Windows 2000/XP and Server 2003 and is always the same) and Setupdd.sys (MBR code exists in this system file for Windows 2000/XP and Server 2003 and is always the same). Spcmdcon.sys presents an interactive command prompt and performs high-level command processing. Setupdd.sys is a support driver that gives Spcmdcon.sys a set of functions that lets Spcmdcon.sys manage disk partitions, load registry hives, and display and manage video output. Setupdd.sys communicates with disk drivers to manage disk partitions and uses basic video support built into the Windows kernel to display messages on screen. Once a user’s password is authenticated the system the user is logged on to can be used via the RC.
Initially use the RC commands to resolve problems by temporarily disabling services and processes, replacing missing or corrupted files, check a volume’s integrity, and hard disk drive surface and other manual recovery operations such as fixing MBR and boot problems.
See: Master Boot Record (MBR) for solution on MBR corruption. |
|
| |
|
| Reparse Data |
|
This is user-defined data about the file or directory. For example, its state or location that can be read from the reparse point by the application that created the data, a filesystem filter driver, or the I/O Manager.
See: Mount Points, Reparse Data, Reparse Point, and Reparse Tag. |
|
| |
|
| Reparse Point |
|
An NTFS file or directory that has a block of data called reparse data associated with it. A reparse point is a block of arbitrary data with some fixed header data that Windows associates with an NTFS file or directory. An application or the system defines the format and behaviour of the reparse point, including the value of the unique 32-bit reparse point tag that identifies reparse points belonging to the application or system and specifies the size and the meaning of the data portion of a reparse point (the data portion being anything up to 16KB) located in the $REPARSE_POINT attribute of a file or directory. Reparse points store their unique tag in a fixed segment. Any application that implements a reparse point must supply a filesystem filter driver to watch for reparse-related return codes for file operations that execute on NTFS volumes. Moreover, the driver must take appropriate action when it detects the codes. NTFS returns a reparse status code whenever it processes a file operation and encounters a file or directory with an associated reparse point. The reparse tag allows the component responsible for interpreting the reparse point’s reparse data to recognise the reparse point without having to check the reparse data.
Whenever an application creates or deletes a reparse point, NTFS updates the \$Extend\$Reparse metadata file, in which NTFS stores entries that identify the file record numbers of files and directories that contain reparse points. Storing the records in a central location enable NTFS to provide an interface for applications to enumerate all a volume’s reparse points or simply specific types of reparse points, i.e., mount points. A reparse point that points to a volume is called a volume mount point. A reparse point that points to a directory is called a Junction Point.
See: Symbolic Link (or Junction Point), Mount Points, Reparse Data, and Reparse Tag. |
|
| |
|
| Reparse Tag |
|
The reparse tag allows the component responsible for interpreting the reparse point’s reparse data to recognise the reparse point without having to check the reparse data.
See: Mount Points, Reparse Data, and Reparse Point. |
|
| |
|
| RLL (Run Length Limited) |
|
A type of encoding that derives its name from the fact that the techniques used limit the distance (run length) between magnetic flux reversals on the hard disk drive platter. The principal behind RLL encoding is to mix clock and data flux reversals and thereby improve efficiency by densely packing encoded data. The two parameters that define RLL are the run length and the run limit, hence its name.
Several types, “family”, of RLL encoding techniques exist, although only two are commonly used. (1, 7) RLL (or 1,7 RLL) encoding increases storage capacity by about 30 per cent over MFM encoding and is most popular in the very highest capacity hard disk drives due to the better window margin. Whereas (2, 7) RLL (or 2,7 RLL) encoding increases/improves storage capacity by 50 per cent over MFM encoding and is used in the majority of RLL implementations. Most IDE, ESDI, and SCSI hard disk drives use one of these forms of RLL encoding.
See: Data, MFM Encoding (Modified Frequency Modulation encoding). |
|
| |
|
| Root Directory |
|
The root directory is the main directory of any hard disk drive or floppy diskette etc. If has a fixed size and location for a particular disk volume and cannot be resized dynamically the way subdirectories can.
See Directory, and Systemroot. |
|
| |
|
| Routine |
|
A routine is a set of frequently used instructions. It can be considered as a subdivision of a program with two or more instructions that are related functionally.
See: Subroutine. |
|
| |
|
| |
|
| |
|
| |
|
|
