Adding SMP Support for Windows NT/2000
Last Updated: 10 Dec 2002
*** PLEASE NOTE: Link(s), If Provided, May Be Wrapped ***
Here is how you configure Windows NT and Windows 2000 to
support multiple CPUs if you initially installed the OS
as on a box with a single CPU.
The Windows 2000 method is much more convenient than the
1. Update ERD using NTBACKUP
2. Create SystemState backup on local drive.
3. Check for the latest firmware or configuration info
4. Go to Device Manager and switch to SMP HAL.
5. Reboot. If issues, restore from backup or Recovery Console
6. Power down and add the CPU.
7. If it doesn't boot, then remove CPU.
The following procedure was provided by Dave Nestor of
Microsoft on one of the Windows NT mailing lists. This
is for Windows NT 4.0:
I would recommend against using UPTOMP.EXE unless you
have revision 3 of the NT4 Resource Kit. A simpler way
to do this is to edit the hidden, read-only file called
SETUP.LOG that's in the \WINNT\Repair directory and
reapply your current Service Pack. UPDATE.EXE from the
Service Pack relies on information in SETUP.LOG for the
proper files to install, it does not do any discovery
process, so if the wrong information is in that file, a
dual processor computer can be blindly returned to single
Six files in the System32 directory determine NT's
multiprocessor capability. NT is multiprocessor by
default which is why we load the multiprocessor kernel
during a fresh install. Later during that install, if
only a single processor is found, we install HAL.DLL or
HALAPIC.DLL and rename it to HAL.DLL and copy in
NTOSKRNL.EXE. Setup will also "smash locks" on four
other files, KERNEL32.DLL, NTDLL.DLL, WIN32K.SYS and
WINSRV.DLL to make them single processor versions.
Failure to alter those four files will burden a single
processor computer with about a 5% performance hit.
Therefore, the manual way to do an upgrade is, from a
command prompt only (using a GUI will give you an access
violation) rename the current six files to *.OLD and copy
in fresh versions of:
HALMPS.DLL and rename it to HAL.DLL
NTKRNLMP.EXE and rename it to NTOSKRNL.EXE
Of course, these had better be files from your current
Service Pack and not from the original CD.
Now you're left with the problem of the SETUP.LOG file
containing single processor information. The next
Service Pack install will move you back to a single
processor version of NT. So edit that file with the
following information, being careful to enter the correct
checksums which will tell the next Service Pack not to
"smash locks" on four files.
\WINNT\System32\NTOSKRNL.EXE = "NTKRNLMP.EXE","E76AB"
\WINNT\System32\HAL.DLL = "HALMPS.DLL","1A01C"
\WINNT\System32\KERNEL32.DLL = "KERNEL32.DLL","5B7F8"
\WINNT\System32\NTDLL.DLL = "NTDLL.DLL","59C19"
\WINNT\System32\WIN32K.SYS = "WIN32K.SYS","132603"
\WINNT\System32\WINSRV.DLL = "WINSRV.DLL","37B4E"
Do a notepad search on the individual file names to find
these lines, since they are not together in SETUP.LOG.
OK, now you're done.
Or, edit the SETUP.LOG first and reapply your current
Service Pack. That's the quick way to do this.
• Whenever possible, use the vendor approved method
of upgrading to SMP. Compaq, for instance, provides
their own HALs, and it would be best to use their
SSDs for upgrading to a MP Kernel.
• With NT4, if you purchase SMP-capable hardware, but
only a single CPU, you should still install the MP
Kernel. Yes, there is a minimal performance penalty
vs running a single CPU system with the UniProcessor
Kernel, but you will have far less grief when you're
ready to install that second CPU. Win2K is much
better about this (although I still feel that the
Server family of NT/Win2K should install the MP
kernel by default).
• Even if your software is not specifically designed
to be SMP capable, you will gain benefits from
running an SMP configuration because at the very
least, the OS will be able to service its own
requests on the additional CPU(s) while the apps
in question are handled on a different CPU.