Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


February 24, 2000

Adding a Processor Without Reinstalling Windows NT

RSS
Subscribe to Windows IT Pro | See More Resource Kit Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

Last year, I came upon a Web site whose authors described adding a second processor to the site's server without reinstalling Windows NT after doing so. The server still had a single-processor kernel, leaving the second processor unused.

I wanted to add a second processor to my system, but my server is a production server with Microsoft Exchange Server, SQL Server, and other critical applications, so I was loath to reinstall NT. I have no backup server. I searched documentation, newsgroups, and asked peers, but I kept getting the same answers: Either reinstall NT after adding a second processor or use the uptomp.exe utility from the Microsoft Windows NT Server 4.0 Resource Kit and pray (it seems that uptomp has a bad reputation). I didn't like either of these options, and I began to think that I should stick with one processor.

After searching and thinking, I stumbled upon something that worked like a charm for me. Microsoft Support Online article Q168132 explains that you can accidentally wipe out a multiprocessor configuration while installing a service pack (SP), and that you can restore the configuration by editing the setup.log file and reinstalling the SP. The setup.log edits replace single processor system files with multiprocessor files. I realized that I could follow the same steps to give my system multiprocessor functionality without reinstalling NT or using uptomp. After some research about my configuration (I'm running NT Server 4.0 with SP3), I decided to try the edits.

My biggest challenge was determining which hardware abstraction layer (HAL) the hardware required—not even the vendor, a well known and highly respected company, could tell me with 100 percent certainty. I used the vendor's suggestion (halmps.dll) because it made sense, but you need to be very careful and ensure that you understand what you're doing before proceeding. If you apply the wrong HAL, you can disable your system. Before you proceed, I suggest that you create an Emergency Repair Disk (ERD). For information about creating an ERD, see Michael D. Reilly's The Emergency Repair Disk, January 1997.

Final results: I'm one happy customer. I upgraded to a multiprocessor environment with no repercussions for my applications and with minimal downtime. I have since applied SP4 to the system, and everything continues to run smoothly.

End of Article



Reader Comments
I do not understand all these problems with uptomp utility.
It works 100% and is a very easy tool. Just one trap, you can not reboot computer before reapplying service pack.
I upgraded many computers from desktops to production servers and had problem just once. First time I did it I forgot about Service Pack ;(

Rafal Wlodarczyk March 01, 2000


Here is a detailed explanation of what Rusty was talking about. I have done this successfully countless times and have never had a problem with SP updates or anything else for that matter.

To manually upgrade from single CPU to dual CPUs do the following:

#1: Find the file SETUP.LOG in \%systemroot%\repair\ and open in notepad. Search for an entry called NTOSKRNL, and below that an entry called HAL. You should find a line something like this:

ntoskrnl="ntoskrnl.exe","E197B"

You are going to change that line to look like this:

ntoskrnl="ntkrnlmp.exe","D89EB"

Right below the NTOSKRNL entry you will find the other entry like this: hal="hal.dll","D0223"

Change this entry to: hal="halmps.dll","1A01C"

#2: Find the files NTOSKRNL.EXE and HAL.DLL in
\%systemroot%\system32 and rename them to .OLD or something so you will know what they are.

#3: In the SP3 distribution you should be able to find the files NTKRNLMP.EXE and HALMPS.DLL. These should be renamed to the original filenames, ie. NTOSKRNL.EXE and HAL.DLL, and place them in the \%systemroot%\system32 subdirectory.

note: The original files are read only so you will need to remove that attribute in order to rename them.

#4: Shut the server down and install the second CPU. Reboot and the multi-processor support should be working just fine. Verify it by starting Task Manager and viewing the Performance tab, you should see two CPU Usage History Windows, one for each CPU.

Additional notes:
Be sure that you DO NOT have the second CPU in the system when you begin this procedure.

The reason for changing the entries in setup.log have to do with service pack installations. If these entries are NOT changed as described, the next time you reinstall a servie pack it will overwrite the mulit-processor files with the single-processor files and you are back to square one.

This process is reversible, simply go through the procedure I outlined in reverse. Change back to the old files and old entries in setup.log, in other words.

I have found this to be a rather quick and easy way to switch back and forth between single- and dual-processor operation on ANY dual-processor machine with NT. It is very usefull if your machine is crashing with the dual-processor support enabled (maybe a bad cpu) and you need to switch back to single-processor to keep a critical system functioning.

Trent Garner March 21, 2000


I tried this instead on using the uptomp.exe utility and the result is the BSD. I am running a HP Netserver 2000 and am using the same HAL as yours. After I made the final changes to the setup.log in the Repair folder I ran SP6a without first rebooting the system. This is when I got the Blue Screen. I booted the system to my backup OS of Windows NT Workstation and restored the setup.log back to the original condition and rebooted and still got the BSD. Is this because now the the service pack was installed? I think your method is way to risky and will end up causing serious downtime.

Tom February 11, 2002


You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor? Register now




Top Viewed ArticlesView all articles
Confirmed: Battery Life Issues Not Windows 7's Fault

Microsoft on Monday issued a lengthy statement about the recent Windows 7 battery controversy, echoing my assessment from earlier in the day, but backing it up with hard, cold evidence. ...

Microsoft Warns of Windows Version Expirations

Microsoft warned that this year will see three out-of-date Windows versions slip into retirement. ...

Battery Life Issues Almost Certainly Not Windows 7's Fault

While Microsoft is still investigating a notebook battery life issue that was supposedly caused by Windows 7, some interesting trends have emerged. ...


Windows OSs Whitepapers Protecting Microsoft SharePoint

Related Events Deep Dive into Windows Server 2008 R2 presented by John Savill

Managing IT Across Multiple Locations

Check out our list of Free Email Newsletters!

Windows OSs eBooks Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

SQL Server Administration for Oracle DBAs

Related Windows OSs Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2010 Penton Media, Inc. Terms of Use | Privacy Statement