Get IT Done: Tweak the Windows XP startup and shutdown process

Control the Windows XP startup and shutdown processes for users

If you support Windows NT or 2000 workstations, you’re probably familiar—at least to some degree—with the boot.ini file and the options it gives you for controlling startup. If you’ve come to Windows XP from Windows 9x or Me, boot.ini might be a bit foreign to you. Plus, you can control startup and shutdown in Windows XP in several other ways, including the Startup folder, scripts, registry keys, and group policies. I’ll explain the ins and outs of Windows XP startup and shutdown and the tools you can use to control both.

Setting boot and recovery options
Windows XP lets you easily configure the default operating system (OS) and other startup options through the Advanced tab of the System Properties sheet. To get there, right-click My Computer, choose Properties, and click Advanced. You can also use the System object in the Control Panel to open the System Properties sheet.

When you click Settings, XP displays the Startup And Recovery dialog box, which defines how the system starts, what happens when a system failure occurs, and how XP handles debugging. The System Startup options indirectly edit the boot.ini file, which XP uses at boot to let you select the operating system/configuration. If XP is the only OS and you don’t have the Recovery Console installed, the system doesn’t display the boot menu; instead, it immediately boots Windows XP. If the Recovery Console or other OSs are installed, the system displays the boot menu, enabling you to select which one to boot.

The System Startup group includes an option that sets the length of time the system displays the boot menu before booting the default OS. It also lets you set the default OS by selecting it from a drop-down list. The third option specifies the length of time the system displays a recovery options menu if the system has experienced a problem requiring automated recovery.

In most cases, you don’t need to edit the boot.ini file directly, but you can if you need to fine-tune startup or add other options to the boot menu. For example, you might want to change the name of one of the OSs listed in the boot menu, add troubleshooting options, or make other changes not offered through the System Properties sheet. Because boot.ini is a text file, you can open it in Notepad or another text processor for editing. Or just click the Edit button on the Startup And Recovery dialog box to open the file in Notepad.

Boot.ini contains two sections, each marked by a header in square brackets. The [boot loader] section contains settings that control the way the boot process works. This section defines the default OS (default value) and the length of time, in seconds, that the system displays the boot menu before booting the default OS (timeout value). To change the default value, look in the [operating systems] section and use the description for the OS to the left of the = sign. Here’s a sample entry:

multi(0)disk(0)rdisk(0)partition(1)\windows=“Microsoft Windows XP Professional” /fastdetect

In this case, you would use multi(0)disk(0)rdisk(0)partition(1)\windows as the value for default to launch XP with the default settings. The typical entry for Windows 9x or Me would be C:\, or the root of the drive where the Windows 9x/Me boot files are located.

How you create additional entries for the [operating systems] section depends on the target operating system. Windows NT, 2000, and XP all use the same format, based on Advanced RISC Computing (ARC) path names. Each entry specifies the physical drive and partition where the OS’s system folder is located. There are three entry types: multi, SCSI, and signature.

1. Multi
The multi syntax works for IDE, ESDI, and SCSI disks. With this syntax, NTLDR uses standard INT13 calls to load NTOSKRNL.EXE and the other system files required to boot the computer. Here’s the format for a multi entry, with explanations of each variable:

  • W specifies the adapter number and is usually 0.
  • X specifies the physical disk and is always 0.
  • Y specifies the logical disk number from 0 to 3.
  • Z specifies the partition number.

INT13 typically supports only one adapter. For IDE systems, this means the OS can boot from either disk on either IDE chain, for a total of four possible system locations. For SCSI systems, the multi syntax supports the first two drives on the SCSI adapter whose BIOS loads first. The multi syntax works only for the first adapter in the system when more than one is installed.

The SCSI syntax lets NTLDR load a SCSI device driver to boot the operating system rather than rely on INT13 calls to the BIOS. Here’s the format for the SCSI syntax, along with a list of variables:

  • W specifies the controller number.
  • X specifies the physical disk number.
  • Y specifies the logical unit number (LUN) of the disk and is usually 0.
  • Z specifies the partition number.

3. Signature
The signature syntax is similar to the SCSI syntax, but allows NTLDR to boot in Plug and Play systems where the SCSI adapter number can vary with each boot. The values for X, Y, and Z are the same as the SCSI syntax. The value W is a hexadecimal value that corresponds to the disk signature written to the disk’s Master Boot Record during the text mode portion of Setup. NTLDR searches the disks for the appropriate signature and boots from that disk. The signature syntax is used only if the system doesn’t support Extended INT13, and the disk is larger than 7.8 GB or the ending cylinder number is higher than 1024.

