Floating-point error: Stack under

I have Windows for Workgroups v 3.11 loaded on an old 486.  This 486 is hooked up to the network and runs fine except for some reason we can no longer surf the Internet.  None of the TCP/IP settings have changed and I get the Application Error;  Floating-point error: stack under.
Any ideas on what this might be
Who is Participating?
derosaConnect With a Mentor Commented:
I had the same problem. It ended up being bad ram. You can it to work by running in standard mode. win /s
What You Will Learn
After completing this lesson you will be able to:
·      Install Windows NT.
·      Explain the process of upgrading from OS/2 or Windows 3.x for MS-DOS to Windows NT
·      Identify all the files accessed during the boot process and what errors occur if any of those files are missing
·      Identify cases where Windows NT would use the 'LastKnownGood' configuration to boot from
·      List the phases of the boot sequence and what takes place during each phase
·      List two problems/errors that may be caused by hardware problems or incompatibilities
·      Use REGEDIT to modify the registry
·      Use the Emergency Repair Disk created during setup.
Windows NT Setup process on x86 Based Systems
Windows NT and Windows NT Advanced Server have three installation options:
·      Floppy or CD-ROM based installation
·      WINNT.EXE installation utility
      This method is used for installing over the network.
·      Computer Profile Setup
      The Computer Profile Setup is designed for large corporate environments where there are a number of 100% identical systems. Since this utility is designed for a specific set of customers, it is included in the Windows NT Resource Kit.
Note   The installation of Windows NT and Windows NT Advanced Server are identical, except where noted in the below descriptions of the Setup process.
Floppy or CD-ROM based Windows NT Setup
The standard technique for installing Windows NT or Windows NT Advanced Server is from floppy disks or from a CD-ROM. As of the last beta release, Windows NT installed from 14 1.44 MB diskettes. Probably the most efficient method of installation is the CD-ROM based install. On x86 based systems, there is one Setup boot floppy, and everything else is installed from the CD-ROM disc. On RISC based systems, the SETUPLDR program must be executed from the \MIPS directory on the CD-ROM. There is no need for a boot floppy.
The floppy or CD-ROM Setup process does require one floppy disk for drive A: that can be reformatted. This disk is used to create the Emergency Repair disk that was talked about in the System Configuration portion of this course.
The Windows NT Setup Boot Floppy
The Windows NT Setup boot floppy accompanies the CD-ROM and is also Disk 1 of the set of disks used for the floppy installation. This disk contains the key files necessary to start the Setup process (SETUPLDR), to detect if there is a SCSI (Small Computer System Interface) adapter in the system (NTDETECT.COM), the Setup application itself (SETUPAPP.EXE), and the instructions for Setup (TXTSETUP.INF). The *.SYS files on the boot floppy are the drivers for the "most popular" SCSI devices.
If Setup is being run on a system that has a SCSI device installed that is not supported by one of these drivers, it is recommended to copy the proper Windows NT device driver onto the boot floppy before starting the Setup process.
Text mode portion of Setup
To start the Windows NT Setup process, the system must be rebooted with the boot floppy. The boot floppy loads and executes the Windows NT Setup Loader (SETUPLDR), which in turn executes NTDETECT.COM to determine the hardware configuration of the system. After this, Setup Loader loads and executes the Windows NT Setup program (SETUPAPP.EXE).
Note   The Text mode portion of Setup is not running under MS-DOS or Windows NT, without an operating system.
Much like the Windows 3.1 Setup, there is the choice to do an Express or Custom Setup of Windows NT which behave the same as Windows 3.x. Once the installation method has been chosen, Windows NT Setup will attempt to determine if there are any SCSI devices in the system. It is at this point where Setup will also allow SCSI device drivers from third party hardware vendors to be installed. Should a SCSI device be found, Setup will determine if this is a CD-ROM based installation or not. Should a SCSI device not be found, Setup continues checking your hardware configuration, looking for machine type, display adapter type, mouse, and keyboard information.
After the hardware detection process has been completed, Setup loads the file systems that Windows NT supports and must determine the destination of the Windows NT install. First Setup checks the system's local hard drives to determine if there is an installation of Windows 3.x on the system, by searching for WIN.COM. If there is, Setup will prompt to install over Windows 3.x, putting the Windows NT files in the \windows\system32 directory. If it is decided not to install onto Windows 3.x, the screen discussed in the next paragraph is brought up.
Disk Configuration
If an installation of Windows 3.x is not found, Setup displays the disk configuration information for the system. This screen allows for the creation and deletion of partitions and the selection for the partition to install Windows NT on. Once the partition has been selected to install Windows NT on, Setup gives the choice of either keeping the existing file system, or converting the partition to NTFS if the partition is currently formatted as FAT. In the case that the installation partition is formatted as HPFS, there will be choices to convert or reformat the partition. The recommended path for a new installation will be \WINNT.
Note   Remember, that ARC (ADVANCED RISC COMPUTER) compliant systems must have a FAT partition as the boot partition and therefore it may not be converted.
At this point, Setup will run a CHKDSK on the system's drives to ensure that there are no problems that may cause trouble during Setup. After the CHKDSK has completed, Setup starts copying the core Windows NT files, those that are necessary to bring up the graphic mode portion of Setup, into the selected destination path. When the necessary files and the registry information needed to boot Windows NT and continue Setup is in place, a blue screen will come up Requesting that the boot floppy be removed from drive A: and the system rebooted.
While the system is rebooting, it may be possible to catch a glimpse of the Boot Loader before Windows NT begins to load. The timeout= entry in the BOOT.INI has purposely been set to zero so that installation of Windows NT will be completed. After this, a blue screen will appear that reports Windows NT is being loaded and listing the startup devices that are being loaded.
The Graphic Mode portion of Setup
Next, the graphic portion of Setup begins. The graphic mode portion of Setup is much like the graphic mode portion of the Windows 3.x Setup, in that Setup is running under Windows NT. When this portion of Setup starts, Setup will prompt for the username and company information, followed by a screen that wants to know the name of the machine (15 characters or less).
Note   The machine name MUST NOT be the same as the domain name if this is a Windows NT Advanced Server installation.
Setup next asks for the Language, or Locale, of the system. This information is used for formatting of date, time, and currency information.
If a Custom Installation was selected, Setup gives the option as to what parts Windows NT to install. It is possible to select specific Windows NT components, whether or not to install network support, set up printers, and set up applications on the hard drive.
Note   If this is a Windows NT Advanced Server installation, the network option will be grayed out because the networking component is required.
Virtual Memory Configuration
Once again if Custom Installation was selected, there will be a configuration screen for virtual memory. This dialog allows the destination drive and size for the Windows NT page file to be selected, with a minimum and recommended size displayed for the drive. As was discussed in the earlier System Configuration section, the page file size should be RAM plus 12 MB. If an Express Installation was chosen, the virtual memory size is automatically set to the recommended size.
Printer Configuration
Next, is the portion of Setup where a default printer is set up. This should only be done if there will be a printer attached to the system locally or will be printing to non-Windows NT print shares. As was discussed in the earlier Windows NT Printing section, a local printer driver is not needed, nor recommended, if printing to a Windows NT print share. If intending to print to a non-Windows NT network printer, the printer should be temporarily assigned to LPT1 until the network components have been installed to allow redirection to the network print share (via the Network option).
Network Configuration
If installing Windows NT Advanced Server, or if decided to install network support for Windows NT, Setup will proceed with installing the necessary network components. If Setup is running as a Custom Installation, Setup will notify the user Setup is ready to automatically detect the system's network card, at this point the detection process can be approved or bypassed in order to make a manual selection. If a network card were to cause the auto-detection code to hang, the work around would be to run a Custom Installation and bypass the auto-detection code. Once Setup has determined the type of network card, it will report back what it has found and requests approval. At this time, it is possible to manually override the detection with a selection from the list of supported network cards. If running an Express Installation, Windows NT automatically searches for a network card and makes the appropriate selection. Once the network card has been determined, a dialog box will be presented that is specific to the detected network card's settings. This will typically include the I/O (Input/Output) port address, the memory address setting for the card, and the IRQ (Interrupt Request) setting.
Next, Setup installs the network services necessary to support the card and the default workstation and server components, copying the necessary files. Once these files have been successfully installed, Setup will install the rest of the files necessary for Windows NT. Once the rest of the Windows NT files are copied, the Network Control Panel Applet will start and display the network hardware and software configuration information. When OK is clicked on in this dialog, the binding process takes place, and the system is ready for the Domain setup.
Windows NT - Workgroup or Domain?
Windows NT allows a system to be either a member of a workgroup or a domain. If a workgroup is chosen, Setup will prompt for the local user account information (username and password). If a domain is chosen, a valid domain name is required. If the system does not have an account in the domain, an administrator name and password will have to be given to create a new account for the system in the domain. Once the necessary workgroup or domain information has been supplied, Setup will prompt for the password for the system's administrator account.
Domain Setup for Windows NT Advanced Server
The Windows NT Advanced Server installation requires that a system either join an existing domain or become a domain controller in a new domain. However, once the domain name has been set on a Windows NT Advanced Server system, the domain name CANNOT be changed without reinstalling Windows NT Advanced Server.
If the system is to be a controller in a new domain, it will become the Primary Domain Controller (PDC) and a domain name and administrator password must be supplied. If the Windows NT Advanced Server machine is to be a member of an existing domain, it will become a Backup Domain Controller (BDC). If this option is selected, an administrator name and password must be supplied for authentication purposes in order to receive a copy of the user database.
Final Stages of Setup
The next two steps performed by Setup are identical to Windows 3.1 setup, Program Manager groups are created and, if selected, Setup searches for applications. Next, Setup will create the Emergency Repair disk that was discussed in the System Configuration section of this course. Setup prompts for a blank disk, or one that can be reformatted, and then checks to be sure that it has not been given the Boot Floppy, by checking for TXTSETUP.INF. Setup will then format the disk, and then save the default configuration information (necessary to restore Windows NT) on the Emergency Repair diskette. Finally, Setup will ask for the system's time zone setting. Unless the system happens to be in the Greenwich mean time zone, the correct time zone must be selected.
The WINNT Setup option allows Windows NT to be installed across any MS-DOS supported network. This method of installation will be very useful for large corporations since it allows common share points to be used for wide distribution. The WINNT Setup process is similar to the Windows 3.1 Setup /A option, in that it takes all of the files from the floppy disks and/or CD-ROM and places them in one large directory on a server. The command line to instruct Setup to create this server directory is:
SETUP -n -i initial.inf -s <source path> -d <destination path>
Note   This command MUST be executed from within Windows NT, therefore one machine must be installed prior to the creation of the WINNT share point.
To use the WINNT Setup, the user must connect to the network share and change into the directory that contains all of the Windows NT files. The command line to start the WINNT Setup is simply: WINNT
How WINNT Setup works
The first thing that WINNT Setup does is to create a Setup boot floppy, just like the boot floppy used in the Floppy or CD-ROM installation (A blank, formatted floppy is needed to create the boot floppy). Next, WINNT downloads the complete Windows NT source directory onto the local partition in the $WIN_NT$.~LS directory.
After WINNT Setup is done copying files to the local hard drive, WINNT Setup will give instructions to leave the boot floppy in drive A: and reboot the machine. Windows NT Setup or Windows NT Advanced Server Setup (depending on which disks were used to create the network share directory) will run, just like the CD-ROM–based installation. However, instead of copying the files from the CD-ROM Setup simply moves the files on the hard disk into the appropriate destination directory.
Benefits of WINNT Setup
WINNT Setup is a relatively fast installation, since the files are transferred across the network, and simply moved around on the hard disk during the local Setup. There is no need for floppy disks other than one for the boot floppy. In addition, multiple machines can run the WINNT Setup at the same time and WINNT Setup does not require a network supported by Windows NT.
Note   that once Windows NT is installed, Windows NT will not see the network if it is unsupported.
Finally, if the Windows NT installation files have been customized, all customizations can be done in one common place.
WINNT Switches
The WINNT.EXE utility supports the following command line switches:
WINNT [/S[:]sourcepath] [/T[:]tempdrive] [/I[:]inffile] [/X | [/F] [/C] [/D[:]winntpath]]
·      /S[:]sourcepath - This specifies the source location of Windows NT files and must be a full path. By default, this is the current directory.
·      /T[:]tempdrive - This specifies the drive to contain the temporary setup files, the \$WIN_NT$.~LS directory. If this is not specified, Setup will attempt to locate a local drive with enough free space.
·      /I[:]inffile - This specifies the filename of the setup information file, which is DOSNET.INF by default.
·      /X - This does not create the Setup boot floppy.
·      /F - This does not verify files as they are copied to the Setup boot floppy.
·      /C - This skips the free-space check on the Setup boot floppy.
·      /D[:]winntpath - This allows a Windows NT directory to be specified, in which all files will be removed.
Note   The /D[:]winntpath switch does not remove the Windows NT Boot Loader, boot sector, or the BOOT.INI entry for the installation. It leaves the directory structure intact, and may also leave some file in the \<winnt root>\System32\config subdirectory.
Setup Switches
The following Setup switches are available:
Switch      Function

