Tricks & Traps: Ask Dr. Bob Your Windows NT Questions

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
By Bob Chronister, Windows NT Magazine, September 1999

Q: After installing Service Pack 4 (SP4), I found that I could no longer log on to my system. Uninstall and my pre-SP4 Emergency Repair Disk (ERD) don't work. What happened?

A: SP4 changes the Registry's SAM and Security hives, and the samsrv.dll, samlib.dll, winlogon.exe, lsasrv.dll, services.exe, and msv1_0.dll files. Pre-SP4 versions of these six files can't access Windows NT system security information after you apply SP4. If pre-SP4 versions of the first three files are present, you might not be able to log on and you'll receive a pop-up error message referencing STOP code 0xC00000DF (i.e., the specified domain name doesn't exist). If pre-SP4 versions of the last three files are present, lsasrv.dll might experience a driver entry point failure.

Here's how to fix a system that these changes affect:

  1. Make a copy of your pre-SP4 ERD before proceeding.

  2. Copy your ERD to a bootable disk because you'll need to edit the ERD's setup.log file.

  3. Remove the attributes from the setup.log file by typing the following line at a command prompt:

    attrib -r -h -s a:\setup.log

  4. Add the following lines under the [Files.WinNt] section of the setup.log file:

    \winnt\system32\samsrv.dll = "samsrv.dll"," 30ec0","\","nt40 repair disk","samsrv.dll"

    \winnt\system32\samlib.dll = "samlib.dll","f993","\","nt40 repair disk","samlib.dll"
    \winnt\system32\winlogon.exe = "winlogon.exe"," 3c2eb","\","nt40 repair disk","winlogon.exe"
    \winnt\system32\lsasrv.dll = "lsasrv.dll","2e7c7","\","nt40 repair disk","lsasrv.dll"
    \winnt\system32\services.exe = "services.exe","2e740","\","nt40 repair disk","services.exe"
    \winnt\system32\msv1_0.dll = "msv1_0.dll","cca6","\","nt40 repair disk","msv1_0.dll"
    where \winnt represents the directory where Windows NT is installed.

  5. Copy samsrv.dll, samlib.dll, winlogon.exe, lsasrv.dll, services.exe, and msv1_0.dll from the Windows NT 4.0 SP4 media to the ERD's root directory (e.g., the A drive). If you don't have enough room on the ERD for the new files, delete any files other than setup.log from the ERD. This alteration makes the ERD unusable for other repair functions, so keep the original ERD in a safe place. You can also use a second disk containing the files to be replaced and insert it when the system prompts you for the Windows NT 4.0 repair disk.

  6. Restart your computer with the three Windows NT 4.0 Setup disks.

  7. Type R to repair your Windows NT installation.

  8. Select Verify Windows NT System Files.

  9. If the system prompts you to insert Windows NT Setup Disk 4, press Esc to continue with the repair process.

  10. Replace the necessary files when the system prompts you to do so.

  11. Reboot the computer, and restart Windows NT.

    If this method doesn't work, take one of the following two steps to upgrade the installation of Windows NT 4.0 over NT 4.0 SP4.

    If the file system is FAT, copy the i386 directory from your original Windows NT 4.0 CD-ROM to a target hard disk; if the file system is NTFS, copy the directory to a network share. (Be certain to make a boot disk with network drivers installed.) You accomplish the upgrade using six files from SP4. Copy and rename the following six files to the i386 directory from the SP4 source:

    • samsrv.dl_ to

    • samlib.dl_ to

    • winlogon.ex_ to

    • lsasrv.dl_ to

    • services.ex_ to

    • msv1_0.dl_ to

  12. If the file system is FAT and the i386 directory is on the local hard disk, boot to MS-DOS and run winnt /b from the i386 directory. Next, choose the Upgrade option during the first boot into the GUI mode. If the install source location is remote and the local file system is FAT, create a network-enabled boot disk and run winnt /b off the modified Windows NT Server share. If the file system is NTFS, install a second copy of Windows NT 4.0 into a new directory. You can then run winnt32 /b from the modified i386 folder.

For more information about SP4, see Mark Minasi, "Service Pack 4," March 1999.

Q: We ran into an interesting dilemma with our Microsoft Small Business Server (SBS) implementation. SBS allows a maximum of 25 users. Our company has grown to 30 users, and we don't want to install the full version of Windows NT Server 4.0. Can you help us?

A: I assume you've tried to install additional client licenses on your SBS server and received the response Your computer already has the maximum number of licenses. You cannot add any more licenses to your computer. To fix this problem, you need to change a Registry entry. Remember that altering the Registry can cause serious problems in Windows NT. Always update your Emergency Repair Disk (ERD) before proceeding.

  1. With a Registry editor (e.g., regedit, regedt32), open the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \LicenseInfo key.

  2. Check the FilePrint entry for ConcurrentLimit, as Screen 1 shows. If this entry's value is greater than 20 (14 in hexadecimal notation), change it to the number of client licenses that the About Microsoft BackOffice Small Business Server dialog box shows.

  3. Close the Registry editor.

  4. In the Services applet in Control Panel, stop and restart License Logging.

  5. Retry adding client licenses.