There are lots of additional switches you can use in boot.ini to control the way XP boots; they’re listed in Table A.
Table A
Switch Function
/3GB Relocates the kernel and executive components to the 3 GB memory location, and increases user mode memory from 2 GB to 3 GB.
/BASEVIDEO Boots Windows XP using the standard VGA driver, helpful for troubleshooting video driver problems.
/BAUDRATE=nnnn Sets the baud rate to use for debugging through the system's COM ports. The default rate for a modem is 9,600 and for a null-mode cable is 19,200. This setting causes the /DEBUG switch to activate (see the /DEBUG entry).
/BOOTLOG Enables boot logging to %systemroot%\ntbtlogl.txt
/BURNMEMORY=n Limits the amount of RAM in MB that Windows XP can use.
/CRASHDEBUG Loads the debugger at boot; debugger remains inactive unless a kernel error occurs; for troubleshooting kernel errors.
/DEBUG Loads and allows the debugger to be activated by any host debugger connected to the system; for debugging reproducible errors.
/DEBUGPORT=COMn Sets the serial port for debugging; this switch causes the /DEBUG switch to activate.
/FASTDETECT=[COMn | COMx,y,z?] Disables serial mouse detection on the specified port(s). Used by itself, the /FASTDETECT switch disables mouse detection for all ports. Use this switch to speed boot when a device other than a mouse is connected to the specified port(s) at startup.
/MAXMEM:n Sets the maximum amount of RAM Windows XP can use; for troubleshooting physical memory problems.
/NOGUIBOOT Hides the startup progress bitmap during boot.
/NODEBUG Does not use debugging.
/NUMPROC=n Forces a multiprocessor system to use a specified number of processors; for troubleshooting processor errors and multiprocessor applications.
/SAFEBOOT:switch Forces Windows XP to boot in Safe Mode using the specified switch, which can be minimal, network, or minimal (alternateshell).
/SOS Displays device drivers as they are loaded by the boot process; for troubleshooting drivers that might be causing a system or boot failure.
/PAE Allows the system that supports Physical Address Extension (PAE) mode to boot normally. PAE allows software to use more than 4 GB of physical memory.

Configuring system failure behavior
If you’ve been running Windows XP for any length of time, it’s a safe bet you’ve come to the conclusion that it’s a stable OS. Even so, XP isn’t perfect and a misbehaving program or service will bring the system down sooner or later. You can configure the way XP handles a system failure by setting options in the Startup and Recovery dialog box.

Tweaking registry settings can produce unintended results. Always back up the system before using the Registry Editor.

The first three settings determine what actions XP takes when the system fails. You can have it write an event to the System log, send an administrative alert on the network, and/or automatically restart. The option Write An Event To The System Log corresponds to the registry value:

Whether the system can actually write useful information to the log depends on the nature of the failure, but it’s still a good idea to enable this option.

The Send An Administrative Alert option causes XP to broadcast a network message to members of the administrator's group. This option corresponds to the registry value:

The Automatically Restart option causes XP to automatically reboot when the failure occurs, and corresponds to the registry value:

Use this option if you don’t want to view any STOP information displayed by the system (Blue Screen of Death) or want to make sure the system reboots as quickly as possible, such as when an administrator might not be immediately available. If you’re troubleshooting a reproducible problem, turn off this option to catch the STOP message.

When you need to configure boot options for the local system, the Startup And Recovery dialog box is the easiest method. Sometimes, however, you need to configure systems remotely. I included the registry values for system failure options to help you set these options on remote systems. Open the Registry Editor, connect to the remote computer, and change the values.

You can use the Bootcfg console application included with XP to make modifications to boot.ini files locally or across the network. This command-line tool gives you several options for modifying boot.ini through a script or dynamically through a local console session or remote telnet session. You can also use it in the Recovery Console to configure boot.ini. For an explanation of the Bootcfg syntax, search Windows XP Help And Support on the keyword bootcfg.

Controlling automatic applications
Like other Windows versions, XP uses a Startup folder to automatically start applications after logon. There are actually two Startup folders, one for all users and one for the current user. The contents of both folders are displayed together in the Start | All Programs | Startup menu. The Startup folders can contain any executables, such as programs, scripts, batch files, shortcuts, or even documents.

The Startup folder for the current user is located in the Start Menu\Programs\Startup folder in the user’s profile. This is typically Documents And Settings\user for new installs or %systemroot%\Profiles\user for systems upgraded from Windows NT. The common Startup folder for all users is located in \Documents and Settings\All Users\Start Menu\Programs\Startup, or the corresponding location in %systemroot%\Profiles for NT upgrades.

Windows XP executes all items in the combined Startup folder at logon. In some cases, you might want to bypass the Startup folder and not start its contents. For example, you might want to log on quickly, check your e-mail, and log off. Just hold down the [Shift] key during logon to bypass the Startup folder.

In some cases, you might want to redirect the Startup folders from their default locations. For example, you might want an entire Organizational Unit (OU) to have the same set of applications or scripts, all loaded from the same server. You can redirect the Startup folders through group or local policy, or through a registry change. You’ll find the policy in either group or local policy in the User Configuration | Windows Settings | Folder Redirection | Start menu branch. Edit the group policy using Active Directory Users And Computers or local policy with the Group Policy MMC snap-in focused on the local computer. Right-click the right pane and choose Properties.