/?      displays Setup switch help
/f      turns off blue background
/i <INF Source File>      defaults to Current Working Directory and 'SETUP.INF'
/c <Script Section>      defaults to 'Shell Commands'
/s <Source Path>      defaults to Current working Directory
/d <Destination Path>      optional destination, mandatory on setup to a share
/t <Var> = <Value>      set INF <var> to <value>, multiple /T is valid
/n      setup to share mode
/v      turn on INF syntax checking
Computer Profile Setup
In many large corporate environments, there are large installed bases of identical system configurations as the result of a long term contract, or bulk purchase. Recognizing that these types of environments exist, Windows NT has an option for a Computer Profile Setup that addresses large corporate environments and allows rapid installation of Window NT or Windows NT Advanced Server on identical systems. This method is only usable on MS-DOS based systems and as noted earlier is shipped with the Windows NT Resource Kit.
There are two main components to the Computer Profile Setup utility:
·      Create Profile
      The Create Profile utility is run on a machine that has already had Windows NT, or Windows NT Advanced Server, installed on it and been configured with all of the desired user information, including user database, Program Manager groups, hardware drivers, etc. Create Profile automatically extracts this information and places it in a secure file with the extension .CPS. This .CPS file is a template file for that specific system configuration.
·      Install Profile
      Install Profile takes a specific template and installs the Windows NT or Windows NT Advanced Server configuration on the target machine. To provide the necessary unique identification for the target system, the domain name (if appropriate), the computer name, and the administrator account password must be supplied.
Windows NT Setup on ARC Compliant System
How to setup Windows NT on an ARC compliant, RISC based, system varies from manufacturer to manufacturer, so it is necessary to read the manufacturer supplied instructions. However, the below steps are typical of many RISC based systems:
 1.      Insert the Windows NT CD in the CD-ROM and restart the system.
 2.      At the ARC screen, choose Run A Program from the menu.
 3.      At the prompt, enter cd:\mips\setupldr and press ENTER.
 4.      Follow the on screen instructions.
      The above instructions assume that the systems hard drive has been initialized and at least partially partitioned. Once Setup has started, it is very similar to the Setup process described above for the Floppy or CD-ROM install.
      If this is not the case, the following utilities should be used to configure the system and setup the systems environment variables.
This utility is used to set up the System partition and must be invoked from the ARC Multiboot screen (discussed in more detail under the Boot Sequence section). ARCINST.EXE partitions, formats the hard disk, and copies HAL.DLL and OSLOADER.EXE to C:\OS\NT. This utility must be used before the Windows NT installation process is started.
Note   The System partition is the partition that contains the files necessary to load the operating system. In the case of Windows NT on an ARC based system, the necessary files are HAL.DLL and OSLOADER.EXE.
To invoke this utility, choose "Run A Program" from the ARC Multiboot menu. After selecting this menu option, the path to ARCINST.EXE will have to be specified at the prompt. Valid entries are:
·      \mips\arcinst.exe
·      scsi()cdrom(2)fdisk()\mips\arcinst.exe
      Once started, choose "Configure System Partition" which allows for partitioning and formatting, as FAT, of the hard drive. On ARC based machines the System partition must always be formatted as FAT, and has to be at least 2 MB in size.
This utility is used to configure the built in Multiboot functionality on ARC based systems and has the following options:
·      Load Default Configuration
      This option allows new values to be specified in the firmware, such as screen resolution, etc.
·      Load Default Environment
      This resets the default environment variables to their defaults. (See the below Environment Variable section for more information)
·      Change Active Boot Selection
      This allows the default (highlighted) Multiboot menu item to be changed.
·      Add/Delete Boot Selection
      This allows selections to add or removed from the built in Multiboot menu.
·      Change Environment Variable
      For more information on the environment variables that can be set through this option, see the below Environment Variable section.
·      Set CMOS Time
      This can be used to change the system time.
·      Set Ethernet Address
      This can be used to change the Ethernet Address for the built in Ethernet card.
·      Exit
Environment Variables
The following are the environment variables necessary to boot Windows NT on an ARC based system:
      This is the name for the boot selection that the built in Multiboot loader menu will display.
      This is an ARC pathname (for more information on ARC style pathnames, refer to Q93373 in the Knowledge base) to the system partition. By default, this will be: scsi()disk(0)rdisk()partition(1).
      This is an ARC pathname to OSLOADER.EXE, by default this will be: scsi()disk(0)rdisk()partition(1)\OS\NT\OSLOADER.EXE
      Once again, this is an ARC pathname to the partition containing the Windows NT Kernel (NTOSKRNL.EXE). By default, this will be: scsi()disk(X)rdisk()partition(Y), where X is the drive number and Y is the partition number where Windows NT is installed.
      This is the path on the OSLOADPARTITION to the Windows NT Kernel (NTOSKRNL.EXE). By default, this is: \<winnt root>\system32\NTOSKRNL.EXE
      This variable specifies any Windows NT boot parameters. This variable can be either DEBUG or NODEBUG.
Other Important Environment Variables
      This is used to specify the system's input device, and by default should be: multi()key()keyboard.
      This is used to specify the system's output device, and should be: multi()video()monitor().
      This is used to specify whether or not the built in Multiboot menu will automatically load. By default it is set to: YES, which will start Multiboot.
      This variable specifies the timezone that the system is in.
·      A:
      This is an ARC path to the A: floppy drive, and by default is: multi()disk()fdisk(0).
·      CD:
      This is an ARC path to the CD-ROM drive, and by default is: scsi()cdrom(2)fdisk().
When the system is booted, if the following message appears on the screen
then the system does not have the correct ARC firmware and the system's PROM will have to updated. The necessary software can be obtained from the systems manufacturer.
In order to update the PROM, once the correct software is obtained, the update floppy disk must be inserted in the drive and the system MUST be cold booted. Using CTRL+ALT+DEL or the Reset button will not work, the to update the PROM the system needs to be cold booted.
Typically, the PROM update software will have the following menu selections:
·      Program ARC PROM
      This option permits the following: uploading the ARC system to firmware, selection of the video mode, selection of the floppy drive size, and allows for the Enabling/Disabling of the AutoBoot functionality.