The cause of this problem might be an alteration of the AutoUsers= line of the [LicenseFilePrintData] section of the winnt.sif file (i.e, someone changed this value to 25 before the installation). This value controls the user limit on clients.

For more information about SBS, see Joshua Feinberg, "Small Business Server Overhaul," June 1999.

Q:Will you explain Windows NT's boot process?

A: Because of the popularity of Intel-based machines, I'll restrict my answer to the i386 architecture.

  1. After the power-on self test (POST) loads the system BIOS into memory, the BIOS reads the contents of the Master Boot Record (MBR). The MBR takes control and reads the contents of each partition's various boot sectors to find a bootable sector.

  2. The bootsector program reads the root directory and loads Windows NT Loader (NTLDR).

  3. NTLDR loads the basic memory configuration and switches to 32-bit mode (protected mode). NTLDR then places itself into high memory to free up as much memory space as possible.

  4. NTLDR reads boot.ini and runs the OS. If boot.ini isn't present, NTLDR assumes NT is in the /winnt directory (i.e., not /winnt40) on the C drive. If NTLDR selects an OS other than NT (e.g., DOS), NTLDR moves bootsect.dos into the hard disk's boot sector. I'll assume NT is loaded.

  5. NTLDR switches back to 16-bit mode and loads, which is a 16-bit application. NTDETECT determines the machine's physical environment. (This determination occurs every time NT boots, so the environment can change for each boot.)

  6. NTLDR loads into memory and reads the resource map that NTDETECT builds.

  7. NTLDR switches the system back to protected mode. NTLDR then sets up the ring 0 mode for the kernel and loads the proper kernel (NTOSKRNL) for the machine. NTLDR pulls in the proper Hardware Abstraction Layer (HAL) and all boot drivers. Everything that NTDETECT collects becomes the HKEY_LOCAL_MACHINE/HARDWARE Registry key.

  8. NTLDR starts the run process for NTOSKRNL.

You can make a bootable 3.5" disk that contains the three essential files NTLDR,, and boot.ini. For more information about NT's boot process, see Mark Russinovich, Inside the Boot Process, November 1998 and January 1999, and Michael D. Reilly, "The NT Boot Process," December 1998.

Q: My company has 150 RAS clients that run Windows NT Workstation 4.0 and use DHCP for IP addressing. We have to use static routing for two additional clients. I selected the Allow clients to request specific IP address option on the RAS server. The DHCP users log on without problems. The static-routing users log on but can't see anything on the network, including the RAS server, PDC, or any BDCs. Any ideas?

A: First, check out the tips in Sean Daily, "DHCP Foibles," June 1999. If you still have problems, here are some additional troubleshooting ideas. (These tips are more obscure than those mentioned in that article, but they're worth a try.)

I assume that your two static-routing users can still manually connect to remote server resources (e.g., via direct Uniform Naming Convention—UNC—name references); they simply can't browse them. If the users can't connect by name, you have a name-resolution problem rather than a browser-related problem. If the users can't connect by IP address, you probably haven't enabled IP forwarding, or you haven't selected the Allow remote clients to access entire network option on the RAS server (i.e., select the Network applet in Control Panel, Remote Access Service Properties, Network, Server Settings, then the Configure dialog box for each supported protocol).

  1. In the RAS server's TCP/IP configuration, select Enable IP Forwarding (i.e., routing) if it isn't already selected. Restart the RAS server.

  2. Verify that the RAS server shows a complete browse list (e.g., in Network Neighborhood) for the TCP/IP protocol. If it doesn't, you need to address that problem first. (Most likely, the lack of a complete browse list occurs because the RAS server is multihomed or because the RAS server doesn't share a common protocol with the servers missing from the browse list.)

  3. Ensure that the RAS server correctly recorded the WINS server addresses in its TCP/IP configuration. If the RAS server is also the WINS server, try recording its IP address in both the primary and secondary WINS server address boxes in the TCP/IP configuration dialog box (i.e., enter the same IP address in both of the WINS server boxes when configuring the WINS Address tab under the TCP/IP Properties dialog box in the Network applet in Control Panel).

  4. Verify the validity of the WINS server addresses that the RAS/DUN client inherited. (Perform step 3 first, however, because the RAS/DUN clients inherit this setting directly from the RAS server's WINS configuration.) If clients still refuse to obtain the WINS address, try hard-coding the WINS server addresses in the client's Dial-Up Networking Phonebook entry.

  5. Ensure that all Windows NT servers on the segment, as well as the remote RAS clients, are at the same service pack level—preferably at least Service Pack 4 (SP4). Service packs have helped me with some bizarre NT network services problems, including problems related to WINS, DHCP, and RAS.

About the Author

Bob Chronister is a contributing editor for Windows NT Magazine and president of Chronister Consultants in Mobile, Alabama. He is coauthor of Windows NT Backup and Recovery (Osborne/McGraw-Hill). You can reach him at

Send your tips and questions to Windows NT Magazine. You can also visit Bob Chronister's online Tricks & Traps at

The above article is courtesy of Windows NT Magazine. Click here to subscribe to Windows NT Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice