| |
|
|
|
| |
|
| Safe Mode |
|
Safe Mode (SM) is one of three Windows boot-problem recovery modes, the other two are the Last Known Good Configuration (LKGC) and the Recover Console (RC). Diagnosing and correcting hardware and software problems that affect the startup process is an important troubleshooting skill. Resolving startup issues requires a clear understanding of the startup process and the core operating system components. To diagnose and correct startup problems, an understanding of what occurs during startup is essential. The first step in isolating a startup problem is to determine whether the problem occurs before, during, or after Windows starts up.
In x86-based systems, startup failures (or unexpected system halts) that occur before the operating system loader (NT Loader, Ntldr) starts could indicate missing or deleted files, or damage to the hard disk drives MBR on the MBR disk, partition table, or boot sector. If the problem occurs during startup, the system might have incompatible software or drivers, incompatible or improperly configured hardware, or corrupted system files.
Windows offers a way to troubleshoot problems by booting into Safe Mode, a startup environment diagnostic boot configuration - a method of starting the minimal set required to start the Windows GUI by running only a subset of the drivers, files and services into the systems memory that are specified by name or group under the Minimal or Network registry keys, when problems prevent the system from starting normally. Safe Mode relies only on the drivers and services necessary for booting Windows, avoiding the loading of third-party drivers and other non-essential drivers that might otherwise result in a system halt/crash.
The following registry subkeys list the drivers and services that start in Safe Mode, without networking and with networking respectively:
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Network
The MINIMAL and NETWORK flags correspond to Safe Mode boot with no network and Safe Mode boot with network support, respectively.
Safe Mode is available by pressing the F8 function key during startup: after the firmware POST process completes but before the Windows NT family operating system displays the graphical output. Once the Windows NT family operating system’s advanced Option Menu is displayed, select the option to start the computer in Safe Mode or press the ESC key to return to normal startup. There is a choice of three Safe Mode types: Safe Mode, Safe Mode With Networking, and Safe Mode With Command Prompt. Standard Safe Mode comprises the minimal number of device drivers and services necessary to boot successfully. Safe Mode With Networking adds network drivers and services to the drivers and services that Safe Mode includes. Safe Mode With Command Prompt is identical to standard Safe Mode except that Windows runs the command prompt application (Cmd.exe) instead of Windows Explorer as the shell for the system enabled GUI mode.
Start Menu Option |
Description |
Safe Mode (SM) |
Loads the minimum required basic device drivers and system services to start the system. Programs located in the Startup Programs group are not started. SM is not always enough to get a damaged installation back up and running. |
Safe Mode With Networking |
Similar to standard SM, but also adds essential services and drivers needed to start networking. SM With Networking allows Group Policy to be implemented, including those implemented by the server during the logon process, and those configured on the local computer. |
Safe Mode With Command Prompt |
Similar to standard SM but loads the command interpreter instead of Explorer.exe as the user shell. |
Enable Boot Logging |
Creates a log file, Ntblog.txt in the %SystemRoot% folder, during normal startup, which logs the name and status of all drivers loaded into memory. |
Directory Services |
Only applies to, Windows 2000 through to Server 2003, domain controllers. |
Restore Mode |
Displays system information such as the number of processors, amount of main memory, Service Pack status, and build number during startup. |
Debugging Mode |
Start Windows 2000 through to Server 2003, in kernel debug mode, which allows a debugger to break into the kernel for troubleshooting and system analysis. Kernel debugging refers to the investigation of internal kernel data structures and/or steeping through functions in the kernel so that internal Windows system information can be clearly displayed. |
Boot Normally |
Start Windows 2000 through to Server 2003, loading all normal starting files and registry values. |
Note: A boot log file, Ntbtlog.txt, is automatically created every time the computer is started in Safe Mode. Unlike non-Windows NT family operating systems, Windows NT family operating systems do not automatically initiate Safe Mode after the system startup has failed. When starting Windows NT family operating systems in Safe Mode, only essential drivers and system services are loaded, including the mouse, keyboard, CD-ROM, standard VGA device drivers, the Event Log, PnP, Remote Procedure Call (RPC), and Logical Disk Manager (LDM) system services. Safe Mode also bypasses programs referenced in startup Programs group folder (including the user’s profile, All Users profile, and the Administrator profile), programs referenced in the registry to automatically run, and all local group policies (which might also enforce the automatic start of an application). This makes Safe Mode extremely useful for isolating and resolving conditions caused by faulty automatically started applications, system services, and device drivers.
Safe Mode knows which device drivers and services are part of the standard and networking-enabled Safe Mode by the specified name or group under the Minimal or Network registry keys shown below. Each subkey contains more subkeys that specify the names and groups of device drivers or services or of groups of drivers. Each subkey under the SafeBoot key has a default value that describes what the subkey identifies.
When booting into a Safe Mode configuration, the boot loader (Ntldr) passes an associated switch to the kernel (Ntoskrnl.exe) as a command-line parameter, along with any switches a user may have specified in the Boot.ini for the installation that is booted. When booting into any Safe Mode, Ntldr passes the /SAFEBOOT: switch. Ntldr appends one or more additional strings to /SAFEBOOT, depending on which type of Safe Mode is selected. For the standard Safe Mode, Ntldr appends MINIMAL, and for network-enabled Safe Mode, it adds NETWORK. Ntldr adds MINIMAL(ALTERNATESHELL) for Safe Mode With Command Prompt and DSREPAIR for Directory Services Restore mode.
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Network
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal(alternateshell)
HKLM \SYSTEM\CurrentControlSet\Control\SafeBoot\Dsrepair
The Windows kernel scans boot parameters in search of the Safe Mode switches early during the boot and sets an internal variable so that the Service Control Manager (SCM) can determine what boot mode the system is in. Although the SCM (the first user-mode component to load during a boot) processes the services listed under HKLM\SYSTEM\CurrentControlSet\Services, it loads only services that the appropriate Safe Mode subkey specifies by name. Moreover, there are a number of special functions that determine which device drivers’ load during Safe Mode under the different Safe Mode types and their associated device driver group and services, e.g., smss.exe and Userinit.exe.
Userinit.exe, (\Windows\System32\Userinit.exe) is another user-mode component that needs to know whether the system is booting in Safe Mode. Userinit, the component that initialises a user’s environment when the user logs on, checks HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\UserAlternateShell. If this value is set, Userinit runs the program specified as the user’s shell in the value HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\AlternateShell rather than executing Explorer.exe. Windows writes the program name Cmd.exe to the AlternateShell value during installation, making the Windows command prompt the default shell for Safe Mode With Command Prompt. Even though command prompt is the shell, typing Explorer.exe at the command prompt will start Windows Explorer, making it possible to run any other GUI program from the command prompt too.
To determine whether a boot is going to be in Safe Mode a special function is on the lookout.
Use Safe Mode to resolve upgrading or installing specific device driver problems. This is perhaps the most common cause of a Windows system becoming unbootable. And because software and hardware configurations can change over time, latent bugs can materialise in drivers at any time, startup and non-startup problems so to temporarily disable applications, processes, services, or uninstalling software etc is one route to troubleshooting an unbootable system.
Logging on to the computer system in Safe Mode does not update the LastKnownGood control set. Therefore, 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.
On Windows XP systems with System Restore enabled, Safe Mode can detect the existence of restore points, and when they are present it will ask the user whether they wish to log into the installation to perform manual diagnosis and repair or launch the System Restore Wizard. Using System Restore to make a system bootable is an attractive troubleshooting solution whether the cause of the problem is known or not.
More intractable problems prior to booting normally into Windows can be achieved by depressing the function key F8 and selecting the option so that a boot log is created. Session Manager (Smss) will save the log of the boot, as is normally the case, which includes a record of device drivers that the system loaded and chose not to load to \Windows\ntbtlog.txt, obtaining a boot log if the cash or hang occurs after Smss initialises. When booting into Safe Mode, the system appends new entries to the existing boot log. Extracting the portion of the log file referring to the failed boot attempt, compare the “Did not load driver” entries of the boot log and compare them with the comparison tool Windiff. Systematically disable each driver that loads during the normal boot but not in Safe Mode. Continue booting in this manner until the system boots successfully again. Re-enable the driver(s) that were not culpable for the failed normal boot.
When a boot log is not possible, as Smss does not initialise, use Driver Verifier combined with crash dump analysis.
See: Last Known Good Configuration, Recovery Console (RC), and Windows NT-Based Startup Phases (and its references) |
|
| |
|
| SCANDISK.EXE |
|
| The default Windows 9x & Millennium hard disk drive testing program; might be also be refereed to as Error Checking in the Drive properties applet. Windows NT through to Server 2003 uses CHKDSK to test hard disk drives.
|
|
| |
|
| Sector |
|
Files, whether they represent text, a database, photographs, songs (audio) , movies (video), web pages, executable programs, a format combination, or anything else, are stored as a series of sectors.
A sector (a physical location) is an addressable (or hardware-addressable) unit (or block) of a storage medium, e.g., hard disk drive. Hard disk drives for x86 systems typically define a 512-user byte sector (block) size. In other words, a sector is a section of one track defined with identification markings and an identification number (sometimes known as the Physical Block Number (PBN) or Logical Block Number (LBN), respectively). Computers access certain sectors on a hard disk drive during startup to determine which operating system to start and where these partitions are located. The data stored on these sectors varies depending on the computer platform.
Most sectors hold 512-user bytes of data. Because of the encoding overhead and the requirements of the detection algorithms about 600-bytes are actually stored in a sector.
A hard disk drive has the capacity to store billions of bytes. To address an individual byte (to know where something is stored), huge numbers would be required. To simplify addressing and finding information on a hard disk drive, bytes are grouped into sectors. The first sector starts at zero, so to read what is in the 513th byte on a hard disk drive, sector 1 is addressed. Regardless as to whether one is only interested in the value of one particular byte, the entire sector is read into memory. A sector is the smallest addressable unit on a hard disk drive. More than one sector can be read at any one time, but no less than one sector.
An important convention to be aware of when editing raw sectors is Intel Byte ordering (little endian): whenever a value exceeds 255 (and thus more than one byte is required to store the value), bytes are stored in reverse order. To store a decimal number greater than 255, it is first converted to its hexadecimal equivalent, and then written in the bytes on the hard disk drive in reverse order.
Note that Intel Byte ordering system is not used exclusively, but it is used with respect to partition table data and some sections of the MBR.
Sectors have traditionally been uniquely identified in a hard disk drive by cylinder, head, and sector (CHS) coordinates. The "head" number indicates on which surface the sector is located. The "cylinder" number identifies the specific concentric track on that surface where the sector can be found. And the "sector" number indicates which of the hundreds of sectors on the track contains the data that is sought.
Note: The physical platters are logically divided and allocated into cylinders, tracks, and sectors as part of the disk subsystem’s formatting. Each sector contains one or more blocks of data depending on the blocking factor that is used to format the disk, e.g., 1,024, 2,048, 8,096 or higher for larger volumes (also known as the disk’s cluster size), determines how many blocks of data will be grouped together.
See: Byte (symbol B), CHS (Cylinder Head Sector), Hexadecimal Number Base System (HEX), Master Boot Record (MBR), and Partition Table. |
|
| |
|
| Session |
|
| A session consists of the processes and other system objects, such as the visible interactive window station (all interactive processes access), \WinSta0 (created by Win32k.sys, windowing system driver, in the \Windows directory), desktop, and Windows, that represents a single user’s workstation logon session. Each session has a session-specific paged-pool area used by the kernel-mode portion of the Windows subsystem (Win32k.sys) to allocate session-private GUI data structures. Moreover, each session has a copy of the Windows subsystem process (Csrss.exe) and the logon process (Winlogon.exe). |
|
| |
|
| Server |
|
| A server is a computer in a network that enables resources such as files and printers to be shared by multiple users. |
|
| |
|
| Shell |
|
| The generic name of any user interface (UI) software. COMMAND.COM is the standard shell for DOS; 32-bit Windows uses the Windows Explorer as a graphical shell and either COMMAND.COM (Windows 9x & Millennium) or CMD.EXE (Windows NT through to Server 2003) as the command-line shell. |
|
| |
|
| S.M.A.R.T. (Self-Monitoring Analysis and Reporting Technology) |
|
S.M.A.R.T., pioneered by Compaq in an effort to improve reliability, is an industry standard for advance reporting of imminent hard disk drive failure. When this feature is enabled in the BIOS and a S.M.A.R.T.-compliant hard disk drive is installed, detected problems can be reported. This enables the user to replace a faulty hard disk drive before it fails, that may otherwise have resulted in data lose.
Legally a manufacture in order to advertise S.M.A.R.T. compliancy needs only to refer to the signalling method between the hard disk drive’s electro-mechanical sensors and the host computer. Consequently, the term S.M.A.R.T. can have less protection value for the consumer, making it difficult and confusing to make valid comparisons of manufactures hard disk drives as their information on S.M.A.R.T. is not readily disclosed. Until an openly disclosed policy covering the principal S.M.A.R.T. indicators is publicly available the standard can be abused and at best limited.
Manufacturers that have supported one or more S.M.A.R.T. attributes (technological leading indicators) e.g., monitoring hard disk drive performance, faulty sectors, recalibration, cyclic redundancy check (often abbreviated CRC) errors, hard disk drive spin-up time, hard disk drive heads, distance between the heads and the hard disk drive platters, hard disk drive temperature, characteristics of the media, and motor and servomechanisms besides many others include: Samsung, Seagate, IBM (Hitachi), Fujitsu, Maxtor, and Western Digital. These manufacturers may not necessarily agree on precise attribute definitions and measurement units; therefore the list should be regarded as a general reference only. However, if a safety threshold for that attribute and hard disk drive is exceeded a warning is given.
Nevertheless, regardless of the secrecy employed by some hard disk drive manufactures, a number of operating system specific software can extend the users ability to monitor hard disk drive conditions through the S.M.A.R.T. interface and predict when a failure is likely to occur by logging deviations in attribute values, of which there can be many. This software may also possess the capability to distinguish between gradual degradation over time, i.e., wear and tear, and a sudden change, indicator of a serious problem or immanent failure.
See: Data. |
|
| |
|
| Soft Error |
|
| An error in reading or writing data that occurs sporadically, usually because of a transient problem, such as a power fluctuation. |
|
| |
|
| Software |
|
| A series of instructions loaded in the computer’s memory that instructs the computer in how to accomplish a problem or task. |
|
| |
|
| Starting Cluster |
|
| The starting cluster is the number of the first cluster occupied by a file and is inserted in the directory entry of every file. |
|
| |
|
| Stop Error, Blue Screen of Death (BSoD), Blue Screen, Stop Message, Exception Error, or Fatal System Error |
|
A catastrophic fault or an internal condition - the native function KeBugCheckEx being called, that prevents the operating system from continuing to run and which may place the filesystem and data at risk.
The operating system generates an obvious message, a screen with the Stop message (a character-based textual representation, full-screen error message displayed on a blue background in low-resolution VGA graphics mode), rather than continuing on and possibly corrupting data. A Stop message in turn indicates that the Windows NT family operating systems kernel detected a condition from which it cannot recover. Each message is uniquely identified by a Stop error code (a numeric code in hexadecimal form known as a bug check code) and a string indicating the error’s symbolic name. Moreover, Stop messages are usually followed by up to four additional hexadecimal numbers, enclosed in parentheses, which identify developer-defined error parameters.
The Stop error can be analysed using a crash dump or memory dump (default: %SystemRoot%/MEMORY.DMP). A crash dump is a record of system memory at the time of a crash that is useful in troubleshooting the cause. Although there are more than one hundred unique stop codes, most are rarely, if ever, seen on a production system. Instead, just a few common stop codes represent the majority of Windows system halt failures.
Defective memory, filesystem errors, viruses, hard disk drive corruption, controller and cabling problems and other system problems can trigger a stop error. The main culprit that results in 70% of Stop errors is related to drivers causing pool corruption. Pool corruption usually occurs when a driver suffers from a buffer overrun or buffer underrun bug that causes it to overwrite data past either the end or start of a buffer it is allocated from paged and non-paged pool. These crashes caused by pool corruption are almost intractable to debug because the system crashes when corrupted data is referenced, not when the corruption occurs. Not all crashes will result in a crash dump for troubleshooting purposes. The reason is that the disk subsystem for the system disk is not able to process disk write requests - a condition that may have triggered the system failure itself.Microsoft’s web site has a full listing of stop errors and their meaning that can be consulted.
See: Crash, and System Crash. |
|
| |
|
| Storage Area Network (SAN) |
|
Backup operations have evolved in terms of both user requirements and the technology used to accomplish backups. Usage requirements have dictated that backups be made more frequently, yet without disrupting application access to data. Backup operations evolved from stand-alone backups to backup operations happening across a local area network (LAN or Lan) to backup operations happening in a storage area network (SAN).
The imminence of (SAN or San), known as a block sharing system, introduced new concepts of backup operations. SAN (LAN-Free Backup, providing efficient use of shared resources, results in the backup data transfer load placed on the SAN, lightening the load on the LAN. Therefore, applications do not impede network bandwidth while a backup is occurring) is a high-speed special-purpose network (or subnetwork) that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users depending on the typology implemented. Typically, a SAN is part of the overall network of computing resources for an enterprise supporting disk mirroring, backup and restore, archival and retrieval of archived data, data migration from one storage device to another, and the sharing of data among different servers in a network. SANs can incorporate subnetworks with network attached storage (NAS or Nas) systems, also known as file sharing systems.
SAN is typically architected on Fibre Channel networking, but iSCSI, as a hard disk drive transport protocol, can be leveraged to create relatively cost effective SANs from networking technology, e.g., gigabyte Ethernet,
Moreover, the assignment of different categories of data to different types of storage media in order to reduce total storage cost, value or importance, can be implemented as part of a tiered (classed or levelled) storage system. Categories may be based on levels of protection needed, performance requirements, frequency of use, and other considerations, rather than managed uniformly.
Categories may be based on levels of protection needed, performance requirements, frequency of use, and other considerations. Tier 1 (class A or level Platinum) data, e.g., mission-critical, recently accessed, or top secret files stored on expensive and high-quality media such as double-parity RAIDs; tier 2 (class B or level Gold) data, e.g., financial, seldom-used, or classified files stored on less expensive media in conventional SANs. As the tier number increases, cheaper media may be used. Therefore, tier 3 (class C or level Silver) data in a 3-tier storage system might contain event-driven, rarely used, or unclassified files on recordable optical discs or tapes for long-term retention, environment. One problem that backup applications need to solve is backing up open files being accessed by active programs while the backup is being done. Note: For completeness the final tier is 4 (class D or level Bronze).
Finally, LAN-free backups and restore are more robust against errors because backups can be performed to multiple devices if one devise suffers from a problem. Moreover, restore can be performed from multiple devices also, allowing flexibility in resource scheduling; both backup and restore completing quickly due to SANs higher bandwidth.
See: Network Attached Storage (NAS), and Open File. |
|
| |
|
| Storage Management |
|
Storage management defines the way an operating system interfaces with non-volatile storage devices and media. The term storage encompasses many different devices, including tape drives, optical media, CD jukeboxes, floppy diskettes, local hard disk drives, and storage area networks (SANs). To the storage subsystem, the file is simply a collection of bits and bytes grouped together as blocks of data by the filesystem and applications that created the file. However, not all data is equal in value or importance, yet generally all information is treated equally in the way it is stored and managed. Windows provides specialised support for each of these classes of storage media. However, of fundamental importance is the kernel component of Windows, with respect to the hard disk drive storage subsystem, where upon during Windows initialisation, the Windows I/O Manager starts the hard disk drive storage drivers. Storage drivers in Windows follow a class/port/miniport architecture – miniport is a type of kernel-mode device driver that maps a generic I/O request to a type of port into an adapter type. Microsoft supplies a storage class driver that implements functionality common to all storage devices and a storage port driver that implements functionality common to a particular bus – SCSI (Small Computer System Interface; (pronounced scuzzy)) bus, or an IDE (Integrated Device Electronics) system – and OEMs supply miniport drivers that plug into the port driver surface windows to a particular implementation. Pressing F6 and installing a miniport driver for a RAID or host board adapter (HBA) controller, or a Serial ATA (SATA) hard disk drive during Windows installation are all examples. In the disk storage driver architecture, only class drivers conform to the standard Windows device driver interface. Miniport drivers, present the hard disks drives that they identify early in the boot process to the disk class driver, use a port driver interface instead of the device driver interface and the port driver simply implements a collection of device driver support routines that interface miniport drivers to Windows. The Windows disk class driver creates device objects that represent disks and partitions.
Furthermore, functions of the class/port and miniport drivers invoke sector-level disk I/O that the class, port, and miniport drivers provide to read a disk’s MBR-style or GPT-style partition table and construct internal representation of the hard disk drives partitioning. The disk class driver creates devices objects to represent each primary partition (including logical drives within extended partitions). Use Sysinternals Windows based Diskmon application, which uses the disk class driver Event Tracing for Windows (ETW) instrumentation to monitor I/O (read and write) stream activity of hard disks drives and displays.See: IDE (Integrated Device Electronics), Multi-path I/O (MPIO) Drivers, and Partition. |
|
| |
|
| Subdirectory |
|
A directory listed in another directory. Subdirectories themselves exist as files.
See: Directory. |
|
| |
|
| Subroutine |
|
A subroutine, generally synonymous with function, method, procedure, subprogram or “closed” subroutine depending on the programming language and methodologies, is a segment of code within a larger program that can be executed (or called) to perform a specific task yet remain relatively independent of the remaining code, by a single call.
A subroutine is routinely coded, and defined by parameters to refine its behaviour or to perform a certain computation with variable values, so that it can be executed multiple times and/or from multiple (or distinct) locations during a single execution of the program. The flexibility of a subroutine (often collected into libraries for sharing and reusing of code) makes it a powerful programming tool; judiciously used it can substantially reduce the size (and redundancy) and cost of a program, while improving its reliability and readability generally and more specifically for program maintainability and troubleshooting.
Note: A subroutine can be composed of multiple subroutines.
See: Routine. |
|
| |
|
Symbolic Link (or Junction Point) |
|
A mechanism for referring to an object name indirectly – a form of redirection. For example, an NTFS junction point (JP) (also referred to as junction or reparse point) or symbolic link (often shortened to symlink) (SL) - a file-system object - allows a directory to redirect a file (the target) or directory pathname transaction (the target) to an alternative directory. JPs – as with SLs – are transparent (meaning their implementation is invisible) to users and programs, and can be acted upon in exactly the same way as normal files and directories and so are a useful means of lifting directories that are deep in a directory tree to a more convenient depth without disturbing the original tree’s structure or contents. Remote directories cannot be linked using a JP, and they are restricted to linking folders and volumes only. JPs are based on an NTFS mechanism called reparse points in the NTFS filesystem from Windows 2000 onwards. Moreover, JPs can be used in a similar way to SLs – allowing the creation of a link to a folder that is, for most intents and purposes, the same as the folder itself. JPs have an advantage over a Windows shell shortcut link (.lnk) file, which are similar to SLs but will not be transparent for Application Programming Interfaces (API) I/Os functions.
For example, a SL (a special type of file) makes it possible for the Configuration Manager to link hives to organise the registry. A SL is a key that redirects the Configuration Manager to another key. Consequently, the HKLM\SAM key is a SL to the key at the root of the SAM hive.
Unlike a hard link (HL), a SL does not point directly to data, but merely contains a symbolic path which is used to identify a HL (or another SL). If a file or a directory has a SL (or reparse point) attached, the operating system calls a file system filter, indicated by the reparse point tag. The filter may implement any method of accessing the actual data. Hierarchical Storage Management (HSM) is a good example of how useful reparse points can be. Although directories can be linked using the reparse point mechanism (JPs), there is no way of linking to files. JPs can supplement NTFS file-only HLs.
Thus, when a SL is removed, the file to which it pointed is not affected. In contrast, the removal of a HL will result in the removal of the file, if it is the last HL to that file. As a result, SLs can be used to refer to files on other mounted filesystems. A SL whose target does not exist is known as an orphan. This can occur if the target of a SL is removed, the data is lost and all links to it become orphaned unlike with HLs - the remove of a SL has no effect on its target. Moreover, when opened, read, or written, a SL will automatically cause the file (link) to be redirected to its target. Nevertheless, functions to detect SLs are available, so applications may find and manipulate them if necessary.
Moreover, JPs allows for the 26 drive letter limitation to be surpassed. By using JPs it is possible to graft a target folder onto another NTFS folder or mount a volume onto a JP.
Microsoft provides utilities that in one capacity or another allows for the creation and manipulation of JPs, e.g., Linkd.exe, Mountvol.exe, Delrp.exe and fsutil included in Windows XP onwards. Therefore using standard Windows facilities HLs, SLs and JPs can only be created and manipulated at the command prompt.
There are a umber of caveats in using JPs: use NTFS ACLs to protect JPs from inadvertent deletion and to protect files and directories targeted by JPs inadvertent deletion or other filesystem operations, use specific RC tools and command, e.g., fsutil, and other third-party tools to delete or create JPs (refer to third-party tools mentioned at the end of this entry), be conscious of the fact that when applying ACLs or changing file compression in a directory tree that includes NTFS JPs as ACL inheritance is by design based on volumes.
A HL is a reference, pointer or directory entry for a file, to physical data on a storage volume. On most filesystems, all named files are HLs. The name associated with the file is simply a label that refers the operating system to the actual data. As such, more than one name can be associated with the same data across directories or the same directory. Though called by different names, any changes made will affect the actual data, regardless of how the file is called at a later time. HLs can only refer to data that exists on the same filesystem or volume. Because all the HLs must refer to the same Master File Table (MFT) entry, spanning volumes is not permissible. A further restriction is that only files can be hard-linked, not directories – (refer to symbolic link information, aforementioned).
On most file systems that support HLs (in Windows, a HL uses the same MFT entry as the original file); an integral value is stored with each physical data section. This integer represents the total number of links that have been created to point to the data. When a new link is created, via the API CreateHardLink function, this value is increased by one (for a newly created files this link count is equal to one). When a link is removed the process of unlinking dissociates a name attribute from the data on the volume; the HL link count value is decreased by one. It is the simplest way for the filesystem to track the use of a given area of storage, as zero values indicate free space and non-zero values indicate used space (data exists). Additional links can also be created to the physical data. The user need only specify the name of an existing link; the operating system will resolve the location of the actual data section. When the last link is removed, the MFT entry is removed, and the space is considered free. A process ambiguously called undeleting allows the recreation of links to data that is no longer associated with a name. However, this process is not available on all filesystems and is often not reliable. All the name attributes are independent, so deleting, moving, or renaming the file does not affect other HLs.
Note: The FAT filesystem does not support HLs, JPs or SLs.
Third-party tools: Junction Link Magic (JPs only) or HardLink Shell Extension (creates SLs, JP and HLs).
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
See: Mount Points, Reparse Data, Reparse Point, Reparse Tag, and Windows Registry. |
|
| |
|
| System Crash |
|
A situation whereby the computer freezes up and refuses to proceed without rebooting requiring a warm boot but sometimes a cold boot. A system crash is usually the result of faulty software. A system crash is unlike a hard disk drive crash as no permanent physical damage occurs.
See: Cold Boot, Crash, Stop Error, Blue Screen of Death (BSoD), Blue Screen, Stop Message, Exception Error, or Fatal System Error, Reboot, Rebooting, and Warm Boot. |
|
| |
|
| System Files |
|
Usually hidden files with the system attribute used to load, configure, and run the operating system. Generally, system files must never be deleted or moved. The DOS and Windows 9x and Millennium operating system files include IO.SYS and MSDOS.SYS. For Windows NT family operating system files IBMBIO.COM and IBMDOS.COM are used.
See: IBMBIO.COM, IBMDOS.COM, IO.SYS, and MSDOS.SYS. |
|
| |
|
| System File Corruption |
|
System file corruption can manifest for several reasons - including executables, drivers, or DLLs. A system file corruption message can appear as a message that begins “”, followed by the name of the file and a request to re-install the file after the BIOS Power-On Self Test (POST) at a black screen.
The reason this message appears is related to the fact that the volume on which a system file is located is corrupt, or one or more system files have been deleted or corrupted.
Please read the detailed description pertaining to the RC. By booting into the RC and executing the chkdsk command, it will attempt to repair volume corruption and any filesystem inconsistencies. Note: chkdsk supports only a few specialised local command functions, and in particular on the system partition. If chkdsk does not report any problems, then the only option available is to obtain a copy of the system file mentioned in the message from \System32\Dllcache as this is where Windows places a copy of system files for Windows File Protection (WFP). The system file must come from either the service pack or hotfix as the system file that is being replaced.
For multiple system file problems, repeat the above procedure until all system file problems are fixed. In the event that copying the system file(s) does not fix the problem, carry out a Windows repair install. Setup will reinstall all system files; leaving application data and registry settings unchanged.
See: Check Disk (chkdsk.exe), Recovery Console (RC), and Windows File Protection (WFP). |
|
| |
|
| System Hive Corruption |
|
System file corruption has occurred if NTLDR displays the message “: \WINDOWS\SYSTEM32\CONFIG\SYSYTEM”, after the BIOS Power-On Self Test (POST) at a black screen.
The reason this message appears is related to the fact that the system hive, which contains configuration information necessary for the system to boot, has become corrupt or has been deleted.
Please read the detailed description pertaining to the Recovery Console (RC). By booting into the RC and executing the chkdsk command on the boot volume, it will attempt to repair volume corruption and any filesystem inconsistencies. Note: chkdsk supports only a few specialised local command functions, and in particular on the system partition. If Chkdsk does not report any problems, then the only option available is to run the Microsoft ChkReg tool, which attempts to automatically repair registry corruption, and it works by running off of the Windows XP setup floppy diskettes. If all else fails copy the System hive stored in \Windows\Repair. Windows Setup makes a copy of the System hive after it completes an installation, so it will be possible to use this option at the expense of losing system configuration changes and device driver installations made since this System hive was created.
See: Basic Input/Output System (BIOS), Boot, Check Disk (chkdsk.exe), Recovery Console (RC), Windows File Protection (WFP), and Windows Registry. |
|
| |
|
| System Partition |
|
The partition that contains the hardware-specific files needed to load Windows, e.g., Ntldr, Osloader, Boot.ini, Ntdetect.com and so forth. The system partition can be, but does not have to be, the same as the boot partition.
See: Active Partition, Boot Partition, Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Bootsect.dos (multiple-boot system; Windows NT-based operating system system startup file #3 (if necessary only)), Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Ntbootdd.sys (Windows NT-based operating system system startup file #5), Ntdetect.com (Windows NT-based operating system system startup file #4), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Partition, and System Registry File (location - systemroot\System32\Config\System – operating system system startup file #8), |
|
| |
|
| Systemroot |
|
The path and folder name where the Windows system files are located. The systemroot does not need to be installed on the bootable C: partition/volume, and if this is the case the partition/volume that has the systemroot will be the system partition/volume. Having such an arrangement is beneficial for multiple installed operating systems. By default, Windows is installed on the C: partition/volume, systemroot being pre-Windows NT C:\WINDOWS, Windows 2000 C:\WINNT and Windows XP and Windows Server 2003 C:\WINDOWS and is both the boot and system partition/volume. By using the value %systemroot% it is possible to replace the actual location of the folder that contains the Windows system files.
The Windows NT family operating systems define “system” and “boot” partitions differently from other operating systems. The system volume contains files that are needed to start Windows NT family operating systems, such as the Windows NT Loader (Ntldr). The boot volume contains the Windows NT family operating system’s system files and folders such as systemroot and systemroot\System32. The boot volume can be, but does not have to be, the same volume as the system volume.
The term systemroot is one of many environment variables used to associate string values, such as folder or file paths, to variables that Windows NT family operating systems applications and services use.
See: Active Partition, Boot Partition, Boot Volume, Environment Variable, Ntldr (NT Loader; Windows NT-based operating system system startup file #1, Partition, System Partition, System Volume, and Variable. |
|
| |
|
| System Registry File (location - systemroot\System32\Config\System – operating system system startup file #8) |
|
The registry file that contains the data used to create the registry key HKLM\SYSTEM. The key contains the information that the operating system requires to start devices and system services.
See: Windows Registry. |
|
| |
|
| System Volume |
|
The volume that contains the hardware-specific files needed to load Windows on x86-based computers with a BIOS. The system volume can be, but does not have to be, the same as the boot partition. The system volume is where Windows places the Windows directory.
See: Active Partition, Active Volume, Basic Input/Output System (BIOS), Boot Partition, Boot Volume, System Partition, System Volume, Partition, Primary Partition, and Systemroot. |
|
| |
|
| |
|
| |
|
| |
|
|