Enabling Dual-Core Support

I don’t really feel quite worthy enough to be attempting to get this info down.  However, I had a problem at work that demanded a solution.

Now that I found it (in two forms) I feel a bit obligated to share, despite my lack of a Microsoft Certification.

Any omissions or incorrect information shared is unintended and I welcome comments from any kind folks more up-to-date in this area.

I want to pick this up by building on my Windows CPU throttling techniques post made about a month ago.

To summarize, we have had a DOS 16-bit program that chewed up all the CPU cycles when running. In finding and testing a solution, I came to realize that the problems wasn’t nearly as sever on our dual-core processor systems as it was on our single-core processor systems.  We have been slowly upgrading and deploying dual-core configurations now for the past two years.

In that process, I discovered that a significant number of our deployed desktop systems that had a dual-core processor were, in fact, only running in a single core mode.  Yikes!

Upon more investigation, I have also identified many of our dual-core laptops also running with only a single core enabled.

What gives?

That turned out to be pretty simple to determine.

How do we get the full dual-core mode turned on?  Well, that got a bit more complex.

Double-Trouble

Turns out that the factory-provided images were flawed.  Seriously.  I just didn’t pay attention to it staring me in the face for the past two or more years.

See when we started deploying these systems, we had a post-deployment configuration step that involved copying some files to C:\Windows\System32.  It was known as the “Hyperthreading patch”.

As all our technicians knew, the files already existed on the system, and were in fact newer than the ones with the same names we were copying, but we were just told to copy them anyway and reboot.  The files were hal.dll and ntoskrnl.exe.

Whatever…so we copied them and moved on down the setup guide.  Well…most of the techs copied them.  Turns out it is now clear that a few did not.  I could tell which systems weren’t updated correctly because no sooner did we walk away then our help-desk would get a call of the user’s pc running slower than their previously assigned system.  A quick copy of the files and reboot turned the system back to a speed-demon.

