I know that XP is limited to something like 2.75GB of RAM. Can someone please explain, as detailed, yet simply(that makes no sense, I know) as possible, why this occurs?
Someone is arguing with me that Windows utilizes however much RAM your mobo supports, and I know that he is completely wrong(he's talking about x32).
I really need to just beat him down with this, cause I don't really like him. So anyone who can explain this well, please step up to the plate.
32-bit systems support a total of 4gb of RAM. Windows takes this and splits it in half, using 2gb for apps, and 2gb for the kernel. If you add the /3g switch the boot.ini, then it uses 1gb for the kernel, and 3gb for apps.
My questions: What does Windows do when I only have one gig of RAM? I don't see it split in half anywhere.
Also, doesn't this render that extra 1gb of RAM useless? I mean if the kernel runs fine when I only have 1gb total, why does it need to steal 1gb to itself?
On my system I use about 450Mb with AIM, FAH, Avast, Desktop Utilities, Microsoft AntiSpyware, RivaTuner, and a ton of FireFox broswers. When I play games (BF2) it goes up to about 1200, so 2GB is great for games. I can't imagine anyone needing more than 2 GB though.
This is from a post I made in another topic a long time ago. Windows XP Pro supports up to 4 Gigs of RAM. I've included a link below (MSA555223) that gives a really good breakdown of what Windows does with your memory.
Heh, just make sure you don't go building a windows system with that much ram. The only MS Windows that can handle 32GB or more is Windows 2000 Datacenter Server, Windows Server 2003 Enterprise Edition, and Windows Server 2003 Datacenter Edition.
Quote:
Here's a list of how much RAM the various Windows versions and editions support (as of Nov 2004):
Windows NT 4.0: 4 GB
Windows 2000 Professional: 4 GB
Windows 2000 Standard Server: 4 GB
Windows 2000 Advanced Server: 8GB
Windows 2000 Datacenter Server: 32GB
Windows XP Professional: 4 GB
Windows Server 2003 Web Edition: 2 GB
Windows Server 2003 Standard Edition: 4 GB
Windows Server 2003 Enterprise Edition: 32 GB
Windows Server 2003 Datacenter Edition: 64 GB
4gb is common place in the design industry, i think you can go a bit more. But 64bit doesn't really ahvea limit atm as im aware of, or it might be 1tb i read a while back. But nothing to be concerned with lol
Not sure if anyone is still interested but here it goes, all 32 bit CPU's internal architecture only allow them to access 4Gb of ram,because your CPU only works with 1's and 0's (binary) so 32 bit is a maximum of 32 1's or 0's next to each other so there is a physical constraint since the addresses are limited. So the 64 bit CPU has twice as many bits to use for memory allocations. But this is just on the CPU side Motherboard specs, and Operating systems also have to be taken into account, btw 32 bit CPU's have supported 4Gb of ram all the way since the 80386, it was only as a result of the Motherboards and OS's that there was a limit on the amount of RAM (and the trivial fact that you couldn't get anyone, apart from a few propeller heads, who knew how big 4Gb was let alone get that amount of Ram, but why would you, in those days I didn't know how on earth I would EVER be able to fill up my brand new 100Mb hard drive)
Originally Posted by Cmespeak
Not sure if anyone is still interested but here it goes, all 32 bit CPU's internal architecture only allow them to access 4Gb of ram,because your CPU only works with 1's and 0's (binary) so 32 bit is a maximum of 32 1's or 0's next to each other so there is a physical constraint since the addresses are limited. So the 64 bit CPU has twice as many bits to use for memory allocations. But this is just on the CPU side Motherboard specs, and Operating systems also have to be taken into account, btw 32 bit CPU's have supported 4Gb of ram all the way since the 80386, it was only as a result of the Motherboards and OS's that there was a limit on the amount of RAM (and the trivial fact that you couldn't get anyone, apart from a few propeller heads, who knew how big 4Gb was let alone get that amount of Ram, but why would you, in those days I didn't know how on earth I would EVER be able to fill up my brand new 100Mb hard drive)
Great first post... rep+ for your first post, i wish everyones first post was like this LOL
Originally Posted by Cmespeak
Not sure if anyone is still interested but here it goes, all 32 bit CPU's internal architecture only allow them to access 4Gb of ram,because your CPU only works with 1's and 0's (binary) so 32 bit is a maximum of 32 1's or 0's next to each other so there is a physical constraint since the addresses are limited. So the 64 bit CPU has twice as many bits to use for memory allocations. But this is just on the CPU side Motherboard specs, and Operating systems also have to be taken into account, btw 32 bit CPU's have supported 4Gb of ram all the way since the 80386, it was only as a result of the Motherboards and OS's that there was a limit on the amount of RAM (and the trivial fact that you couldn't get anyone, apart from a few propeller heads, who knew how big 4Gb was let alone get that amount of Ram, but why would you, in those days I didn't know how on earth I would EVER be able to fill up my brand new 100Mb hard drive)
Welcome to the forum nice to have you here.
You are wrong.
Let me start with the obvious. 2^64 is not twice as much as 2^32? It is maybe beyond an order of a magnitude? 4GB is 2^32 and is 4GB of addressable memory 2^64 is 17.2 billion GB. More than RAM must use so you will never get 4GB's of RAM with a 32bit OS. Consider?
To end all the speculation about a Windows XP Professional supporting more than 4 GB of physical RAM
I patched the kernel. For the test I used the kernel file ntkrpamp.exe from XP SP1, which is the multi
processor kernel with enabled physical address extension. Pay attention that we can not use XP SP2 or
SP3, because Microsoft removed the RAM support since SP2.
The fastest method to find the RAM patch location inside an unknown kernel executable is by setting a
breakpoint at the function ExVerifySuite with the following WinDbg command:
bp nt!ExVerifySuite
We run the OS and after the breakpoint is hit press Shift + F11 to step out of the function ExVerifySuite.
Right at this code location has to be a check for the suite type and some typical RAM size values like:
- 0x80000 for 2GB RAM
- 0x100000 for 4GB RAM
- 0x200000 for 8GB RAM
- 0x400000 for 16GB RAM
- 0x800000 for 32GB RAM
- 0x1000000 for 64GB RAM
- 0x2000000 for 128GB RAM
We only have to patch the jumps accordingly, so the biggest possible value is used.
For XP SP1 we patch the following offset in ntkrpamp.exe which enables all available RAM up to 64 GB:
- WinDbg "bp nt!MiPagesInLoaderBlock+0x48" from
80684d66 7515 jne nt!MiPagesInLoaderBlock+0x5f (80684d7d)
to
80684d66 90 nop
80684d67 90 nop
- IDA from
INIT:005B0D66 jnz short loc_5B0D7D
to
INIT:005B0D66 nop
INIT:005B0D67 nop
- hex editor offset 0x197D66 in the kernel file ntkrpamp.exe from
75 15
to
90 90
After ntkrpamp.exe is changed we have to do the following to replace the original kernel file:
- correct the checksum of ntkrpamp.exe with LordPE
- add /PAE switch to boot.ini
Do not omit this step otherwise we can not address the full RAM!
- replace the original kernel file by the patched one:
- rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
- rename the file "C:\Windows\Driver Cache\i386\sp1.cab" to "sp1.cab_"
- rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
- cancel the "Windows File Protection" message box and choose "Yes"
- copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
- cancel the "Windows File Protection" message box and choose "Yes"
- reboot
So if I follow you we basically need to get the XP SP1 ntkrpamp.exe kernel, modify it 'removing the limiter', then rename as ntkrnlpa.exe and paste in place of original ntkrnlpa.exe kernel (plus extra touches).
When you say:
Quote:
... Pay attention that we can not use XP SP2 or SP3, because Microsoft removed the RAM support since SP2 ...
It would also be possible to modify the SP2 and SP3 ntkrpamp.exe, but it would have no effect at all. It seems Microsoft has changed some stuff like the HAL starting with SP2.
To reduce driver compatibility issues, Windows Vista and Windows XP Service Pack 2 or a later version include hardware abstraction layer (HAL) changes that mimic the 32-bit HAL DMA behavior. The modified HAL grants unlimited map registers when the computer is running in PAE mode. Additionally, the kernel memory manager ignores any physical address that is more than 4 GB. Any system RAM that is more than the 4 GB barrier would be made unaddressable by Windows and be unusable in the system. By limiting the address space to 4 GB, devices with 32-bit DMA bus master capability will not see a transaction with an address that is more than the 4 GB barrier. Because these changes remove the need to double-buffer the transactions, they avoid a class of bugs in some drivers that is related to the correct implementation of double buffering support.
It would also be possible to modify the SP2 and SP3 ntkrpamp.exe, but it would have no effect at all. It seems Microsoft has changed some stuff like the HAL starting with SP2.
Are you sure you're using the correct hal.dll? There are many versions of them, to detect the correct one you need to open your original hal.dll in explorer (rightclick-properties) and look for the original name.
In the Version tab, look for the original file name property. For example, on my PC it's halmacpi.dll. So, you need to extract halmacpi.dll from XP SP1 distributive to system32 folder, and modify/add the boot.ini menu to include it like this
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows XP Professional patched halsp1″ /pae /fastdetect /kernel=ntkrnlp2.exe /hal=halmacpi.dll
Not sure which hal.dll you're using, but it works ok on my pc, usb drives and DMA are working.
Do not try Server 2003 SP2 halls, as they are not binary-compatible with XP (different set of imported/exported functions)
@TELVM: Many thanks to you for pointing into the right direction with the link! Much appreciated!!!
I tested it on XP SP3 with the hal.dll from XP SP1 and it worked. Be careful I have not done a lot of tests, but connecting a USB stick worked.
Be advised that the link patches another location very near my patching location. But in my opinion the patch from the link only enables up to 16 GB RAM instead of mine which should enable 64 GB RAM.
For XP SP3 we patch the following offset in ntkrpamp.exe which enables all available RAM up to 64 GB:
- WinDbg "bp nt!MiPagesInLoaderBlock+0x5d" from
e0d73851 751b jne nt!MiPagesInLoaderBlock+0x7a (e0d7386e)
to
e0d73851 90 nop
e0d73852 90 nop
- IDA from
INIT:005D0851 jnz short loc_5D086E
to
INIT:005D0851 nop
INIT:005D0852 nop
- hex editor offset 0x1B2A51 from
75 1B
to
90 90
After ntkrpamp.exe is changed we have to do the following to replace the original kernel file:
- correct the checksum of ntkrpamp.exe with LordPE
- add /PAE switch to boot.ini
Do not omit this step otherwise we can not address the full RAM! This is necessary, because
we will use hal.dll from XP SP1.
- replace the original kernel file by the patched one:
- rename the file "C:\Windows\Driver Cache\i386\driver.cab" to "driver.cab_"
- rename the file "C:\Windows\Driver Cache\i386\sp3.cab" to "sp3.cab_"
- rename the file "C:\Windows\system32\ntkrnlpa.exe" to "ntkrnlpa.exe_"
- cancel the "Windows File Protection" message box and choose "Yes"
- copy the patched file ntkrpamp.exe to "C:\Windows\system32\ntkrnlpa.exe"
- cancel the "Windows File Protection" message box and choose "Yes"
- rename the file "C:\Windows\system32\hal.dll" to "hal.dll_"
- copy hal.dll from XP SP1 (internal file name halmacpi.dll) to "C:\Windows\system32\hal.dll"
- do not forget to add the boot.ini switch /PAE, otherwise we can not address the full RAM,
because we use hal.dll from XP SP1
- reboot
Again many thanks to TELVM for clearing things up!
After intensive testing I found out that after applying the patch my external USB HDD does hang very often and looses power. This could hang the complete computer. It seems to be related to hal.dll from XP SP1. If we switch back to the hal.dll from XP SP3 and use a patched kernel the computer won't boot anymore. But if we switch back to hal.dll from XP SP3 and install VSuite Ramdisk without adding any ram disks the system boots up fine. By investigating further we see that the driver that seems to solve the problems is rxvstor.sys, this can be installed with rxvstor.inf and installs a new virtual SCSIAdapter device. If we install the included bus driver only, named rxvbus.sys, we get one or more exclamation marks in device manager on USB devices and the problem still persists. We could also install both drivers and it works, but only rxvstor.sys is needed really. The above was verified on two of my systems. To get the drivers simply install VSuite Ramdisk and look into the program folder. In the end I recommend to use Windows 2003 Server to support more memory on x86, because I do not know what other side effects the patch will have on XP SP3.
thanks for all the info.
preparing to upgrade hardware to ivy bridge platform and would like to use 8 gigs of ram instead of 4, as it's already maxing out even with my current pentium 4 system.
everything seems clear, just the part about correcting the checksum of ntkrpamp.exe with LordPE... how to do it?
- patch ntkrnlpa.exe
- start LordPE > press button "PE Editor" > choose ntkrnlpa.exe > Open > click on the question mark symbol besides the checksum edit control >
the checksum should change > press button "Save" > OK > close LordPE
Hi - I am trying to reproduce your success but I am having issues:
SYSTEM has 4GB
I am not able to reproduce the modifications you did, tried on GERMAN XP Professional SP3 Kernel.
The hexoffsets differ, if I try to modify the same address the resulting kernel will not boot.
I would like to understand how to determine the needed offsets for each possible ntkrpamp version using windbg, but I just don't know how to use it...
What am I trying to do?
Windows XP SP3 Pro german (ntkrpamp build5.1.2600.5512 as well as latest and greatest 5.1.2600.6419) do the >4GB patch
PAE-Kernel Multiprocessor (ntkrpamp)
I also have some halmacpi to play with:
from original SP1 (5.1.2600.1106) german
as well as newer german ones (inbetween SP1 and SP2) which might solve the USB problems you ran into (I would like to try that)
as well as german SP3 5.1.2600.5512
as well as english SP3 5.1.2600.5512
My problem is: I have absolutely no clue using Windbg. Do I have to do REMOTE debugging to set breakpoints?
I played a little more:
I thought when using ENGLISH SP3 files, it might actually work,
(the hex offsets are not the same in the german one (when I try to replace the same offsets in german as you did, the system won't boot)
So here is what I did:
System is still Windows XP SP3 GERMAN + almost latest patchlevel
I downloaded SP3 english and extracted ntkrpamp as well as halmacpi from it...
expanded english sp3 ntkrpamp.ex_ into sys32\ntkrnlpa.exe 5.1.2600.5512
expanded english sp3 halmacpi.dl_ into sys32\hal.dll 5.1.2600.5512
applied your fix to ntkrnlpa.exe
- hex editor offset 0x1B2A51 from
75 1B
to
90 90
fixed the checksum in pe-header of ntkrnlpa.exe
SFC is turned off, it won't replace the files with other ones - I doublechecked that!
rebootet the system - it starts (does NOT crash - even with eng sp3 halmacpi)
tried several boot.ini settings:
/fastdetect /noexecute=OptIn
-> PAE shown in system info (3,25GB) but is used for NX
TaskManager shows 3405932kb
this represents system default boot.ini
then I tried
/fastdetect /noexecute=OptIn /PAE
-> PAE shown in system info (3,25GB) but is used for NX
TaskManager shows 3405932kb
same result as default
then I tried
/fastdetect /noexecute=AlwaysOff /PAE
-> PAE IS shown in system info (3,25GB), NX options greyed out <-PM to Kondra states otherwise, I was wrong with that....
TaskManager still shows only 3405932kb
So everything works as if I had not applied the patch at all, doesn't it?....
What am I missing?
Why does this not work?
Afterwards I tried the same with german HALMACPI from SP1 5.1.2600.1106 (although from what I've read on this topic implies that downgrading halmacpi should only be necessary if new kernel does not boot up properly)
->old halmacpi german SP1 5.1.2600.1106 gives exactly the same results
Is it because I am using english kernel files within german xp?
I would love to patch my german kernel but I still don't understand how to use WinDbg...
Do you have any idea?
Is anybody able to do the necessary changes for ntkrpamp GERMAN SP3 5512 and/or latest and greatest (different hex-offsets are necessary)?
Has anybody successfully reproduced what Kondra achieved on any XP SP3?
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Related Threads
?
?
?
?
?
Ask a question
Ask a question
Overclock.net
27.8M posts
541.2K members
Since 2004
A forum community dedicated to overclocking enthusiasts and testing the limits of computing. Come join the discussion about computing, builds, collections, displays, models, styles, scales, specifications, reviews, accessories, classifieds, and more!