·      Program RISC/os PROM
      This option is for UNIX configuration purposes and uploads the SASh system to firmware.
·      Probe SCSI Bus
      This option is essentially a SCSI diagnostics utility and will allow the following: display the SCSI devices currently recognized or display the SCSI ID of each device.
Upgrading from a Previous Operating System
When upgrading an MS-DOS based system, the Windows NT Setup program will install the Windows NT Boot Loader to let the user choose which operating system to use each time the system is started.
Windows 3.x for MS-DOS
It is possible to install Windows NT to the same directory as an existing version of Windows 3.x. Windows NT places its system files in a \<windows root>\SYSTEM32 directory. The Windows NT Setup program also places some files that can be used with any version of Windows, such as *.BMP files, in the \<windows root> directory.
If the choice is made to not install Windows NT into the same directory as Windows 3.x, the Windows 3.x Program Manager groups will not be available under Windows NT. If Windows NT is installed in the same directory as Windows 3.x, the Setup process will import the Windows 3.x program groups into Windows NT.
Also, there are dependencies that Windows 3.x applications have installed in Windows 3.x that will not be available under Windows NT. OLE (Object Linking and Embedding) and DDE (Dynamic Data Exchange) applications will not know how to edit or play objects embedded or linked in applications under Windows NT. The information necessary for this, is stored in the registry of the version of Windows that the application is installed under. In this case, the necessary information is in the Windows 3.1 registry (REG.DAT), not the Windows NT Registry. For much the same reason, the component OLE server and client DLL (Dynamic Link Library) files will most likely not be found. The problem of the files not being found can be worked around by including the Windows 3.x directory in the Windows NT PATH.
If Windows NT is installed into a directory other than the Windows 3.x directory and OLE and DDE support is desired, the only solution is to re-install all of the Windows 3.x applications under Windows NT. It is important to reinstall the applications into the same directory (on top of themselves), since this will typically only reinstall the necessary OLE and DDE information and files in the Windows NT directory.
Migration of Windows 3.x configuration data to Windows NT
When Windows NT is installed on top of Windows 3.x, *.INI file data, *.GRP file data, and REG.DAT data is migrated into the Windows NT environment. Currently the migration process is one way only, from Windows 3.x to Windows NT, and happens only the first time that a user name logs in after Setup. By the time Windows NT ships, the ability to go back, as well as incrementally migrate future changes from Windows 3.x to Windows NT with each login should be added. There are actually two stages in which this migration occurs.
Stage One
When WINLOGON.EXE starts the first time after Windows NT has been installed over Windows 3.x, the REG.DAT and those portions of the WIN.INI that are mapped to the Registry SOFTWARE hive are migrated into the Windows NT Registry. This includes the following:
·      All of the Object Linking and Embedding (OLE) information stored in the Windows 3.1 Registry (REG.DAT). This information is stored in the Windows NT Registry under HKEY_CLASSES_ROOT.
·      The following sections and variables from the Windows 3.x WIN.INI are migrated:
      If any errors occur during the migration process, they will be logged in the Event Viewer's Application log.
Stage Two
This portion of the migration process occurs the first time every new username logs onto a Windows NT system that has been installed over Windows 3.x. However, the "Administrator" and "System" user names are exempt from the migration and will never start a migration. For all other user names, the migration occurs just once, the first time that user name is used to log on to the system. This portion of the migration process begins with a dialog box being displayed to allow the user to select which parts of the Windows 3.x configuration, if any, to migrate: the *.INI files and /or the *.GRP files. If Cancel is clicked, the migration will not occur and the next time that user name logs on, they will again be asked what portions to migrate. Clicking on OK will begin the migration process, however if both *.INI and *.GRP files were deselected nothing will be migrated and the user will not be asked again.
·      The following sections and variables from the WIN.INI are migrated during this stage:
·      The following sections and variables from the SYSTEM.INI are migrated during this stage:

·      The following sections and variables from the CONTROL.INI are migrated during this stage:
      [Color Schemes]
      [Custom Colors]
      [Screen Saver.Marquee]
      [Screen Saver.Mystify]
      [Screen Saver.Stars]
·      All sections and variables from WINFILE.INI are migrated during this stage.
·      All of the Windows 3.x Program Manager group files, as identified by the list of groups in the PROGMAN.INI file, are migrated during this stage. If the name of the group, as contained within the *.GRP file and not the *.GRP filename, is the same as the name of a Windows NT Personal OR Common group, then the group will NOT be migrated. Therefore, the Main, Accessories, Games, and Startup groups will not be migrated, unless their names have been changed, since these groups exist in Windows NT.
      The groups are migrated as is, except the show state of each group is set to Minimized and the device dependent bits for each icon are converted to device independent format. Specifically, the location of each icon, and the location of each group windows when the icon is opened will remain the same. This may cause some problems if Windows 3.x and Windows NT are using different resolutions.
      Once again, if any errors occur during this stage of the migration process they will be logged in the Event Viewer's Application log.
Items that are NOT Migrated
The following information is NOT migrated, because it would be complicated and potentially cause problems:
·      [Ports], [Devices], and [PrinterPorts] sections of WIN.INI. These are actually migrated during Stage One of the migration process to keep Windows 3.x applications happy, but Windows NT ignores them.
·      Persistent shares and users from Windows for Workgroups.
·      Default domain and user ID from Windows for Workgroups or the LANMAN.INI.
·      Per user profiles maintained by WINLOGIN.
·      Any changes the user has made to their "Main", "Startup", "Games", and "Accessories" groups in Windows 3.x.
·      MS-DOS drive letters. Drive letters should be configured using Windows NT Disk Administrator.
·      The Program Manager "Auto Arrange", "Minimize on Run", and "Save Settings on Exit" options from PROGMAN.INI are not migrated because the Windows NT Program Manager stores these in the Registry as REG_DWORD instead of as text strings.
·      Font information for character mode command windows.
Potential Problems
Some icons that have been migrated may appear as black "blobs" under Windows NT. To correct this, editing the properties of the icon and clicking OK should restore the icon to the correct image. This is apparently caused by device dependent icon bitmaps that use multiple planes instead of multiple bits per pixel.
It is possible for Windows NT, MS-DOS, and OS/2 to peacefully coexist on one system.
OS/2 1.x
It is possible to create a system that will boot either Windows NT, MS-DOS, or OS/2 1.x by using OS/2 1.x's BOOT utility and following the steps below:
 1.      The first step in setting this up is to make sure the system is currently booted under MS-DOS. If there is any doubt, using the command boot /dos will boot MS-DOS.
 2.      Run the Windows NT setup program, which will configure Boot Loader for Windows NT and MS-DOS.