You can redirect folders in one of two ways: Basic or Advanced. The Basic option lets you redirect the Startup folder to a common location for all users that fall under the scope of the policy. The Advanced option lets you redirect the Startup folder based on group membership. For example, administrators could have their Startup folder redirected to one location, while regular users would have their Startup folder redirected to a different location.

You can make a registry change to redirect the Startup folder if you can’t or don’t want to apply redirection through policies. The individual user Startup folder is defined in:
\Explorer\User Shell Folders\Startupregistry value.

This value is set by default to %userprofile%\Start Menu\Programs\Startup, where %userprofile% is replaced by the user’s current user-profile location, such as \Documents and Settings\user. The common All Users Startup folder is defined by the following registry value and is set by default to
%allusersprofile%\Start Menu\Programs\Startup:
\Explorer\User Shell Folders\Common Startup

In each case, you can redirect the folders by specifying an absolute or relative path.

There are a handful of alternative ways to start applications automatically in XP. This can be particularly puzzling when you’re trying to prevent applications from starting at logon and have already cleaned out the Startup folder. Windows XP executes applications listed in the following registry keys:

You can modify the list, adding or removing items, to control automatic program execution. Just open the Registry Editor and add or remove values as needed.

One final way to run an application automatically is as a service. If you’re trying to minimize the number of applications that start when you log on, check the Services console for noncritical services and set their startup mode to Manual.

Finally, check the contents of win.ini for load= and run= entries if you’ve upgraded from Windows 98 or Me. These settings cause applications to be loaded at startup.

Startup and shutdown scripts
One final way to control Windows XP startup and shutdown is through scripts. Startup scripts execute when the system boots and shutdown scripts execute when the system shuts down. Logon and logoff scripts execute and logon and logoff, respectively. After you create and test the script, you assign it through local or group policy. So, the next step is to decide the level at which you want to apply the policy, and then edit the policy at that level.

The startup and shutdown scripts are defined through the Computer Configuration | Windows Settings | Scripts branch. The Startup policy defines the startup scripts and the Shutdown policy defines the shutdown scripts. You can assign multiple scripts to each policy, and scripts are not limited to batch files—you can use any executable or even launch documents through document/program association.

Logon and logoff scripts are defined through the Logon and Logoff policies in the User Configuration | Windows Settings | Scripts branch. As with startup and shutdown scripts, you can assign multiple scripts in each policy. Where you store the scripts and how you reference their path in the policy depends on a handful of issues.

Windows 2000 and .NET servers maintain a script folder for each policy object. To locate the folder, open the policy in the Policy Editor and click Show Files on the policy’s dialog box. Windows opens the folder, and you can drag and drop files to and from the folder as needed. Scripts that reside in the specified folder need only be referenced by script name and don’t require a path. You can specify a UNC path to pull the script from a server or an absolute path to pull it from the user’s local computer. Scripts that are assigned through local policy rather than group policy are stored in the
%systemroot%\System32\GroupPolicy\User\Scripts\Logon folder, or a subfolder of that location.

You can also assign logon scripts through a user’s account as well as through group policy. These are called legacy scripts because you assign them the same way in Windows XP/2000/.NET as you do in NT. Place the scripts in the NETLOGON share of the user’s logon server. For Active Directory installations, this is \SYSVOL\domain\SCRIPTS by default. The location of the SYSVOL folder varies according to the location specified during Active Directory installation on the server. You can use the Shares branch of the Computer Management console on the server to locate the NETLOGON physical directory if you’re not sure where it is.

You can also specify account-based logon scripts for users in a workgroup, if needed. Their accounts are stored on the local computer rather than in Active Directory on a server. Start by creating a NETLOGON share on the user’s local computer and place the user’s scripts in the folder. Then, open the Local Users And Groups branch of the Computer Management console, open the user’s account, and click the Profile tab. Specify the script name in the Logon Script field. You can specify a relative path if the script is stored in a subfolder of the NETLOGON share. For example, specify common\logon.bat if the file LOGON.BAT is stored in \NETLOGON\COMMON. You can also use the %username% variable to point to a subfolder of NETLOGON that corresponds to the user’s account name. For example, if my account name is jboyce, I can use %username%\logon.bat to point to the file \NETLOGON\jboyce\logon.bat.

Four policies for script execution
Finally, take a look at a few group and local policy settings that control script execution. The User Configuration | Administrative Templates | System | Logon | Logoff branch includes four policies that let you control script execution:
  • Run Logon Scripts Synchronously. Enable this policy if you want to require that all scripts must finish processing before XP displays the user interface. If the policy is disabled, XP can display the user interface while scripts continue to execute.
  • Run Legacy Logon Scripts Hidden. Enable this policy if you want the user to be able to see the account-based logon script execute. The script appears in a console window. The console is hidden if the policy is disabled.
  • Run Logon Scripts Visible. Enable this policy to display the policy-defined logon scripts in a console window, allowing the user to view them as they execute.
  • Run Logoff Scripts Visible. Enable this policy to display the policy-defined logoff scripts in a console window.

These four policies reside in User Configuration | Administrative Templates | System | Scripts when set through local policy.