How to tell NT 4 it's really running on a uni-processor system?
I've got NT 4 server running on a single-CPU system. It was originally installed on a dual cpu motherboard a few years ago before the drive was moved to a new motherboard. Every time there is a critical update from Microsoft, I have to see if files like NTOSKRNL.
I've got NT 4 server running on a single-CPU system. It was originally installed on a dual cpu motherboard a few years ago before the drive was moved to a new motherboard.
Every time there is a critical update from Microsoft, I have to see if files like NTOSKRNL.EXE has been changed because if the critical update includes a change to (specifically) that file (and possibly a handfull of others) then the system doesn't boot when it's re-started.
I have another machine (also running NT4 server) that seems to behave properly (it's also running on a single-cpu motherboard). I check NTOSKRNL.EXE on it to see how it compares to the first machine when necessary.
So, my questions are:
1) My machine obviously thinks it's still running as a multi-processor system, to the extent that it will screw itself up when downloading system updates from microsoft that include new versions of ntoskrnl.exe. How do I tell it it's really running as a single-CPU system? Is there a registry setting or two (or a dozen) I need to modify?
2) Maybe I'm not looking in the right place, but when I bring up the properties of files (like ntoskrnl.exe) and select the version tab, all I see is "4.00". Is there no build or extended version number for the various system files that have been released by microsoft for NT4 over the years???? Other than knowing the file time-stamp and file size (and maybe the checksum) is there no way to know the "pedigree" of these updated files??? Am I right about this - that Microsoft has either gotten lazy or sloppy (or just plain negligent) when version-ing these files? Is it asking too much to be able to get build or extended version info for system files?
Every time there is a critical update from Microsoft, I have to see if files like NTOSKRNL.EXE has been changed because if the critical update includes a change to (specifically) that file (and possibly a handfull of others) then the system doesn't boot when it's re-started.
I have another machine (also running NT4 server) that seems to behave properly (it's also running on a single-cpu motherboard). I check NTOSKRNL.EXE on it to see how it compares to the first machine when necessary.
So, my questions are:
1) My machine obviously thinks it's still running as a multi-processor system, to the extent that it will screw itself up when downloading system updates from microsoft that include new versions of ntoskrnl.exe. How do I tell it it's really running as a single-CPU system? Is there a registry setting or two (or a dozen) I need to modify?
2) Maybe I'm not looking in the right place, but when I bring up the properties of files (like ntoskrnl.exe) and select the version tab, all I see is "4.00". Is there no build or extended version number for the various system files that have been released by microsoft for NT4 over the years???? Other than knowing the file time-stamp and file size (and maybe the checksum) is there no way to know the "pedigree" of these updated files??? Am I right about this - that Microsoft has either gotten lazy or sloppy (or just plain negligent) when version-ing these files? Is it asking too much to be able to get build or extended version info for system files?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Figures, my VPC NT4 image was corrupted. Guess vmware is trying to tell me something.
Try: http://www.dependencywalker.com/
That should show ya the version number of the files.
Try: http://www.dependencywalker.com/
That should show ya the version number of the files.
Thanks for the info.
But answer me this:
Will setting registry values (such as # of CPU's) to the appropriate # of CPU's (1 in this case) be the same as if I had installed NT from scratch on a single-CPU motherboard?
In other words, do single-CPU systems (installed on motherboards with only ONE cpu) also have a switch in the win.ini and registry where the number of CPU's can be set?
I don't simply want to have my NT4 keep thinking it's a dual-CPU setup that's been told to use only 1 CPU. I want it to think, behave, and smell like it's a single CPU setup all the way down to it's very core.
But answer me this:
Will setting registry values (such as # of CPU's) to the appropriate # of CPU's (1 in this case) be the same as if I had installed NT from scratch on a single-CPU motherboard?
In other words, do single-CPU systems (installed on motherboards with only ONE cpu) also have a switch in the win.ini and registry where the number of CPU's can be set?
I don't simply want to have my NT4 keep thinking it's a dual-CPU setup that's been told to use only 1 CPU. I want it to think, behave, and smell like it's a single CPU setup all the way down to it's very core.
According to this:
http://support.microsoft.com/kb/168132
"The Setup.log (found in the %SystemRoot%\Repair directory) was created when Windows NT was first installed and contains information about the files copied to your system during Windows NT setup. Consequently, the file reflects the information for a single processor computer. When service packs are installed, the Setup.log file is parsed looking for the correct Hal.dll and Ntoskrnl.exe to replace."
That is in response to adding CPU's to what was originally a single-CPU system and then running the utility Uptomp.exe from the Windows NT Resource Kit.
So basically the culprit responsible for downloading multi-processor kernel updates on my single-processor system is the setup.log file. Now how to modify it so that future microsoft updates are handled correctly?
From the above link:
RESOLUTION
By modifying the %SystemRoot%\Repair\Setup.log file, you can tell the service pack Update.exe program to load the correct multiprocessor components (thus taking you back to multiprocessor support and at the same time ensuring that future service packs install correctly).
[in my case, I want to modify it so that it reflects a uni-processor installation]
Steps to fix the Setup.log and restore your system to multiprocessors:
1. Remove the read only and hidden attributes on the %SystemRoot%\Repair\Setup.log file.
2. Make a backup copy of the %SystemRoot%\Repair\Setup.log.
3. Open the Setup.log using notepad.
4. Search for and modify the following lines, being careful to use the correct operating system version section and proper HAL for your computer type:
Windows NT version 4.0
Modify the entries under [Files.WinNt] section to the following:
\<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","e76ab"
\<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","5b7f8"
\<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","37b4e"
\<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","59c19"
\<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","132603"
Then, select one of the following HALs and modify the line:
\<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","0f337"
\<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a01c"
Windows NT version 4.0 Terminal Server Edition
Modify the entries under [Files.WinNt] section to the following:
\<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","fe754"
\<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","700ee"
\<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","3e526"
\<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","62b31"
\<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","140e95"
Then select one of the following HALs and modify the line:
\<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","15a34"
\<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a062"
5. Save the modified Setup.log to the %SystemRoot%\Repair directory.
6. Re-apply the service pack to take you back to MPS support.
http://support.microsoft.com/kb/168132
"The Setup.log (found in the %SystemRoot%\Repair directory) was created when Windows NT was first installed and contains information about the files copied to your system during Windows NT setup. Consequently, the file reflects the information for a single processor computer. When service packs are installed, the Setup.log file is parsed looking for the correct Hal.dll and Ntoskrnl.exe to replace."
That is in response to adding CPU's to what was originally a single-CPU system and then running the utility Uptomp.exe from the Windows NT Resource Kit.
So basically the culprit responsible for downloading multi-processor kernel updates on my single-processor system is the setup.log file. Now how to modify it so that future microsoft updates are handled correctly?
From the above link:
RESOLUTION
By modifying the %SystemRoot%\Repair\Setup.log file, you can tell the service pack Update.exe program to load the correct multiprocessor components (thus taking you back to multiprocessor support and at the same time ensuring that future service packs install correctly).
[in my case, I want to modify it so that it reflects a uni-processor installation]
Steps to fix the Setup.log and restore your system to multiprocessors:
1. Remove the read only and hidden attributes on the %SystemRoot%\Repair\Setup.log file.
2. Make a backup copy of the %SystemRoot%\Repair\Setup.log.
3. Open the Setup.log using notepad.
4. Search for and modify the following lines, being careful to use the correct operating system version section and proper HAL for your computer type:
Windows NT version 4.0
Modify the entries under [Files.WinNt] section to the following:
\<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","e76ab"
\<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","5b7f8"
\<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","37b4e"
\<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","59c19"
\<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","132603"
Then, select one of the following HALs and modify the line:
\<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","0f337"
\<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a01c"
Windows NT version 4.0 Terminal Server Edition
Modify the entries under [Files.WinNt] section to the following:
\<%SystemRoot%>\System32\Ntoskrnl.exe = "NTKRNLMP.EXE","fe754"
\<%SystemRoot%>\System32\Kernel32.dll = "KERNEL32.DLL","700ee"
\<%SystemRoot%>\System32\Winsrv.dll = "WINSRV.DLL","3e526"
\<%SystemRoot%>\System32\Ntdll.dll = "NTDLL.DLL","62b31"
\<%SystemRoot%>\System32\win32k.sys = "WIN32K.SYS","140e95"
Then select one of the following HALs and modify the line:
\<%SystemRoot%>\System32\hal.dll = "HALSP.DLL","15a34"
\<%SystemRoot%>\System32\hal.dll = "HALMPS.DLL","1a062"
5. Save the modified Setup.log to the %SystemRoot%\Repair directory.
6. Re-apply the service pack to take you back to MPS support.
I still wish I had access to a list or inventory or version history of NT4 system files like:
kernel32.dll
Hal.dll
NTdll.dll
ntoskrnl.exe
Win32k.sys
Winsrv.dll
Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?).
Between the 2 machines I have right now, I have a variety of each of those files.
I'd like to know why all of them are simply "version 4.00". If anyone knows how to get the build or extended version info out of those files, please let me know (or tell me why that info is not available). It seems that the setup.log file identifies them based on their checksum.
One more question - about hal.dll. Is that file generic enough that motherboard makers don't have to make one specifically for individual motherboards - or chipsets?
kernel32.dll
Hal.dll
NTdll.dll
ntoskrnl.exe
Win32k.sys
Winsrv.dll
Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?).
Between the 2 machines I have right now, I have a variety of each of those files.
I'd like to know why all of them are simply "version 4.00". If anyone knows how to get the build or extended version info out of those files, please let me know (or tell me why that info is not available). It seems that the setup.log file identifies them based on their checksum.
One more question - about hal.dll. Is that file generic enough that motherboard makers don't have to make one specifically for individual motherboards - or chipsets?
Originally posted by sm5w2:
Quote:Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?).
"That's simple enough to find out though! You can extract out MOST service packs with commandline switches... ones like (iirc) /X can send ALL of its files out to a folder you choose, without installing them automatically."
I've tried:
Microsoft
File Checksum Integrity Verifier V2.05
and
fsum Version 2.51
( http://www.slavasoft.com/fsum/)
and I can't generate anything like the codes I see in the setup.log file. Are they checksums? CRC's? How are they generated???
Quote:Specifically, what are the most recent versions of those files that have at this point been made available by Micro$oft for NT4 server SP6 for a single CPU (uni-processor) installation (and how do I get checksum info for the ones I have ?).
"That's simple enough to find out though! You can extract out MOST service packs with commandline switches... ones like (iirc) /X can send ALL of its files out to a folder you choose, without installing them automatically."
I've tried:
Microsoft
File Checksum Integrity Verifier V2.05and
fsum Version 2.51
( http://www.slavasoft.com/fsum/)
and I can't generate anything like the codes I see in the setup.log file. Are they checksums? CRC's? How are they generated???
Easiest solution (without devoting time to researching fixing this that is) would be to reinstall NT.
Unless you can modify setup.log to recognize your system as uni-processor then your SOL since any update that involves the HAL will reference the dual info in your setup.log and reinstall the dual HAL.
I'll pore through technet and see if I can find what MS uses for NT4 CRC checking.
Hmm, try this link: http://www.windowsnetworking.com/kbase/W...cessormode.html
Unless you can modify setup.log to recognize your system as uni-processor then your SOL since any update that involves the HAL will reference the dual info in your setup.log and reinstall the dual HAL.
I'll pore through technet and see if I can find what MS uses for NT4 CRC checking.
Hmm, try this link: http://www.windowsnetworking.com/kbase/W...cessormode.html
Originally posted by dosfreak:
Quote:Easiest solution (without devoting time to researching fixing this that is) would be to reinstall NT.
Unless you can modify setup.log to recognize your system as uni-processor then your SOL since any update that involves the HAL will reference the dual info in your setup.log and reinstall the dual HAL.
I've already modified the setup.log to indicate the uni-processor files for hal and ntoskrnl. But I wonder if Microsoft will ever again issue critical updates for NT4 (I think that critical updates for NT4 have just come to an end - yes?)
Those 2 files (ntoskrnl and hal) seem to be the only files where there are 2 versions of each - the difference in the names being that there is an "mp" in one version of each. There doesn't seem to be any other files where there are similarly a uni-processor and multi-processor version (at least as indicated in the file name).
However, maybe there are uni and multi versions of these files:
kernel32.dll
NTdll.dll
Win32k.sys
Winsrv.dll
And the only way to tell is by version or build number. Does anyone know if this is the case for those files?
Getting back to the setup.log file, I'm not sure how important it is to have the _correct_ hash code (or what-ever the 4/5 digit hex value is) on each line of the file. During a windows-update session, once you've identified the original install state (single or multi cpu) maybe the checksum thingy doesn't play a role.
By the way, re-installing NT is basically out of the question since there is software running on it that I no longer have the original source CD (or more like floppy disks).
Something else you guys might find interesting: A few years ago this NT4 hard drive was slaved to a computer running Win2k, and then again to a computer running XP. The purpose was to run anti-virus and anti-trojan scans on the drive (seemed like a good idea to remove the drive and slave it to another system, de-frag it while we're at it, etc).
Turns out that when you slave an old(er) NTFS file system to a computer running a newer version, the older drive gets modified to the newer NTFS specs. Basically, while NT4 still runs fine when it's put back into the old computer, I can't run tools on it like chkdsk (because it doesn't recognize the NTFS version that it's now running).
If anyone knows how to convert an NTFS drive (XP-version) to NTFS (NT-4 sp6a version) let me know. I think this also accounts for why I can't get extended file version info when I look at the properties of files (like ntoskrnl and hal) but when those same files are put on a floppy and brought to a win-2k machine the extended version info can be seen.
Quote:Easiest solution (without devoting time to researching fixing this that is) would be to reinstall NT.
Unless you can modify setup.log to recognize your system as uni-processor then your SOL since any update that involves the HAL will reference the dual info in your setup.log and reinstall the dual HAL.
I've already modified the setup.log to indicate the uni-processor files for hal and ntoskrnl. But I wonder if Microsoft will ever again issue critical updates for NT4 (I think that critical updates for NT4 have just come to an end - yes?)
Those 2 files (ntoskrnl and hal) seem to be the only files where there are 2 versions of each - the difference in the names being that there is an "mp" in one version of each. There doesn't seem to be any other files where there are similarly a uni-processor and multi-processor version (at least as indicated in the file name).
However, maybe there are uni and multi versions of these files:
kernel32.dll
NTdll.dll
Win32k.sys
Winsrv.dll
And the only way to tell is by version or build number. Does anyone know if this is the case for those files?
Getting back to the setup.log file, I'm not sure how important it is to have the _correct_ hash code (or what-ever the 4/5 digit hex value is) on each line of the file. During a windows-update session, once you've identified the original install state (single or multi cpu) maybe the checksum thingy doesn't play a role.
By the way, re-installing NT is basically out of the question since there is software running on it that I no longer have the original source CD (or more like floppy disks).
Something else you guys might find interesting: A few years ago this NT4 hard drive was slaved to a computer running Win2k, and then again to a computer running XP. The purpose was to run anti-virus and anti-trojan scans on the drive (seemed like a good idea to remove the drive and slave it to another system, de-frag it while we're at it, etc).
Turns out that when you slave an old(er) NTFS file system to a computer running a newer version, the older drive gets modified to the newer NTFS specs. Basically, while NT4 still runs fine when it's put back into the old computer, I can't run tools on it like chkdsk (because it doesn't recognize the NTFS version that it's now running).
If anyone knows how to convert an NTFS drive (XP-version) to NTFS (NT-4 sp6a version) let me know. I think this also accounts for why I can't get extended file version info when I look at the properties of files (like ntoskrnl and hal) but when those same files are put on a floppy and brought to a win-2k machine the extended version info can be seen.