Once this has been done, booting Windows NT or MS-DOS is simply a matter of selecting the correct choice from the Boot Loader menu. To boot OS/2, select MS-DOS from Boot Loader, and then use the command boot /os2. When Windows NT or MS-DOS is once again desired, simply use the boot /dos command and this will bring back the Boot Loader menu.
OS/2 2.0 Boot Manager
It is possible to use OS/2 2.0's Boot Manager to boot OS/2 2.0, as well as Windows NT Boot Loader to boot Windows NT and MS-DOS. The Windows NT Setup program recognizes an OS/2 2.0 Boot Manager partition, but does not attempt to participate in the Boot Manager scheme. Instead, the partition where Windows NT is installed is made the active partition and Windows NT Boot Loader starts automatically. However, it is possible to switch between Windows NT and OS/2 2.0.
To switch between Windows NT Boot Loader and OS/2 2.0 Boot Manager, the partition of the desired boot menu must be marked active. For example, to use OS/2 2.0 after installing Windows NT, the Boot Manager partition must be set active and the system rebooted.
In order to accomplish this, the Windows NT Disk Manager can be used to mark the Boot Manager partition as active. To return to the Windows NT Boot Loader, an OS/2 2.0 tool, such as FDISKPM, must be used to mark the Windows NT partition as active.
Windows NT
Currently, Windows NT can be installed on top of itself, if so desired.
Note   It is not recommended to do this when installing Beta 2 on a system that already has Beta 1.
Refer to the Windows NT System Guide, Chapter 18 (or Windows NT Advanced Server System Guide, Chapter 20) - Installing Windows NT for more information.
*.INF files used by Setup
(Functionally the equivalent of the Windows 3.1 SETUP.INF.)
·      SETUP.INF
*.INF File Formats
This is file is functionally equivalent to the Windows 3.x SETUP.INF file. The TXTSETUP.INF contains the following sections:
This section contains the source disks that Windows NT, or Windows NT Advanced Server, will be installed from. When installing from a CD-ROM, or over the network, there will only be two entries in this section.
This section contains information on what product is being installed, as well as install requirements.
Entries in this section can be changed in order have the Setup program send Debug information to one of the system's com ports.
This section contains the directories relative to the directory chosen by the user for the Windows NT installation and are used to specify the directory files the various files are installed in. Entries in this section are of the format:      <shortname> = <directory>, where <directory> must not start or end with \, unless it is the root directory.
This section contains a list of files that will be deleted if they are present in the target Windows NT installation directory structure. These entries are of the format: <shortname>,filename. The <shortname> entry corresponds to the entries in the [WinntDirectories] section above.
This section is only used on x86 based systems and is the root directory of the active partition. This entry has the same format as the [WinntDirectories] entries: <shortname> = <directory>.
Once again, this section is only used on x86 based systems, and specifies the files that will be deleted if present in c:\. These entries are of the format: <shortname>,filename. The <shortname> entry corresponds to the entries in the [BootDirectories] section above.
This section lists the Installable File Systems that Setup will install on the system.
This section is used when a WINNT.EXE Setup is performed after the system has rebooted with the Setup boot floppy and has started moving files around on the local hard drive. If a file is listed in this section, the file deletion is suppressed. The format of the entries in this section is: <filename>=xx, where xx must be present, but can be anything.
[Map.Computer] and [Computer]
These sections contain the information regarding the computer type selections that Setup allows. In addition, these sections define the shortname used by Setup to refer to the computer type in other sections.
[Map.Display] and [Display]
These sections contain the information regarding the display type selections that Setup allows. In the [Display] section the entries are of the format:
<string> = "Setup selection", <TXTSETUP.INF section for the files to be copied>,       <shortname>, Xresolution, Yresolution, bits per pel, vrefresh, interlaced
If the interlaced entry is -1, it is non-interlaced.
[Map.Mouse] and [Mouse]
These sections contain the information regarding the mouse selections that Setup allows. The format of the entries in the [Mouse] section is:
<shortname> = "Setup selection", <TXTSETUP.INF section for the files to be copied>, <type>
This section is referred to when Setup does not need to copy any special files to support a piece of hardware.
[Map.Keyboard] and [Keyboard]
These sections contain the information regarding the keyboard selections that Setup allows. The format of the entries in the [Keyboard] section is:
<shortname> = "Setup selection", <TXTSETUP.INF section for the files to be copied>, <type>
These sections contain the Setup information for the various SCSI adapters that Windows NT supports. The entries in these sections have the format:
<shortname> = "Setup selection", <TXTSETUP.INF section for the files to be copied>,       <shortname>, <shortname from the [WinntDirectories] section>
[SCSI.ISA.Load], [SCSI.EISA.Load], and [SCSI.MCA.Load]
These sections contain the load information for the various SCSI adapters that Windows NT supports. The entries in these sections have the format of:
<short disk name>,<shortname>
["Keyboard Layout"]
The entries in this section specify the shortname and the Setup selection for the Setup keyboard layout option. These entries have the form: <shortname> = "Setup selection"
This section is used to install the Windows NT Boot Loader, boot sector on the various file systems. These entries have the format:
<file system> = <short disk name>, <filename>, <boot sector size>
The rest of the TXTSETUP.INF
Most of the rest of the entries in the TXTSETUP.INF file specify the files that need to be copied to support a specific hardware component. The section headings are of the form: [<shortname>] or [files.<shortname>]. The format of the entries in these sections is of the form:
<short disk name>, <filename>, <short [WinntDirectories] name>, <filename to rename the file       to>
If the line ends in "", the file will retain the same name. For example, the entry: d2,haltest.dll,2,hal.dll - will copy haltest.dll from the second disk to directory number 2 (specified in [WinntDirectories] section) as hal.dll.
The exceptions to the above are the following sections: [Files.KeyboardLayout], [IFSDLL], [Kernel], [MiscFiles], [ntdetect]. The entries in these sections all use the following formats: <shortname> = <short disk name>, <filename>, <short [WinntDirectories] name>, <filename to rename the file to>
This file is used by Original Equipment Manufacturers (OEMs) to install the correct files and Registry entries for their hardware devices. This file uses the hash (#) character to introduce comments. All strings with embedded spaces, commas, or hashes should be double-quoted, such as "Bill and Ted's Excellent Video Card".
This file uses the general format of :
[section name]
key = value1, value2, .......

and contains the following sections:
# This section lists all of the disks in the disk set.
# <description> is a descriptive name for a disk, used when prompting for a specific disk.
# <tagfile> is a file whose presence allows setup to recognize that the correct disk is inserted.
# <directory> is where the files are located on the disk.

d1 = <description>,<tagfile>,<directory>
d2 = <description>,<tagfile>,<directory>

# This section lists the default selection for each 'required' hardware component. If a line is not present for
# a component, the default becomes the first item in the [<component_name>] section (see below).
# <component_name> is one of computer, display, keyboard, mouse, SCSI
# <id> is a unique <within the component> string to be associated with an option.

<component_name> = <id>

# This section lists the options available for a particular component.
# <id> is the unique string for the option
# <description> is a text string, presented to the user in a menu
# <key_name> gives the name of the key to be created for the component in
#      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

<id> = <description>,<key_name>

# This section lists the files that should be copied if the user selects a particular component option.
# <file_type> is one of driver, port, class, DLL, hal, inf, or detect (See below for more information).
# <source_disk> identifies where the files are to be copied from, and must match an entry in the [Disks]
#      section.
# <filename> is the name of the file. This is appended to the directory specified for the disk in the [Disks]
#      section to form the full path of the file on the disk.

<file_type> = <source_disk>,<filename>

# This section specifies values to be set in the registry for particular component options.  Required values
# in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\xxx key are created
# automatically. This section is used to specify additional keys to be created in .....\Services\xxx and values
# in ......\Services\xxx and Services\xxx\yyy.
# <key_name> is relative to the services node for this device. If it is empty, then it refers to the services
#      node. If specified, the key is created first.
# <value_name> specifies the value to be set within the key
# <value_type> is a string, such as REG_DWORD. (See the Registry Terms section below for more
#      information on the possible <value_type>s)
# <value> specifies the actual value; its format depends on <value_type>

value = <key_name>,<value_name>,<value_type>,<value>...

The <file_type>s in the [Files.<component_name>.<id>] section
·      Driver
      This is a valid type for all components, and the file is copied to <winnt root>\system32\drivers.
·      Port
      This is a valid type for keyboard, mouse, and SCSI components and allows for a distinction between port and class drivers, but is equivalent to driver type. This file is copied to <winnt root>\system32\drivers.
·      Class
      This is a valid type for keyboard and mouse components. If specified, this replaces the standard class driver. This file is copied to <winnt root>\system32\drivers.
·      DLL
      This is a valid type for all components and is particularly useful for the GDI portion of a display driver. This file is copied to <winnt root>\system32.
·      Hal
      This is a valid type only for computer component. On x86 based systems, this file is copied to <winnt root>\system32\hal.dll. On ARC compliant systems, this file is copied to \os\nt\hal.dll on the system partition.
·      INF
      This is a valid type for all components and is used to copy a GUI inf file for use with system maintenance setup. This file is copied to <winnt root>\system32.
·      Detect
      This type is valid only on x86 based systems for the computer component. If specified, this replaces the standard x86 hardware recognizer (NTDETECT.COM). This file is copied to c:\ntdetect.com.
Windows NT Setup Issues
SCSI Devices
When using a SCSI CD-ROM device, it is important to ensure that the device does not have an ID of 0 or 1. Some SCSI BIOS programs reserve 0 and 1 for hard disks only. If the CD-ROM has an ID of 0 or 1 and these are reserved for hard drives, there will likely be an extra partition in Setup that does not, in reality exist.
No memory at 1 MB
This will cause a problem because the x86 version of NTOSKRNL.EXE (which is discussed in detail below) has no relocation information, and thus must always be loaded at a fixed address. This address happens to be 1 MB and therefore NTOSKRNL.EXE can not be loaded. On systems that do not have any memory at 1 MB, the following error will occur when Windows NT attempts to boot:
Loading file multi(0)disk(0)rdisk(0)partition(1)\winnt\system32\ntoskrnl.exe
OS LOADER:  Image can't be relocated, no fixup information.
The system did not load because it cannot find the following file:
<winnt root>\system32\ntoskrnl.exe
Please re-install a copy of the above file.
Boot failed

This error will occur on any x86 based system that does not have any memory at 1 MB. It has been seen most often on some Compaq SystemPro XLs. To correct it on a SystemPro XL, it is necessary to change the EISA configuration memory parameter from 'Linear' to '640K Compaq Compatible'.
Lab Exercise
Installing Windows NT
The Windows NT Registry
The Windows NT Registry Editor (REGEDT32.EXE) is the tool that permits viewing and manipulation of the Windows NT Registry. However, to make a change to a value in the Registry, the appropriate user interface tool should ALWAYS be used.
Registry Information
The Registry data is collected from the following sources:
·      The Windows NT Setup program.
·      The Windows NT x86 hardware detection program (NTDETECT.COM), or on ARC compliant systems, the POST routine.
·      Hardware, Software, and their installation software.
·      The Windows NT applets.
The Windows NT Registry is designed to hold all the configuration information for Windows NT and any installed applications. However, an artificial limit of 1 megabyte is imposed on the amount of data that can be stored in the data field of a Value entry. If more than 1 megabyte of data needs to be stored, it is recommended that the data be stored in a separate file and a Registry entry created that points to the file.
Note   Because the Registry is designed to hold small objects, this is an artificial limitation that was imposed to prevent Registry abuse.
In the first release of Windows NT, the total size of the Registry is limited to 32 Megabytes.
Registry Terms
The Windows NT Registry appears very much like a hierarchical file system, in that each node (referred to as a Key) is analogous to a directory, and the Values stored within each node, or Key are analogous to files. Each Key in the Registry can also contain Sub-Keys, in addition to any Values that it may contain. The Registry consists of four Predefined Key Handles: HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, which will be talked about in more detail later in this section.
Each Registry key has both a fixed part and two variable parts. The fixed part of a key consists of the key's name, class, security descriptor, and time stamp. The two variables parts of a key, are the key's list of sub-keys and the key's set of value entries. Each value entry in the Registry has a name, type, and data field.
The following is a listing of what the Value type field entries mean:
·      REG_DWORD
      Only one <value> is allowed, and it must be a string of 1-8 hex digits.
·      REG_SZ
      Only one <value> is allowed, and it is interpreted as the string to be stored.
      This is similar to REG_SZ, except the text can contain a replaceable variable. For example, in the string: %SystemRoot%\ntvdm.exe, %SystemRoot% would be replaced with the path to the Windows NT system32 subdirectory.
      Only one <value> is allowed, and it is a string of hex digits, each pair of which is interpreted as a byte value.
      Multiple <value>s are allowed, each <value> is interpreted as a component of the MULTI_SZ. In the below screen shot, if Sample5 were edited, Line1 Line2 Line3 Line4 Etc. Etc. would all be on separate lines in the editor.
The Registry can also be viewed as being somewhat analogous to the Windows 3.x *.INI files. When looking at the Registry in this manner, each Key can be viewed as a bracketed heading in an *.INI file and the entries under the heading would be equivalent to the Values in the Registry. The one difference between the Registry Keys and the *.INI bracketed headings is that the Registry Keys can contain Keys, or sub Keys, but the *.INI files do not support nested headings. For example, the [windows] heading from the WIN.INI contains many entries under it, such as spooler=yes, Beep=Yes, etc. In the Windows NT Registry, this would appear as:
Note   This is not an actual Registry key, but one created to illustrate this example.
Registry Hives
Physically, the Registry exists as a set of files, with the Registry being divided into sections referred to as hives. The following table shows the different Registry hives, and their corresponding files.
Hive      Physical File

HKEY_USERS\<Admin's SID>      ADMIN000
-      -
-      -
HKEY_USERS\<User's SID>      USER000
-      -
The above table shows the hives that are created when Windows NT is first installed. Each time a new user logs onto a system, additional HKEY_USERS hives will be created for that user. These files are all located in \<winnt root>\system32\config. The files in this subdirectory with the extensions of .ALT and .LOG are backups of the hive files. Should the system fail to load because the system hive has a bad sector, Windows NT will automatically switch to the SYSTEM.ALT.
The information regarding the hive files and what they map to, can also be found in the Registry under:
Registry Sharing
Since the Registry is the central location for all configuration information and Windows NT is a pre-emptive, multitasking operating system, it is reasonable to assume that more than one program may try to read and/or write to the Registry at the same time. The Registry handles this possibility by implementing a certain amount of atomicity at the key level. While a key is being edited, all other writes to that key are blocked.
A program that reads a key which has more than one Value entry is guaranteed that any given Value entry will be consistent. Therefore, the program will always read the old Value Name, Type, and Data, or the new Value Name, Type, and Data, but never some combination of old and new information.
Registry Security
Much the same as files on an NTFS volume, Registry keys can have Access Control Lists (ACLs) applied to them. ACLs can only be applied to Registry keys, not values, but the key's ACL protects all of its value entries from unauthorized modification. Therefore, it is possible to prevent users from modifying the configuration data in the Registry and by default, only Administrators can make modifications.
The following are the permissions that can be allowed for Registry keys:
      This permission specifies access to read the value, type, and last write time from a key.
·      SET VALUE
      This permission specifies access to write the value and type of a key.
      This permission specifies access to create a child subkey.
      This permission specifies access to count or name the children of a key.
·      NOTIFY
      This permission specifies access to receive notification of a change to a key.
      This permission specifies access to link one key to another key.
·      DELETE
      This permission specifies access to delete a key or any and all of it's values.
·      WRITE DAC
      This permission specifies access to add discretionary access control (DAC) information (i.e. security).
      This permission specifies access to take ownership of a key.
      This permission is standard read + QUERY VALUE + ENUMERATE SUBKEYS + NOTIFY.
This predefined handle is the root of the currently logged on user's profile and contains all of the information necessary to set up a specific user's environment. This includes such items as, program groups, screen colors, etc. There are Windows NT Advanced Server utilities that allow a user's profile to be located anywhere on the network. If for some reason the profile cannot be accessed, the system will load the .DEFAULT system profile.
The following are the default subkeys for HKEY_CURRENT_USER:
·      \Console - contains subkeys that specify the window size and options for the Windows NT command prompt.
·      \Control Panel - contains the subkeys which hold the configuration information for the Control Panel applets.
·      \Environment - contains entries for the current user's environment variables.
·      \Keyboard Layout - contains an entry for the current active keyboard layout.
·      \Printers - contains the current default printer name
·      \Program Groups - contains subkeys with the names and settings of the current user's program groups.
·      \Software - contains subkeys that describe the user configurable settings of any installed software.
The entries under HKEY_CURRENT_USER are mapped directly to HKEY_USERS\<SID of currently logged on user> . Therefore, if an entry is added under one of these, it will automatically be added to the other. This ensures that both keys contain identical entries.
This predefined handle contains the default system profile, and the profile of the currently logged on user. HKEY_USERS\<SID for currently logged on user> contains the same information as HKEY_CURRENT_USER, and as noted above they are mapped to each other. Currently, HKEY_USERS has the following two subkeys, each of which have the same subkeys as HKEY_CURRENT_USER:
·      ...\DEFAULT
      This is the profile that is used while the Windows NT CTRL+ALT+DEL logon message is displayed. Therefore, changing the color scheme under this key will change the color scheme used for the logon screens.
Note   In the final Windows NT product, it will not be necessary to modify the Registry for a screen saver to be enabled when the CTRL+ALT+DEL logon message is on the screen. By default, the logon screen will use the blank screen saver.
·      ...\<SID for currently logged on user>
      This is the profile for the currently logged on user.
This predefined handle contains information about file associations and Object Linking and Embedding (OLE). The main purpose of this key is to provide compatibility with the Windows 3.1 registration database.
Similar to the HKEY_CURRENT_USER entries, the entries under HKEY_CLASSES_ROOT are mapped directly to HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Once again, this will ensure that both keys contain identical entries.
This predefined handle is the root of the per machine configuration data, regardless of what user is logged on to the system.
This key is essentially the installed hardware database and represents the physical configuration of the machine. This includes such data as the processor type, bus type, video adapter type, which interrupts are being used, etc. This data is volatile and is re-computed each time the system is booted.
This subkey refers to the root of the hardware database built by the operating system loader during the boot process. On ARC compliant systems, this is a copy of the ARC configuration database which is extracted from the system's firmware. On x86 based systems, it is a subkey in the same format as the ARC tree, but it contains whatever data the system's Hardware Recognizer program could find. As we will see when we look at the boot process, the Hardware Recognizer is executed during the boot process and on x86 based systems is NTDETECT.COM.
Each hardware component that is detected has a set of values associated with it that store configuration data for that component:
·      Component Information - contains binary data that identifies among other things, version information.
·      Identifier - contains the identifier of a component, if specified.
·      Configuration Data - contains the component specific information, such as I/O port addresses, IRQ number, etc. This entry will not be present if the data is not available for a particular component.
This subkey contains additional subkeys that list the device drivers which need to communicate the names of the device objects they have created, along with certain properties of those device objects to other device drivers, and to user mode code. For example, video drivers need to communicate to the Windows NT USER component which type of video hardware is associated with which device object, and what user-mode display DLL should be bound to it. The \Devicemap subkey offers a solution to this problem. \Devicemap contains the device class specific data used by user-mode software that needs to communicate with the device.
This key is used to track which hardware resources are in use, and by which drivers. The data stored under this key is volatile and is therefore recreated each time the system is booted. All device drivers are expected to report their use of I/O ports, memory addresses, interrupt vectors, and statically allocated DMA channels. This allows Windows NT to detect and report conflicts, in order to guide the installation and configuration of new devices and drivers.
This key contains the Security Account Manager database, which contains user and group account information for the local system if it is a Windows NT system. On the other hand, if the system is using Windows NT Advanced Server, this key contains information for the domain. Currently, this key is mapped to HKEY_LOCAL_MACHINE\SECURITY\SAM.
This key holds all of the security information for the local computer. It is NOT possible to modify any of the \SECURITY subkeys, even if logged on as Administrator.
This key contains the per-machine software data. In other words, this key contains the configuration information about the software installed on the local system. This information applies to all users of the system and is written to the Registry when a piece of software is installed on the system. By querying this key, it is possible to determine what software is installed on a system. There is even a convention for how information should be stored under this key:
      \<Company Name>
            \<Product Name>
                  \<Version Number>
For example, Excel would create the following:
Information regarding the configuration of the application is stored on a per-user basis under:
            \<Company Name>
                  \<Product Name>
                        \<Version Number>
This information is written to the Registry at application runtime, since the user who installed the software may not necessarily be the user of the application.
As was discussed under HKEY_CLASSES_ROOT, this subkey is mapped to HKEY_CLASSES_ROOT and contains file association and OLE information.
This subkey also contains description information about the installed applications, as discussed above.
This subkey contains the common program groups on the system, individual user groups are stored under HKEY_CURRENT_USER. The value of each of this subkeys is binary data describing the group.
The most important section of the Registry for the boot process is the HKEY_LOCAL_MACHINE\SYSTEM section. The data stored under this key is organized into what are called control sets.
Windows NT ControlSets
A control set can be thought of simply as an instance of system parameters. Under HKEY_LOCAL_MACHINE\SYSTEM there will be four ControlSets:
·      ...\Clone
      This is a volatile copy of the ControlSet the system booted from (CurrentControlSet). This key is made during the Kernel Initialization phase (discussed in detail later in this module) of the boot sequence and is used by the Service Controller (SCREG.EXE).
·      ...\ControlSet001
      This is the primary ControlSet and is used, by default, to boot Windows NT from.
·      ...\ControlSet002
      This is a backup ControlSet that can be used in the case of ...\ControlSet001 failing to boot the system.
·      ...\CurrentControlSet
      This is the ControlSet that Windows NT is booting from. Typically it will be mapped to ...\ControlSet0001.
      Each of these ControlSets consists of two subkeys: ...\Control and ...\Services.
This subkey, holds all of the miscellaneous information necessary to boot Windows NT, such as paging file size, location, etc.
Since the information under the \Services subkey is contained in a series of more subkeys, no assumptions can be made about the order in which they will appear in an enumeration. Therefore, there is explicit control of load ordering, under the \Control subkey. The two \Control subkeys that specify how to interpret the \Services list are:
This subkey contains a value called "list", which is a list of groups in the order in which they are to be loaded. For example, we have to load the disk driver before we can load the file system
This subkey contains a value entry per load Group (discussed more below), each of which list the Tag values (discussed more below) in the order they are to be loaded.
This subkey contains all of the kernel device drivers, file system drivers, and Win32 service drivers that can be loaded, as well as if and when they are to be loaded. The \Services subkey has the following format:

      \<entry name> (typically the driver name)
            Value Entries: Type, Start, ErrorControl, Group, Tag, DependOnGroup
            Value Entries: any arbitrary data the driver writer wants to store

Each of the subkeys under ...\Services can have all or some of the following value entries, which control the behavior of the service:
Type values
Each subkey in the ...\Services part of the Windows NT Registry has a Type value. As the name implies, this identifies the type of service provided by the associated entry. The following table shows what the five Type values are and the kind of service provided by each type.
Type Value      Service Provided

0x1      Kernel drivers
0x2      File System drivers
0x4      Adapters
0x10      Win32 Services (that do NOT share processes)
0x20      Win32 Services (that do share processes)
Subkeys with a Type of 0x4 (Adapter) contain a set of arguments for a piece of hardware.
Start values
Each ...\Service subkey also has a Start value associated with it. This value determines at what point, if any, the item is loaded and initialized during the boot process (discussed in more detail in the next section).
Value      Starts at

0      Boot - Kernel load
0x1      System - Kernel initialization
0x2      Auto - Win32 subsystem start
0x3      Demand - can be loaded by user
0x4      Disabled - never loaded
Note   Start values are ignored for type=Adapter (type 0x4) items. For type=Service (type 0x10 or 0x20) items, the start value must be either Auto, Demand, or Disabled.
Group values
Group values allow services to be loaded in an order related to the type of service that they are. As we saw in the earlier discussion of ...\ControlSetxxx\Control, the group order is defined under:
Tag values
This value specifies an explicit load order for the services, within a group.
ErrorControl values
This value determines what happens if the driver being loaded, does not load or initialize properly. There are three different ErrorControl levels:
·      0x1 - "Normal"
      If this occurs, the boot process should ignore the error and proceed.
·      0x2 - "Severe"
      If the current boot is not based on the LastKnownGood, the boot process should fail and restart using the LastKnownGood. If the boot process is using the LastKnownGood, the error should be ignored and the boot process should continue.
·      0x3 - "Critical"
      A "critical" error is very much like a "severe", in that it switches to the LastKnownGood if not using it. However, if the LastKnownGood is being used, the boot process will fail and an error message will be displayed.
Note   Most device drivers have an ErrorControl value of 0x1 ("normal").
ImagePath values
This value entry specifies the items path name. The default for a driver is <winnt root>\System32 \Drivers\<drivername>.SYS and for a service is <winnt root>\System32\<servicename>.EXE. This entry is ignored for items of the adapters type.
ObjectName value
This value entry specifies an object name. If the service type is a Win32 Service, then this is the account name the service will use to log itself on when the service is run. If the service type is Kernel or file system driver, this name is the Windows NT driver object name, which the I/O Manager uses to load the device driver. The default for this key is <subkeyname>.
DependOnService and DependOnGroup value
This value entry specifies zero or more service keynames (DependOnService) or group names (DependOnGroup), the default being empty. Dependencies all subkeys to be loaded in an order related to other particular subkeys they are closely associated with. For example, the Nbf transport depends on an NDIS driver being loaded. That is, in order for the Nbf protocol stack to load successfully, an NDIS network card driver must have first been loaded.
Under the \Select subkey, there are four entries which tell the boot process which ControlSet of drivers and services should be loaded.
The four entries are:
·      Current. This is the value of the ControlSet that Windows NT is currently using.
·      Default. Unless told otherwise, NTOSKRNL.EXE uses the ControlSet pointed to by the Default value.
·      LastKnownGood. This is the value of the ControlSet that last successfully booted Windows NT. LastKnownGood is covered in more detail in the Windows NT Overview section of this course.
·      Failed. This is the value of the last ControlSet that was unable to boot Windows NT. This value will be 0 (zero) if Windows NT has never failed during the boot sequence.
      The value of the above entries is expanded into a three digit number and added to "ControlSet", to determine which ControlSet is used. Therefore, if Default has a value of 0x1, Default is referring to ControlSet001.
This subkey contains information used by the Windows NT Setup program.
Control Panel Applets
The Control Panel Services Applet displays the status and startup time for all of the Services located under:
In addition, there is a Control Panel Devices Applet. This Applet displays the status and startup time for all device drivers and file systems found under:
Both of these Applets allow for the starting and stopping of the items shown, as well as allowing the startup time to be configured. Both of these Applets are contained in SRVMGR.CPL, along with the Server Applet. It is recommended that these Applets be used in place of editing the Registry, via REGEDT32.EXE, whenever possible.
Where to find the Windows 3.1 *.INI entries in the Registry
                  \Windows NT
are keys for each of the standard Windows 3.x *.INI files. Under each of the keys for the *.INI files are entries for each of the standard headings in these files. These heading entries each contain a string that points to the location in the Windows NT Registry where the items that were under these headings in Windows 3.x can be found. Each of these entries begin with either SYS or USR:
      SYS can be found under HKEY_LOCAL_MACHINE\SOFTWARE
      USR can be found under HKEY_CURRENT_USER
Based on this, to find the Patterns entry that was in the CONTROL.INI under Windows 3.x, look in the Registry under:
                  \Windows NT
In the Registry, this key has a Value for Patterns of: USR:Contol Panel\Patterns. This translates into a location of:HKEY_CURRENT_USER\Control Panel\Patterns, for determining what the current, and possible, patterns are on the system.
It is important to be aware that many entries can be found in more than one location within the Registry. However, when there are entries in multiple locations, the keys are "mapped" to one another. This means that when one key is changed, any keys "mapped" to it will automatically be updated as well, and vice versa.
Boot Sequence Details
Windows NT boots in a number of stages. Some stages are specific to Windows NT and some are common to Intel and ARC based systems, such as the POST routine. First, we will look at the specifics of the boot process on each platform and then take a look at the platform independent portion of the Windows NT boot sequence.
The Intel Boot Process
When an Intel based machine is powered on, the CPU is set to run in real memory mode (segments and offsets) and the instruction pointer is positioned at 0xffff:0x0000. This is the beginning of the Power on Self Test (POST) routine. The POST routine is responsible for determining the amount of memory, if required hardware components are present, such as a keyboard, and allowing adapter cards to initialize. The information that appears on the screen at this point is determined by the developer of the system's ROM, and the manufacturers of any installed adapter cards. Typically, the POST routine can be identified by an on screen count up of the memory installed in the system. Once the system has executed its POST routine, any installed adapter cards are permitted to run their POST routines.
At the end of the POST routine process, the CPU is instructed to process any commands at software interrupt nineteen hex (19h). This is the reboot computer interrupt. This routine attempts to locate the boot device, by first checking drive A: and if no disk is found in drive A: the hard disk C: is checked.
To determine if drive C: is a boot device is really a two step process.
·      The first sector of the hard disk contains the Master Boot Record (MBR), which is loaded into memory. The MBR contains a program which is executed.
·      This program scans the partition table (the remaining portion of the MBR) to locate the "active partition" in the partition table. The "active partition" is determined by a flag in the partition table.
Next, the "boot record" for the active partition is loaded into memory. The boot record starts at the first logical sector in the active partition. On a FAT formatted partition the boot record is only one sector long, and on an HPFS formatted partition the boot record is sixteen sectors long. The program located in the boot record loads the first layer of the program necessary to start the operating system. When Windows NT is installed, the boot record is changed to support the booting of the Windows NT operating system.
Note   The boot record on the system is saved as BOOTSECT.DOS (discussed further below), regardless of what operating system was installed on the system prior to the installation of Windows NT.
If for some reason no active partition is found on the C: drive, processing will pass to the ROM BASIC software interrupt, INT 18 hex. It is very rare that any clone systems will actually have ROM BASIC at this location, however this hook is still useful. In remote boot situations, where the operating system image is loaded from a server, this interrupt is redirected to the ROM on the network adapter card by the POST routine on the network card.
Note   Windows NT does not currently support being remote booted.
This is the point at which the boot process starts to differ from the way in which the system would boot if only the MS-DOS operating system were installed. At this stage in the boot process, under MS-DOS the program located in the boot record would load IO.SYS into RAM at 700h and then MSDOS.SYS and pass control to the SYSINIT portion of IO.SYS.
As noted above, during installation Windows NT replaces the boot record. The new boot record is instructed to find, load into memory, and execute NTLDR, which MUST be located in the root directory of drive C:.
It is possible to tell when NTLDR starts executing, because the screen will be cleared and the following message will be briefly displayed:
Windows NT
Portable Boot Loader
NTLDR initializes the video hardware, by making a BIOS call to set the video card in 80x25 16 color alphanumeric mode, clears the screen, and then displays the above boot message.
NTLDR is used to control the Boot Loader Operating System selection process and requires NTDETECT.COM, BOOT.INI, and BOOTSECT.DOS to be in the root directory of the boot drive. In addition, if the drive the system is booting from is a SCSI drive, the file NTBOOTDD.SYS must also be in the root directory. NTBOOTDD.SYS is created during Setup (if the boot drive is a SCSI device), by making a copy of the appropriate SCSI driver in the root directory, and naming the driver NTBOOTDD.SYS.
Once NTLDR is started, it proceeds through the following steps:
·      Switches the processor into 32 bit flat model mode
·      Starts the appropriate mini file system
·      Reads the BOOT.INI and displays the operating system selections
·      Allows the user to select an operating system
·      Loads the correct operating system
·      Executes NTDETECT.COM
The 32 bit flat model
The first task performed by NTLDR is switching the processor into 32 bit flat model mode. When Intel computers first boot, they are running in real mode, like an old 8088 or 8086 processor. Because NTLDR is mostly a 32 bit program it must switch the processor into 32 bit flat model mode before it can perform the rest of its functions.
The mini file system
During this portion of the boot sequence, NTLDR loads a small version, with limited functionality, of the file systems in use on the system. NTLDR supports FAT, HPFS, and NTFS. The mini file systems are contained within NTLDR, and allow NTLDR to access files as well as change directories on the boot drive.
The following is a sample BOOT.INI file:
[Boot Loader]
[operating systems]
scsi(0)disk(0)rdisk(0)partition(1)\nt = "Windows NT (from c:\nt)" /NODEBUG
c:\ = "MS-DOS"

The entries in the [Boot Loader] section contain the following information:
·      timeout= is the number of seconds before the default operating system automatically starts.
·      default= is the path of the default operating system.
The entries in the [operating systems] section have the format of:
      <path> = "<menu option>" [optional parameters]
Where the <path> is the path to the operating system and "<menu option>" is the choice displayed on the Boot Loader menu screen. Any necessary optional parameters can be added to the ends of these lines, as shown in the sample BOOT.INI above.
In order to determine what, if any, selection other than Windows NT will appear in the NTLDR menu, Setup searches the boot drive for certain files. If MSDOS.SYS or IBMDOS.COM are found, then MS-DOS or PC-DOS becomes the alternate the selection. If OS2 is found, then OS/2 will be the menu item for the other operating system.
Note   The <path> entry for Windows NT in the BOOT.INI uses an ARC (Advanced RISC Computer) format for the pathname in order to emulate the internal pathnames on RISC systems. For more information on this type of path, see Q93373 in the Knowledge base.
The BOOT.INI is a standard text file and can be edited using any text editor. However, the BOOT.INI is marked read only, so the attribute will have to be changed before editing the file. In addition, by using the Control Panel, System applet it is possible to change the timeout= and default= values in the BOOT.INI.
Loading the Operating System
If MS-DOS, OS/2 1.x, or OS/2 2.0 is selected from the NTLDR menu, NTLDR loads the hidden file, BOOTSECT.DOS into memory at location 700h. NTLDR then switches the processor back to real mode and jumps to the start of the boot sector program contained in BOOTSECT.DOS. From this point on, the boot sequence is as it would normally be for the other operating system.
Note   NTLDR currently supports loading multiple versions of Windows NT and ONE other operating system.
If Windows NT is selected, NTLDR then executes NTDETECT.COM.
NTDETECT.COM collects information on the hardware components installed in the machine. It then builds a list of these components and returns this information to NTLDR. Currently, the following information can be detected by NTDETECT.COM:
Information      Example Registry Entry

Machine ID      AT/AT Compatible
Bus/Adapter Type      ISA
Video      Video7 VGA
Keyboard      PCAT_ENHANCED
Communication Port      COM1
Parallel Port      PARALLEL1
Floppy      Floppy1/Floppy2
Mouse      Microsoft Serial Mouse
Note   NTDETECT.COM is not needed on ARC machines because the needed information is provided by the ARC firmware. Therefore, it is appropriate to view NTDETECT.COM as an x86 hardware recognizer.
Currently, both the Central Processor and the Floating Point Coprocessor are detected by the Windows NT Kernel (NTOSKRNL.EXE) and the Hardware Abstraction Layer (HAL.DLL).
After NTDETECT.COM has given NTLDR the list of installed hardware, the Windows NT boot process continues in the section titled "Windows NT Load" below.
Note   If the system is not 100% PC-compatible, such as the system has more than one I/O bus or has more than one central processor, OEMs must provide their own version of NTDETECT.COM.
The ARC Based Boot Process
On ARC based systems, the resident ROM firmware will select a boot device by reading a boot precedence table from non-volatile RAM. In the case where the non-volatile RAM is not valid or blank, the firmware will either query the user for the boot device or default to a: floppy, hard disk sequence. For a hard disk boot, the firmware will read the first physical sector of the boot drive (the Master Boot Record (MBR)) and determine if a bootable partition is present. If there is a bootable partition present, the first sector of the partition will be read into memory and the BIOS Parameter Block (BPB) examined to determine whether or not the volume's file system is one that the firmware supports. If the file system is supported by the firmware, the root directory of the volume will be searched for OSLOADER.EXE, and if found will be loaded and control passed to it.
Note   If the file system is NOT supported by the firmware, the system will not be able to boot, since the ARC specification requires that the system partition always be formatted with the FAT file system.
The Boot Loader menu and functionality that is implemented by NTLDR on x86 based systems is not needed on ARC (Advanced RISC Computer) based systems. This is because ARC based systems have the NTLDR functionality built into the system firmware. Therefore, there is no need for NTLDR, the initial stages of the Windows NT load are handled by OSLOADER.EXE.
In addition, there is also no need for NTDETECT.COM on ARC based systems. The ARC POST routine collects the hardware information and OSLOADER.EXE gets the necessary information from the POST routine.
On ARC based systems, the video hardware is initialized by the Windows NT HAL (Hardware Abstraction Layer) in order to display the information regarding the boot process.
MIPS Boot Screen
Upon system power on, the machine will go through it's Power On Self Test (POST) routine and should display the following information on the screen:
Testing Memory 32768 KB...OK
Testing Memory Controller...OK
Testing Interrupt Controller...OK
Testing Keyboard Controller...OK
Testing Serial Controller...OK
Testing Parallel Controller...OK
Testing Floppy Controller...OK
Testing SCSI Controller...OK
Testing Ethernet .........OK
Testing APPR..............OK
Testing Loop..............OK
Initializing Firmware...........
Based on the information supplied by the POST routine, it is possible to tell if a particular hardware component is functioning correctly before booting Windows NT.
ARC Multiboot Screen
If the system's ARC firmware is the correct version (for more information on the ARC firmware, see the earlier section on Windows NT Setup on ARC Based Systems), the following screen should appear:
ARC Multiboot Version 248
Boot Windows NT
Boot an alternate OS
Run a program
Execute Monitor
use arrow keys to select
press enter to choose
·      Boot Windows NT
      This option allows Windows NT to be booted.
·      Boot an alternate OS
      This allows a different operating system, or another version of Windows NT, to be booted.
·      Run a program
      When this option is selected, a full ARC pathname must be specified to the executable.
·      Execute Monitor
      This executes the system monitor, which is similar to the MS-DOS Debug utility.
MIPS boot
The R4000 supports three types of resets:
·      Power-On Reset - This starts from the power supply being turned on.
·      Cold Reset - Restarts all clocks, but the power supply remains stable. The processor operating parameters do not change.
·      Warm Reset - This restarts processor, but does not affect the clocks.
Windows NT Load
The following stages occur no matter what platform Windows NT is booting on.
·      Kernel Load
·      Kernel Initialization
·      Service Load
·      Windows Start
Kernel Load
During this stage, the Windows NT kernel (NTOSKRNL.EXE) and the Hardware Abstraction Layer (HAL) are loaded into memory, but not initialized. Next a copy of the system hive, HKEY_LOCAL_MACHINE\SYSTEM, from the Registry is loaded into memory.
At this time, the Registry is scanned for drivers with a start value of 0 (zero), which indicate they should be loaded but not initialized before the kernel, and a service type value of 0x1, which indicates it is a kernel device driver. Drivers with these values are typically low level hardware device drivers, such as hard disk device drivers.
These drivers are not loaded into memory in the order found, instead their group value is first examined to sort the list. The sorting is based on the position of the Group Value in:
From this, we can see that services with a Group of "SCSI miniport" will be loaded first, followed by "port", followed by "Primary disk", followed by etc., etc.
The loading into memory of these drivers is all done using BIOS Int13 calls in real mode, or by NTBOOTDD.SYS (the Windows NT SCSI device driver for the boot device) if the boot device does not support Int13 calls (such as a SCSI drive). During this, NTLDR is switching between real mode and protected mode in order to use both Int13 and load the Executive, HAL, and drivers in "extended" (protected mode) memory.
Kernel Initialization
This stage of the boot process is signified by the screen turning blue. This is when NTOSKRNL.EXE is initialized and control is passed to it. In addition, all of the drivers that were loaded during the Kernel Load stage are initialized. If an error is encountered, action will be taken based on the drivers ErrorControl Value, which is discussed in detail in a later section. Once again, the Registry information is scanned, this time for drivers that have a 0x1 start value. Similar to the Kernel Load phase, the list is sorted according to order and the drivers are then loaded. However, unlike the previous phase, the drivers are not loaded using BIOS calls, but with the drivers that were loaded in the previous phase and just initialized. In addition, these drivers are initialized as soon as they are loaded.
During this stage, the Registry Hardware list is created using the information that was passed from NTLDR or OSLOADER.EXE, depending on the type of system. The CurrentControlSet is created by creating a link to ControlSet00x, where x is 1 or 2 as determined by checking the value of:
In addition, the Clone ControlSet is created by making a copy of the CurrentControlSet and both CurrentControlSet and Clone are initialized, but not saved yet.
After all of the drivers are successfully loaded and initialized, the NTOSKRNL.EXE performs some housecleaning by freeing memory blocks used by the device drivers.
Service Load
This stage is when Session Manager (SMSS.EXE) is started. The first thing Session Manager does after starting is it reads and executes the list of programs in:
                        \Session Manager:BootExecute
As can be seen above, the default entry is: autocheck autochk *. AUTOCHK.EXE is the boot time version of CHKDSK that automatically performs a check on each partition. If this entry is changed to read: autocheck autochk /p *, the /p will force the equivalent of a CHKDSK /F on each partition on every subsequent restart of the system. Since the BootExecute value is a REG_MULTI_SZ, BootExecute can have more than one entry under it. Therefore, you could add a second line such as: autocheck autochk /p \DosDevices\c:, to have AUTOCHK.EXE perform the equivalent of CHKDSK /F on drive c: for each restart of the system. If a drive has been set to be converted to NTFS on the next system boot, the following entry will be added to ...\SessionManager\BootExecute: autocheck autoconv \DosDevices\x: /FS:ntfs.
Once the check disk information starts displaying on the blue screen, it is a clear indication that Session Manager has started. Of course, if this information does not appear it is possible that the autocheck line was removed from the BootExecute Registry entry.
After all of the checks have been successfully performed on the system's hard drives, Session Manager will set up the Pagefiles defined under:
                  \Session Manager
                        \Memory Management
Note   As can be seen above, Windows NT supports multiple pagefiles, up to 16, which for maximum performance should be located on separate physical drives.
Next, since the partitions are now checked and the paging files are setup the CurrentControlSet and the Clone ControlSet are written to the Registry. The next to occur are the creation of symbolic links. These links are used to direct certain classes of commands to the correct component in the file system. These entries are located in:
                        \Session Manager
                              \DOS Device Drivers
Finally, the entries under:
                  \Session Manager
are loaded.
As can be seen, by default the only required entry is the Win32 subsystem (CSRSS.EXE). This subsystem is required, because all access to the video screen goes through the Win32 subsystem, therefore it must always be loaded.
Windows Start
When the Win32 subsystem is started, it automatically starts WINLOGON.EXE, which starts its System entries under:
                        \Current Version
By default WINLOGON.EXE will start the Local Security Authority subsystem (LSASS.EXE) and the print spooler (SPOOLSS.EXE). Next, the welcome screen is presented with the CTRL+ALT+DEL logon message and then the Service Controller (SCREG.EXE) is executed.
Tip      It is possible to by pass the CTRL+ALT+DEL logon message and automatically logon to Windows NT. To enable this functionality, follow the steps below:
 1.      Start RegEdit32 (REGEDT32.EXE) and edit the following key:
                  \Windows NT
 2.      Assign the appropriate strings to the below values of the ...\Winlogon key, for the domain, account name, and password:
 3.      Add a value called "AutoAdminLogon" to the ...\Winlogon key. This value should have a data type of REG_SZ and a value of 1 (just the character 1).
      The next time the system is shutdown and restarted, the system will automatically logon to Windows NT and bring up the Program Manager ready for use.
Once the Service Controller has started, it makes a final pass through the Registry looking for items with a start value of 0x2. However, at this point the loading sequence is determined differently from that of the device drivers that were loaded earlier in the process. All services with a 0x2 start value have certain dependencies, DependOnGroup and/or DependOnService entries which determine their load order. This is necessary because these services are loaded in parallel for better performance, where as the device drivers were loaded serially so their Group order was sufficient. Each service must have its dependencies started before it will be able to start.
In addition, there are two different type values for services loaded by the Service Controller. These are type 0x10 services which only allow one (1) service to run in a given process space. This allows the same .EXE to be started multiple times, each with different names and process space. The EventLogger is an example of a type 0x10 service. Type 0x20 services have multiple services in each .EXE and when each one is started, they are each given a new thread, but no new process is created. The LanmanWorkstation and LanmanServer are examples of type 0x20 services.
At this point the Clone ControlSet is copied to the LastKnownGood ControlSet. Although support for the LastKnownGood is designed into the system, it has not been fully enabled in the Beta 1 and Beta 2 releases of Windows NT. In the first two Beta releases of Windows NT, the CurrentControlSet is copied to LastKnownGood as soon as the CTRL+ALT+DEL dialog appears.
In the final release of Windows NT, the boot will not be considered good until a user successfully logs onto the system. After a successful logon, then the Clone ControlSet will be copied to the LastKnownGood ControlSet.
The completed boot sequence:
Trouble-shooting the Boot Process
·      If NTLDR is missing, the following message will appear:
      BOOT: Couldn't find NTLDR. Please insert another disk.
·      If the boot fails right after switching to the blue screen with the following error message:
      Fatal System Error: 0x00000067
***Configuration Initialization error
      then NTDETECT.COM is missing.
·      In a dual boot configuration, when attempting to boot the second operating system you will receive the following error message if BOOTSECT.DOS is missing:
      Couldn't open boot sector file multi(0)disk(0)rdisk(0)partition(1):\bootsect.dos
BOOT.INI Problems
·      If the system automatically boots into Windows NT without giving the Boot Loader choices, BOOT.INI is either bad, missing, or the time= entry is set too low.
·      If the path for the default= line in the [Boot Loader] section of the BOOT.INI does not match any of the paths in the [operating systems] section, then a new menu selection, "NT (default) [debugger enabled]" will appear. This will be the highlighted entry, using the default= line in the [Boot Loader] section, and will be loaded, or will be attempted to load, if the time expires. This additional selection means there has been a line changed in the BOOT.INI.
·      If part of the path statement to Windows NT is incorrect, you will receive the following error message:
      OS Loader V2.10
loading file scsi(0)disk(0)rdisk(0)partition(1)\nt\system32\ntoskrnl.exe
The system did not load because it cannot find the following file:
<winnt root>\system32\ntoskrnl.exe
Please re-install a copy of the above file.
Boot failed
      The second line of the error message will vary depending on system hardware and the path Windows NT is installed in. This can be caused by a damaged BOOT.INI file, or NTOSKRNL.EXE may indeed be missing.
·      If there is an invalid device or partition component in the path to Windows NT in the BOOT.INI file, you will receive the following error message:
      OS Loader V2.10
The system did not load because of a computer disk hardware configuration problem.
Could not read from the selected boot disk.  Check boot path and disk hardware
Please check the Windows NT(TM) documentation about hardware disk configuration and your hardware
reference manuals for additional information.
Boot failed
      Again, this is an error that will be caused by a damaged BOOT.INI file.
Speaking The Language
Before Going On
 1.      What are the three methods of installing Windows NT? Which of these methods requires the most available hard drive space and why? Which method is recommended for large corporations with large numbers of identical systems?
 2.      To use the WINNT.EXE method of Setup, what kind of network software is required? What two utilities must be used for the Computer Profile Setup, and what does each do?
 3.      What hive contains the information about your hardware configuration, and in what directory is this file located? What hive contains the user profile information that will be used when a user logs on?
 4.      What information is stored under HKEY_CURRENT_USER? Is this key mapped to any other keys? If so which one(s)? What Windows NT Registry predefined handle is the equivalent of the Windows 3.1 registration database?
 5.      What key under HKEY_LOCAL_MACHINE is recomputed with each system boot? Which key under HKEY_LOCAL_MACHINE contains the information necessary to boot Windows NT?
 6.      Looking under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services at one of the driver entries, what value will tell whether or not the driver is being loaded during Windows NT boot? What will this value be if the driver is not being loaded?
 7.      Where in the Registry, can the number of the ControlSet that the system was booted from be found?
 8.      What file is the main component of the early stages of the Windows NT boot sequence on x86 based systems? What six steps does this file perform if Windows NT is selected to load?
 9.      What file is the main component of the early stages of the Windows NT boot sequence on NON x86 based systems? Do NON x86 based systems use NTDETECT.COM? Why or why not?
10.      After the platform specific stages of the boot sequence, what are the four remaining stages that occur on all hardware platforms?
Lab Exercises
Viewing Effects of Missing Files on System Boot
To Learn More
See Chapter 5 - Windows NT Configuration Registry, of the Windows NT Resource Guide
See Chapter 6 - Windows NT Installation and Configuration, of the Windows NT Resource Guide
See Chapter 7 - Windows NT Boot Sequence, of the Windows NT Resource Guide
See Chapter 20 - Migrating from Windows 3.1, of the Windows NT Resource Guide
See Chapter 24 - Troubleshooting, of the Windows NT Resource Guide
See PC MAGAZINE, January 12, 1993, "Power Programming - A Look at the Windows NT System Registry" by Ray Duncan.
See PC MAGAZINE, January 26, 1993, "Power Programming - Exploring Windows System Registry Performance Data" by Ray Duncan.


fancyAuthor Commented:
This question has nothing to do with WindowsNT it is about a Windows for Workgroups computer that is on a simply peer-to-peer network that constantly comes up with the error message floating point error
Check to see if you have a perm swap file...should be set to about double your Ram. Also disable 32 bit disk access and file access and see if this helps.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.