Skip navigation

Ask Dr. Bob Your NT Questions - 12 Aug 1999

SEND US YOUR TIPS AND QUESTIONS.
For answers to more of your NT questions, visit our online discussion forums at http://www.winntmag.com/forums.

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

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. Type the following line at a command prompt to remove the attributes from the setup.log file:
    attrib -r -h -s a:\setup.log
  4. Add the following lines under the \[Files.WinNt\] section of the setup.log file (\winnt represents the directory NT is installed on):
    \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"
    
  5. Copy the samsrv.dll, samlib.dll, winlogon.exe, lsasrv.dll, services.exe, and msv1_0.dll files from the 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, you can 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 NT 4.0 repair disk.
  6. Restart your computer with the three NT 4.0 Setup disks.
  7. Type R to repair your NT installation.
  8. Select Verify Windows NT System Files.
  9. If the system rrompts you to insert 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 NT.

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

  1. If the file system is FAT, copy the i386 directory from your original 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 samsrv.org
    • samlib.dl_ to samlib.org
    • winlogon.ex_ to winlogon.org
    • lsasrv.dl_ to lsasrv.org
    • services.ex_ to services.org
    • msv1_0.dl_ to msv1_0.org
  2. 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 NT Server share. If the file system is NTFS, install a second copy of 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.

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?

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 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, page 204, 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 clients' user limit.

For more information about SBS, see Carlos Bernal, "Introducing Microsoft BackOffice Small Business Server," December 1997, and Joshua Feinberg, "Small Business Server Overhaul," June 1999.

Will you explain Windows NT's boot process?

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 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 ntdetect.com, 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, ntdetect.com, and boot.ini.

For more information about NT's boot process, see Mark Russinovich, NT Internals, November 1998 and January 1999, and Michael D. Reilly, Getting Started with NT, December 1998.

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. Do you have any ideas?

First, check out the tips in Sean Daily, Watch Your RAS, June 1999. If you still have problems, here are some additional troubleshooting ideas.

I assume that your two static-routing users can still manually connect to re.mote 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 check box on the RAS server (i.e., select the Network applet in Control Panel, Remote Access Service Properties, Network, Server Settings; then, go to 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 ad.dresses 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 ad.dress 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 ad.dresses in the client's Dial-Up Networking Phonebook entry.
  5. Ensure that all 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.

Editor's Note: Sean Daily contributed this answer to Tricks & Traps.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish