- Customizing the Boot Sequence and System-Behavior Parameters
Most Windows operating systems automatically configure the default boot sequence.
However, there are many users who may need to modify this. For example, if you have a
multi-boot system, you may need to change the default operating system. Sometimes you
may need to increase the default interval when the boot menu is displayed, add custom
logo files and so forth. Here, we'll discuss some methods for customizing the boot
sequence. These methods aren't complicated, and any system administrator, support
specialist, or advanced user should be familiar with them.
A detailed description of all of the processes that take place when Windows NT-based
systems, including Windows 2000/XP and products of the Windows Server 2003 family
are booting, is provided in Chapter 6. You will also find information on the role of the
system registry in the boot process there.
To customize the boot sequence of any Windows NT-based system, you simply need to
edit a single INI file: Boot.ini. This file, which is necessary for the OS to boot, resides in
the root directory of the system partition. Because of this, it has the Hidden, System, and
Read-only attributes set. This means that Windows Explorer does not display this file by
To be able to view this and other protected files protected files using Windows Explorer,
log in to the local system as an Administrator. Start the Folder Options applet in Control
Panel or select the Folder Options command from the Tools menu in Windows Explorer
or My Computer. The dialog shown in Fig. 4.1 will open. Go to the View tab, and then
go the Advanced Settings field. Select the Show hidden files and folders option and
clear the Hide protected operating system files (Recommended) checkbox.
- Figure 4.1: The View tab of the Folder Options Window
Modifying the Boot Sequence and System Behavior via the User Interface
If you are an experienced Windows NT/2000 administrator, you are already accustomed
to the Boot.ini file format and can edit it manually using any text editor. More detailed
information on the Boot.ini file format will be provided later in this chapter. For an
advanced user, manual editing of this file won't be difficult. However, for a beginner, the
easiest method of editing this file is to use the System applet located in Control Panel.
This option allows you to specify the time interval for which the boot loader will display
the boot menu, thus allowing you to select the operating system (for multi-boot systems).
This option also allows you to specify the default operating system that will be loaded
when this interval expires and you haven't selected an option from the boot menu. To
configure these options in Windows NT 4.0, start the System applet from Control Panel,
go to the Startup'Shutdown tab, and set the options you need using the System Startup
Note Starting with Windows 2000, this capability has undergone significant changes.
Windows XP and Windows Server 2003 introduce further enhancements. Let us
consider these new features in more detail.
Configuring the Error Reporting Service
- To modify system behavior and the boot sequence, open the Control Panel window and
double-click on the System icon. The System Properties window will open. Go to the
Advanced tab (Fig. 4.2).
Figure 4.2: The Advanced tab of the System Properties window
A careful look at the Advanced tab of the System Properties window in Windows
XP/Windows Server 2003 reveals a particular enhancement that was first introduced with
Windows XP - the so-called Error Reporting Options (notice the Error Reporting
button located directly below the Startup and Recovery option group). The error
reporting function was designed by Microsoft in order to encourage users to help
developers improve future versions of the operating system. Any time an error occurs,
Windows XP/Windows Server 2003 displays a dialog prompting the user to let the OS
automatically generate an error report and send it to Microsoft (Fig. 4.3).
- Figure 4.3: A dialog prompting the user to create an error report and send it to Microsoft
This option is enabled by default, but if you want to customize its settings or disable the
feature entirely, click the Error Reporting button. The Error Reporting window will
appear (Fig. 4.4). In this window, you can specify the following options:
Figure 4.4: The Error Reporting window (Windows Server 2003)
Totally disable the Error Reporting service by selecting the Disable error
reporting radio button. Notice that, even if you disable the Error Reporting
service altogether, you can still enable an option that allows the service to inform
you of serious errors (such as STOP errors, also known as Blue Screens of Death).
To do this, select the But notify me when critical errors occur checkbox directly
below the Disable error reporting radio button.
- Enable the Error Reporting service by selecting the Enable error reporting
option. In this case, you can configure the service by specifying the types of errors
about which the service must inform you. For example, if the Windows operating
system checkbox is set, the service will report any problems with the Windows
components running in kernel mode. To enable the reporting of errors for add-on
programs, select the Programs checkbox. To further customize the program list,
click the Choose Programs button to open the Choose Programs window (Fig.
4.5). In this window, you can change the default reporting mode by creating a
custom lists of programs to be included in or excluded from error reporting.
Figure 4.5: The Choose Programs window
Note In comparison to Windows XP, the Error Reporting service in Windows Server
2003 has been enhanced further and provided with additional capabilities. For
example, you can now report unplanned server shutdowns by selecting the
Unplanned machine shutdowns option (see Figs. 4.4 and 4.6). Note also the Force
queue mode for program errors checkbox, which was also newly introduced with
Windows Server 2003. When this option is selected, the Error Reporting service
will queue error messages. This option is particularly useful when multiple
persistent application errors occur. In this instance, the service will display a
notification of the 10 most recent errors when a user with administrative rights logs
on to the system. Each error notification will be displayed in a separate window,
- thus providing the administrator with the opportunity to choose the appropriate
steps to be taken.
Figure 4.6: Notification on the unplanned system shutdown
The ability to automatically create reports on system and application errors is particularly
useful. If a company is able to keep and organize such records, it is then able to focus its
efforts on the areas that are causing most common errors. Support personnel are then be
able make necessary corrections, develop workarounds for the problems, and improve the
efficiency of their work. Thus, the adoption of this approach by Microsoft is well
justified, since collecting vast amounts of error reports on the areas that are problematic
for most customers provides a database allowing the company to improve its products
further. On the other hand, if your company is developing software or providing services
to a large number of customers, it can also benefit from this by redirecting reports to a
specially dedicated shared folder in your corporate network. Furthermore, as real-world
experience has shown, not every organization is willing to support extra communication
between their client systems and the outside world. Thus, the most effective approach for
a corporate IT department is to use the error reporting feature to their advantage by
redirecting automatically generated error reports to a corporate file share.
There are two ways of accomplish this: by configuring Group Policy and by editing the
registry. To redirect error reports to a corporate share using Group Policy, proceed as
1. On systems participating in workgroups, open the Control Panel window, double-
click on the Administrative Tools icon, then open the Local Security Policy snap-
in. To control systems attached to domains, start the Default Domain Security
Policy MMC snap-in for the same purp
Note Remember that when a Group Policy setting conflicts with a local setting,
Group Policy overrides local settings. Furthermore, in all cases, settings
established using the MMC snap-in override Control Panel settings. The
settings made in Control Panel apply only if no Group Policy is configured.
- Besides this, many additional settings are available when configuring error
reporting via Group Policy. More detailed information on Group Policy will
be provided in Chapters 10 and 11.
2. After opening Group Policy object, expand the console tree as shown in Fig. 4.7
(Computer Configuration | Administrative Templates | System | Error
Reporting). Three items will be available to you: Report Errors, Display Error
Notification, and a folder - Advanced Error Reporting Settings.
Figure 4.7: Redirecting error reports using Group Policy
3. Double-click on the Report Errors item and select the Enabled radio button in
the Report Errors Properties window. After you do this, several additional
options will become available, among which is the one that you need to configure
- namely, the Corporate upload file path text field. To change the error-report
destination, specify a path to the new location using the UNC format, for example:
\\myserver\myshare\my_dir. Note that the settings specified using Group Policy
will be stored in the registry under the
00C04fB984F9}Machine\Software\Policies\Microsoft\PCHealth\ErrorReporting DW key (Fig. 4.8).
- Figure 4.8: Settings specified using Group Policy are saved in the registry
To perform the same task by editing the system registry and, at the same time, enforce
these settings for all users who log on in the local system, do the following:
1. Start Regedit.exe and expand the
key (Fig. 4.9). If this key doesn't contain the nested DW key, create it.
Figure 4.9: The contents of the
2. Create a REG_DWORD value named DWNoSecondLevelCollection, and set it to
0. Then create a string value named DWFileTreeRoot. To change the error-report
destination, specify a path to the new location. For example,
3. Click OK and close the Registry Editor.
4. To restore the original configuration and send reports directly to Microsoft, delete
the DWFileTreeRoot entry.
- Modifying the Boot Sequence
To set the boot and system behavior parameters, click the Settings button in the Startup
and Recovery option group at the Advanced tab of the System Properties window. The
Startup and Recovery window will open (Fig. 4.10).
Figure 4.10: The Startup and Recovery window
At the top of this window is the System startup option group, which allows you to
specify the default operating system and set the time interval during which the system
will display the boot menu.
Note In Windows 2000, the System startup options are the same as those in Windows
NT 4.0, but Windows XP and Windows Server 2003 provide a very convenient
enhancement - the System startup group now provides the option to edit the
Boot.ini file manually. To do so, simply click the Edit button (Fig. 4.10). Besides
this, Windows XP and Windows Server 2003 include the new Bootcfg.exe
command-line utility that allows to manipulate the Boot.ini file from the command
- The most interesting option group is System Failure, which allows you to specify system
behavior in case a STOP error occurs (these errors are also known as kernel errors or
"blue screens"). Let's look at these options in more detail.
If you need to identify a problem and discover its cause, you shouldn't overlook the
system log. Because of this, it is recommended that you select the Write an event to the
system log checkbox. If this option is enabled, the system will register an event in the
system log any time a STOP error occurs. An example of what this record will look like
is shown below:
Event ID: 1001 Source: Save Dump Description: The computer has
rebooted from a bugcheck. The bugcheck was: Oxc000021a (0xe1270188,
0x00000001, 0x00000000, 0x00000000). Microsoft Windows NT (v15.1381).
A dump was saved in: C:\WINNT\MEMORY.DMP.
If you select the Send an administrative alert checkbox, the system will send an
administrative alert to the network administrator's workstation any time a STOP error
Finally, if you need to get the computer up and running as soon as possible, you can
configure it to reboot automatically whenever a STOP error occurs. To enable this option,
select the Automatically restart checkbox.
Note The following tip explains how to edit the Windows NT/2000/XP and Windows
Server 2003 registry to make the system reboot automatically when a STOP error
occurs. Open the system registry using Regedit.exe, expand the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl key, and set the Autoreboot value to 1. Theoretically, this tip is accurate, but there is
a much easier way to do this. Just select the Automatically reboot checkbox in the
Startup and Recovery window.
If STOP errors persist, you need to find out what's causing them. The best way to do this
is to analyze the memory dump. To instruct the system to create a memory dump when a
STOP error occurs, use the Write Debugging Information option. To specify the name
of the file in which to store the debugging information, fill in the Dump File field. If you
need to overwrite the contents of this file when the memory dump is created, select the
Overwrite any existing file checkbox. Note that these options haven't changed since the
release of Windows NT 4.0.
Starting with Windows 2000, Microsoft introduced an extended function for saving the
memory dump. If you are an experienced Windows NT user, you will remember that
Windows NT 4.0 dumps the entire contents of the physical memory. The size of the
memory-dump file generated by this system is slightly larger than the amount of physical
- memory that is present on the computer. Since STOP errors initiate in the system kernel,
the kernel data (for example, the state of a system at the time of a crash, including what
applications were active, what device drivers were loaded, and what code was being
executed) are of interest to the support specialists analyzing the dump. User-mode data
aren't useful for determining the cause of a crash. They just contribute to the size of a
crash dump file.
Because of this, starting with Windows 2000, the developers introduced a new option in
the Startup and Recovery window. This option provides you with some control over the
size of the crash dump. The first combobox from the Write Debugging Information
option group allows you to select the mode used for saving the crash dump. Beside the
ability to save the complete dump (this option is similar to the one existing in Windows
NT 4.0), Windows 2000/XP and Windows Server 2003 provide a Kernel Memory
Dump option that allows you to exclude application (user-mode) data. Only kernel
information will be stored in the crash dump. All crash-analysis tools compatible with
newer Windows versions, including Dumpexam and WinDbg, will interpret this file
correctly. This option allows you to save disk space (the amount will be different for each
system; it will also depend on the type of crash). My own experience has shown that, on
computers with 128 MB of RAM, a complete crash dump will consume about 128 MB
(actually, a little more); while a kernel dump will only consume about 40 MB.
Note Starting with Windows XP, this function was enhanced even further by providing
an additional option - namely, the Small Memory Dump, which allows you to limit
the dump to 64 KB (see Fig. 4.10). Note that when a STOP error occurs, Windows
XP and Windows Server 2003 always create a small memory dump. Thus, the Error
Reporting service considered above is always capable of creating a report on the
problem on the basis of this dump file, even if you have configured the system in
such a way as to create kernel, or even a complete memory dump.
Editing the Boot.ini File Manually
As has already been mentioned, Windows XP and Windows Server 2003 provide a very
convenient way of editing the Boot.ini file. However, if you are working with Windows
NT/2000 or you still want to use a text editor of your choice to open the Boot.ini file for
editing, clear the Read-Only attribute. This is necessary to save your changes.
To do this, run the following command from the command line:
attrib -r boot.ini
Boot.ini File Format
- The Boot.ini file is created automatically by the Setup program during the installation of
the operating system. This file is located in the root directory of the system partition and
is needed by the boot loader in order to display the boot menu (the screen that allows the
user to select the operating system).
A typical example of the Boot.ini file is shown below:
multi(0)disk(0)rdisk(0)partition(2)\WINXP="Microsoft Windows XP
multi(0)disk(0)rdisk(0)partition(3)\WINNT="Microsoft Windows 2000
Professional" /fastdetect /noguiboot
multi(0)disk(0)rdisk(0)partition(7)\XPRC1="Microsoft Windows XP
2002 Server (Tchek)" /fastdetect
multi(0)disk(0)rdisk(0)partition(8)\WINDOWS="Microsoft Windows XP
Home Edition (RC2 Tchek)" /fastdetect
Whistler Professional" /fastdetect /sos
C:\CMDCONS\BOOTSECT.DAT="Microsoft Windows Recovery Console"
C:\="Microsoft Windows" C:\="Microsoft Windows"
The Boot.ini file contains two sections: [boot loader] and [operating systems], Both of
these sections are described below.
The [boot loader] Section
The parameters contained in this section are described in Table 4.1.
Table 4.1: [boot loader] Section Parameters
Timeout The number of seconds the boot loader provides for the user to select an
operating system from the boot menu displayed on the screen. If the time
interval expires and the user hasn't yet chosen an operating system, Ntldr will
start loading the default operating system. If this value is set to 0, the boot
loader starts loading the default operating system immediately without
- Table 4.1: [boot loader] Section Parameters
displaying the boot loader screen, which prevents the user from making a
choice. If this value is set to −1, the boot loader will wait until the user selects
an operating system. Note that you must edit the Boot.ini file to set this value,
since the System option in the Control Panel interprets it as invalid.
Default The path to the default operating system.
Note The startup menu does not appear if Windows XP or Windows Server 2003 is the
only system installed on your computer. In this case, Ntldr ignores the time-out
value and starts Windows immediately.
The [operating systems] Section
This section contains the list of available operating systems. Each record contained in this
section specifies the path to the boot partition of the operating system, the string
displayed in the boot loader screen, and optional parameters.
The Boot.ini file supports the capability of loading multiple Windows NT/2000/XP or
Windows Server 2003 installations, as well as starting other operating systems, including
Windows 9x, MS-DOS, OS/2, LINUX, and UNIX.
The entries contained in the [operating systems] section of the Boot.ini file support
several optional switches, which are described in Table 4.2. Note that these switches
aren't case-sensitive. Switches that were introduced with Windows 2000 (Win2K) are
marked with an asterisk (*).
Table 4.2: Boot.ini Switches
/BASEVIDEO This switch causes Windows to load using a standard
VGA driver. If you have installed a new video driver
that isn't working correctly, this switch will allow you
to start the computer so that you can change the video
/BAUDRATE This switch enables kernel-mode debugging (it also
sets the /DEBUG parameter) and specifies the baud
rate to be used for this purpose. If you don't set the
baud rate, a default value will be used. If a modem is
attached, the default baud rate is 9,600 (for a null-
modem cable, the default baud rate is 19,200).
- Table 4.2: Boot.ini Switches
/BOOTLOG* If this switch is specified, Windows will write the boot-
process log into the %SystemRoot%NTBTLOG.TXT
file. This log will enable you to find out which drivers
were loaded successfully and which weren't.
/CRASHDEBUG If you include this switch, the kernel debugger is
loaded when the system boots, but remains inactive
unless a crash occurs. This allows the specified COM
port (or COM1 by default) to remain available for other
uses while the system is running. This switch is
especially useful if your system is subject to random
/DEBUG Enables kernel-mode debugging. The debugger is
loaded when the system boots and can be activated at
any time by a host debugger that is connected to the
computer. This mode is recommended when STOP
errors are persistent and reproducible.
/DEBUGPORT=comx Enables kernel-mode debugging and specifies an
override for the default serial port (COM1) to which
the remote debugger is connected. For example:
/FASTDETECT* This switch is new in Windows 2000. When you dual
boot NT 4.0 and Windows 2000 or later, the newer
version of NTDETECT.COM is used during the boot
process. In Windows 2000/XP and Windows Server
2003, the detection of parallel and serial devices is
carried out by plug-and-play device drivers. Windows
NT 4.0, however, expects NTDETECT to carry out the
detection. Specifying FASTDETECT causes
NTDETECT to skip parallel and serial device
enumeration for a boot into Windows 2000/XP or
Windows Server 2003, while omitting the switch
directs NTDETECT to perform enumeration for a boot
into Windows NT 4.0. Windows Setup program
automatically recognizes dual-boot configurations and
sets this switch for BOOT.INI lines that specify a boot
or a newer Windows version.
/MAXMEM This option will limit Windows to using only the
amount of memory that you specify. The number value
represents the number of MBs. For example:
- Table 4.2: Boot.ini Switches
/MAXMEM=16 would limit NT to using 16MB of the
system's memory. This option is useful if you suspect
that a memory chip is bad.
/NODEBUG Prevents kernel-mode debugging from being
initialized. Overrides the specification of any of the
three debug-related switches, /DEBUG,
/DEBUGPORT, and /BAUDRATE.
/NOGUIBOOT* This switch is new in Windows 2000. When this option
is selected, the VGA video driver that is responsible for
presenting bitmapped graphics during Win2K's boot
process isn't initialized. The driver is used to display
boot-progress information, as well as to print the Blue
Screen crash screen. Disabling it will disable Win2K's
ability to do those things as well.
/NOSERIALMICE=[COMx,y,z, Disables serial mouse detection of the specified COM
…] port(s). Use this switch if you have a component other
than a mouse attached to a serial port during the startup
sequence. If you use /NOSERIALMICE without
specifying a COM port, serial mouse detection is
disabled on all COM ports.
/SAFEBOOT* This option is new in Windows 2000. You should
never have to specify this option manually, since
NTLDR does it for you when you use the F8 menu to
perform a safe boot. Following the colon in the option,
you need to specify one of three additional switches:
MINIMAL, NETWORK, or DSREPAIR. The
MINIMAL and NETWORK flags correspond to a safe
boot with no network and a safe boot with network
A safe boot is a boot where OS loads only drivers and
services that are specified by name or group in the
Minimal or Network registry keys under
The DSREPAIR (Directory Services Repair) switch
causes Windows 2000 Server or Windows Server 2003
to boot into a mode where it restores the Active
Directory from a backup media that you present.
An additional option you can use is
- Table 4.2: Boot.ini Switches
"(ALTERNATESHELL)". This tells Windows to use
the program specified by
Shell as the graphic shell, rather than the default, which
/SOS This switch causes Windows NT/2000/XP or Windows
Server 2003 to print information about which drivers
are being loaded as the system boots. This is useful
when Windows NT/2000/XP or Windows Server 2003
won't start and you suspect that a device driver is
The list of Boot.ini switches shown above should not be considered as exhaustive, since it
includes only the most frequently used switches. The most complete and up-to-date list of
Boot.ini switches can be downloaded from http://www.sysinternals.com/bootini.htm.