Not only that, but with the latest rounds of laptops, copying those files (which did no harm to the desktops would render the dual-core laptops unbootable.

Not good.

Finally, with my CPU utilization problems bringing to the forefront of my attention that we had some dual-core systems not running dual-core mode, I knew I had to start digging deeper for an accurate understanding of what exactly was going on.

To the Google!

It’s the Processor…Stupid! (Well, maybe not.)

Having the systems in front of me and our technical specs, I had no trouble running a Google check on Intel’s website to verify that the processors we had in each system were, in-fact, dual-core.

Were I not to have that information, I could have used CPU-Z, System Information for Windows (SIW), or even SIV - System Information Viewer to get enough hardware identification information about the processor to do my lookup.

I then opened up the Windows Hardware Device Manager on several of these single-core using, dual-core processors and was surprised to see that XP Profession had correctly identified and was reporting both processors present.

However, a quick launch of the Task Manager (example 1 or example 2) confirmed that the OS was only “seeing” one core as I had no options to show both cores in separate usage graphs.

Maybe it was a driver thing?

I found this post Windows XP Multi Core config - Does your OEM do it for you? - Notebook Forums and Laptop Discussion that suggested I needed to download and apply a Microsoft patch and make some tweaks.  Only that didn’t “enable” the dual core mode at all.  Nor apparently did it help a lot of other folks who have been reading that thread.

I next turned to a comparison between two otherwise identical systems.  One was showing dual-cores activated and the other was not.  After much digging, I located what appeared to be a key registry key difference:  The dual-core system had two entries in the following locations:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTIONS\System\CentralProcessor

and 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\

Whereas the single-core one did not.

So, stupid grasshopper that I was just exported those extra registry key items and then imported them on the single-core system.  It didn’t hurt anything, but after a reboot, they were removed automagically and the system remained in a single-core state.

It was very clear that something else was going on.  But what.

It’s a HAL and NT OS Kernel Thang

I’ll spare you the extra days of ed-u-fi-cation I put myself through but in the end, I think I got it all sorted out.

(Note: All the following discussion assumes that the BIOS/systemboard supports a dual/multi-core processor AND that it has been enabled as such in the BIOS.)

Turns out that when Windows setup is ran, it should (in most cases) auto-sense the processor and apply and configure the proper HAL (Hardware Abstraction Layer) file and the correct NT OS kernel depending on the hardware auto-detected.

In our case, either the imaging process or imaging application at the factory failed to take into account a shift from a single-core to a dual-core model, or maybe the pre-build setup of the XP Pro OS wasn’t done correctly.  In any case, every dual-core system that had been deployed from the factory didn’t ship with the supported dual-core processor HAL and NT OS Kernel.

What I came to understand is that our “Hyperthreading fix” was actually patching that error and replacing the single-core files with the proper dual-core ones.  That’s why the file-names, sizes, and dates were different but the system speeded up afterwards…the dual-cores were now being used!

What I discovered is that you can see this difference in action if you have both a dual-core and a single-core enabled system to compare.  Just browse to the installed HAL and Ntoskrnl files and take a look at the file properties, then look at the “Original File Name” field.

• How can I determine which hardware abstraction layer (HAL) is running on my computer? – Windows IT Pro

• How can I determine which version of Ntoskrnl.exe I’m using? – Windows IT Pro

The key thing to notice in those quick tips is that the (correctly activated) multi-processor files will have different original file names than those of the single-processor systems.

Here are some of the most commonly seen ones:

Advanced Configuration and Power Interface (ACPI) PC
- halacpi.dll (renamed to hal.dll)
- ntkrnlpa.exe
- ntoskrnl.exe

ACPI Uniprocessor PC
- halaacpi.dll (renamed to hal.dll)
- ntkrnlpa.exe
- ntoskrnl.exe

ACPI Multiprocessor PC
- halmacpi.dll (renamed to hal.dll)
- ntkrpamp.exe (renamed to ntkrnlpa.exe)
- ntkrnlmp.exe (renamed to ntoskrnl.exe)¨

Why are they different?  Let me have a Windows IT Pro explain….

• Which files are different between the single and multiprocessor versions of Windows XP and later? – Windows IT Pro

A. The core OSs are the same for both uniprocessor and multiprocessor systems. The only real differences are in the underlying Windows kernel (which is implemented along with the Executive subsystem in Ntoskrnl.exe) and the hardware abstraction layer (HAL--hal.dll). Windows versions earlier than Windows Server 2003 and XP did have some additional files that differed (Windows 2000 also had separate versions of Win32k.sys, NTdll.dll, and Kernel32.dll). When Windows is installed, it detects the processor requirements and copies the relevant file from the media to the standard name (e.g., ntoskrnl.exe) on the installed OS. The Table shows the files that differ between the uniprocessor and multiprocessor versions of XP. Note that the Ntkrnlpa.exe is used only on systems that have invoked the Physical Address Extension (PAE) kernel, which allows access to as much as 64GB of memory. Essentially the uniprocessor version of the kernel doesn't have the mutliprocessor synchronization algorithms, which are more complex and time-consuming, so they're a waste of processing resources for systems with only one processor.

So when Windows Setup is run on a system, it should sort all this out automatically.  But problems come up if that image is Sysprep’ed and then deployed on systems that are similar enough for it to work, but having a different processor core type.

Need more links?  Here are a ton that I found helpful to get my understanding down.

• How to Troubleshoot Windows 2000 Hardware Abstraction Layer Issues – MS KB237556

• How to force a Hardware Abstraction Layer during an upgrade or an installation of Windows XP – MS KB299340

• HAL options after Windows XP or Windows Server 2003 Setup – MS KB309283

• HOW TO: Add Support for Multiple Processors in Windows 2000 – MS KB234558

• A geeks guide to Windows XP HAL Replacement – Johan Arwidmark at myITforum.com

• SysPrep in Depth - Part 3 - SysPrep.inf and HAL’s - David Remy’s Blog

• SysPrep Guide: Hardware Abstraction Layer (HAL) - 3/8 – Vernalex.com

• Imaging machines using different HALs w/sysprep – David Carlin

• Cool Solutions: Loading the Appropriate HAL via a single Image – Novell Cool Solutions Tip

• XP Ghost - HAL Issues – SysOpt.Forums

Fixing the Single-core to Multi-core Problem

OK.

I now clearly (as bayou mud) understood what was going on.  I also knew we had at least one fix method already down.

Seems from a review of multiple forums that I looked into, many home-users with the problem of their system being dual-core supported and the hardware to match, but only seeing a single-core often ended up getting told that the only way to fix this on their XP systems is to just start from scratch and re-run a full Windows setup.  This isn’t something that a Windows Repair was going to fix.

Only I didn’t like the idea of re-running Windows Setup on all these dual-core able, single-core using systems.  Too much time and work for our team.

Simply using our already issued “Hyperthreading Fix” patch which involved (what I know knew to be) copying the multi-core ACPI supported hal.dll and ntoskrnl.exe files with a following reboot would do the trick.

Kind-of. 

Although this worked great on the desktop systems, it seems it tanked the laptops.

I needed some other solution options.

Method #1: Pugsly0014’s Batch-file Wonder

I eventually discovered a solution (very similar to our “Hyperthreading Fix” patch in a notebook support forum as contributed by Pugsly0014.  Actually Pugs offers two solutions, but I liked the first better in our environment.

Enable Dual Core Support in a Windows XP Single Core Install? - NotebookForums.com

…you are going to have to replace the hal.dll and ntoskrnl.exe from the single core version to the multi core version.

Option #1 - Hal / NToskrnl replacement

a. Make a directory called DUO on C:\
b. Copy halmacpi.dll (search your C:\ drive for this) to C:\DUO then rename it to hal.dll
c. Copy ntkrnlmp.exe (search your C:\ drive for this) to C:\DUO then rename it to ntoskrnl.exe
d. Make a batch file called go2core.cmd and put this in the file.

C:
CD\windows\system32
REN hal.dll hal.old
copy C:\Duo\hal.dll C:\windows\system32
REN ntoskrnl.exe ntoskrnl.old
copy C:\Duo\ntoskrnl.exe c:\windows\system32

e. Run Go2Core.cmd from C:\duo directory.
f. Reboot and you should now see two processors in Task manager

Pugs’ second solution involved editing your boot.ini file and pointing it to the multi-core supported files, if that option is selected at boot.  It is another clever solution, but not one I wanted to offer my end-users in our environment.

Lab-testing soon found that the batch-file switch-er-oo worked great, and could be deployed as a server login-script if we so choose to do.

If you don’t find the files halmacpi.dll and ntkrnlmp.exe, you might find them in a cab file or compressed but not “expanded”. 

However, when I tested it on Dell D620/630 dual-core notebooks, it tanked them.  Seriously.

Back to the drawing board.

Method #2: An “Ageless” Solution

More searching and thinking ensued.

I then located this deviation on Pugs’s second “boot.ini” solution.

Dual core not processing two units – Seti@Home Forums

Forums poster “Ageless” offered this elegant solution (which ties into Pugs’ second method I skipped):

…follow the steps:

1. You will need Service Pack 2 for XP for this, so if you do not have it, install it from Windows Update.
2. Use search to find ntkrnlmp.exe and halmacpi.dll and copy them to your c:\windows\system32 directory.
3. Use search to find boot.ini and open it in your text editor then find the following line:

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /fastdetect /NoExecute=OptIn

(or something of this sort)

and replace that line with:

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”XP Professional MP” /fastdetect /kernel=ntkrnlmp.exe /hal=halmacpi.dll

Make sure there are no line breaks in that line.

4. Reboot your computer. It may go through an installation of the new kernel, just continue to click Yes and Install (or which ever you get) until done and that's it.

Note, depending on your flavor of XP and other factors, your boot.ini line might look a tad-bit different.

The key here is to add the /kernel=ntkrnlmp.exe /hal=halmacpi.dll part.

So I tried it on the notebooks and it worked!

Hurrah!

Caveat Emptor

Only I now wondered what impact this might have on the notebook when we went to apply XP SP3.  Would the fact that they were pointing at a non-standard kernel and hal file muck things up?

I then attempted to install XP SP3.

And it failed…because it checked the boot.ini and found it wasn’t using a “standard” kernel and hal file!

Bummer.

But wait!

When I went back in to look at the hal.dll and ntoskrnl.exe files, turns out they now matched the same size, date, and original file-name property of the ones I was pointing to!

Turns out that during the XP re-configuration process (Step 4) where it sensed the new multi-processor changes, it also updated the original single-core hal.dll and ntoskrnl.exe files to the multi-core supported ones!

What would happen if i went in and re-edited the boot.ini file back to the original?

I tried it and it worked!  The system/OS still recognized the mulit-core processor state.

Now when I tried to install XP SP3 it went on with no issues or complaints!

Awesome!

Claus’s “Ageless” Mod Fix

So here (from the top-down) is what I ended up doing to move the dual-core laptops that were only running a single-core enabled into a fully enabled multi-core processor mode when the simple file switchout trick didn’t work, as founded on “Ageless’s” technique.

1. Ensure system is running XP Service Pack 2 or greater, if not upgrade accordingly first.

2. Run a local file-search (F3) to find the ntkrnlmp.exe and halmacpi.dll files. Copy them to your c:\windows\system32 directory. Note, in some cases they might only find them in the format ntkrnlmp.ex_ and halmacpi.dl_. If this is the case you must “extract” the files in the command line using expand.exe <filename> <output filename> synatax (example: expand.exe ntoskrnl.ex_ ntoskrnl.exe)

3. Browse to the C:\windows\system32 folder and make copies of the existing hal.dll and ntoskrnl.exe files…just in case you need them later. I just leave the copies in the c:\windows\system32 folder.

4. Use search to find boot.ini and open it in your text editor.

(Or browse to Start -> Control Panel -> System and launch that. Then go to the “Advanced” tab and click the “Settings” button on the bottom “Startup and Recovery” section. Click the “Edit” button under the “System Startup” section and it will launch your boot.ini file in Notepad.)

Save a copy as boot.ini.orig to the root of your system partition (usually C:) just in case.

Then find the following line (yours may look slightly different):

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /fastdetect /NoExecute=OptIn

(or something of this sort)

and replace that line with:

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /fastdetect /NoExecute=OptIn /kernel=ntkrnlmp.exe /hal=halmacpi.dll

All that is on a single line, by the way!

Save this version as boot.ini on the root, overwriting the original.

5. Reboot your computer.

It should go through an installation of the new kernel and supporting elements.

You shouldn’t get any prompts but if you do, just continue to select Yes or Install.

When completed, you should be prompted to reboot your system to put changes into effect.

Reboot again.

6. When it comes up, you should now be able to verify you are running in dual-core mode by going to <CTRL> <ALT> <DELETE> and opening the Task Manager. Click the Performance tab and it should show both CPU cores in the “CPU Usage History” graph.”

7. Go into the c:\windows\system32 folder and you should also now be able to compare the hal.dll and ntoskrnl.exe files with the copies you made. You should note that the file sizes are now different, but do match the ntkrnlmp.exe and halmacpi.dll versions you copied in earlier. That’s because they were changed to the multi-core support versions!

8. Go back to your boot.ini file (however you want to find and open it) and open it in Notepad.

Just to be sure, you might want to first save it as boot.ini.multi.

Re-edit it back to the original state you found it in:

Find the following line (yours may look slightly different):

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /fastdetect /NoExecute=OptIn /kernel=ntkrnlmp.exe /hal=halmacpi.dll

(or something of this sort)

and replace that line with:

multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /fastdetect /NoExecute=OptIn

Save it again as boot.ini to the root of your system partition (usually c:).

9. Reboot your system again and all should be well!

So, pick whichever method you want and give it a shot.  It ended up working well on our systems at work.  Of course, every system is different in its own way and your mileage may vary.

I’m no Mark Russinovich so I’m not sure I can provide much advice outside of this narrow range of testing and hardware I’ve been working with. I know there is a lot more of the multi/single kernel and hal related technicals that I’ve only just scratched the surface of understanding with here.

I’d also recommend making backup copies of any original hal.dll and ntoskrnl.exe files first. And, keep a Windows PE 2.0, a VistaPE, or even a BartPE liveCD boot disk handy, just in case you need to liveCD-boot your system to put back any original versions.  It came in dead-useful as I was testing and working out these issues.

Bonus #1 – Controlling the Processor Affinity in a Multi-Core system

So now that you got multiple cores up and running what can you do with them?

By default, a properly configured Windows multi-core supporting system will automatically manage and load-balance CPU usage rates across them.

However, in some rare cases (or with gamers) you might want to shove all of a particular process onto a single processor and not spread it across multiple ones.

There are a number of ways and tools you can use to do this:

• Getting More Bang Out of Your Dual Processing Buck : Getting The Most Out Of Software By Properly Assigning Threads – Tom’s Hardware. – Shows how their freeware tool “THG Task Assignment Manager” can be used to assign affinity on a per-case (non-permanent) basis.

• Or, as Tom’s shows in that post you can also use the Windows Task Manager to set process affinity.

• Process Explorer from Microsoft Sysinternals can also provide that functionality, with a bit more beef in my opinion.

• RunFirst - (freeware) – Also allows you to choose on which processor an application starts. This one is clever as it supports command-line arguments so you could use it in combination with the program to make a special shortcut that will launch your program automatically on the desired multi-processor core.

• Processor Affinity Manager 1.0 - (freeware via Softpedia) – Original location at this pamanager - Google Code link.  Has drag-n-drop support, Current-process details, process defaults, tool to create a shortucut (a-la RunFirst) to launch an app with a particualar processor affinity set.

• SMP Seesaw - (freeware) – Another nice utility for setting processor affinities. (As reviewed by Download Squad.)

Finally, if you really want to get down and dirty and modify the application to launch on a particular core without these tools, you can do it, but it is going to take some extra work, as I previously posted.

You can change an application to run exclusively under a single CPU on a dual/multi-core processor, but it takes a bit more work.

In my case it specifically addressed the ntdvm.exe file tweaking that I was looking at, but could apply to almost any process.

Troubleshooting an MS-DOS application which hangs the NTVDM subsystem in Windows XP and Windows Server 2003 -  markwilson.it

Read the post but it comes down to using a Microsoft Windows 2000 Resource kit tool, imagecfg.exe with some detailed command-line arguments.

Related posts on this technique:

• Technical Support : Hyper Threading and Flight Simulator – Reality XP

• JSI Tip 3542. How can I permanently set the processor affinity for an application? – Windows IT Pro

• Set CPU Affinity prior to app launch? – Tom’s Hardware forums

• Set CPU Priority for a Process - Petri.co.il forums by Daniel Petri

Bonus #2 – Miscellaneous Multi-Core posts

I also found these posts as well in all my research.  Don’t really apply to much but are semi-related and I found them interesting, nonetheless.

• No more HAL-hell, the implications of Windows Vista’s hardware independent imaging technology – 4SysOps

• Re: .wim hal issue - TechNet Forums

• Confusion over Multi-Processor Guest OS Support with Hyper-V - Virtual PC Guy’s WebLog

• The Mystery of Hyper-V's Limit Processor Functionality? (Part 1) – Loud Sigh blog

• The Mystery of Hyper-V's Limit Processor Functionality? (Part 2 - Final) – Loud Sigh blog

• The Mystery of Hyper-V's Limit Processor Functionality? (Part 3 - Officially) – Loud Sigh blog

I hope this documentation of all my personal trials and tribulations in the land of multi-core Windows systems ends up helping someone.

The answers are out there, just takes a lot of work to tease them all out.

If anyone has any more information or additional tips, wisdom, or l33t 5k1ll5 to share, please feel free to educate me and us all.

Cheers!

--Claus