LOL! I think the limity for XP is 3GB... Vista is a difference story!

 

Yep, any idea why 3gb is the limit?

 

Okay. From what I've found:

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?

 

Quote:

Originally Posted by amped Yep, any idea why 3gb is the limit?

Especially since I thought it was 4GB

 

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.

Origonal Message from Topic 66772 post #8

Quote:

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

(Windows XP 64 bit supports upto 128 GB ram)

Microsoft Article 555223

Xaine99

 

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

 

Even though you don't need the 4GB of RAM unless you are a graphics designer or something, it would be cool to have and would give you bragging rights

 

i woudlnt mind 4 gig lol.

PLus 2gb gave my firends dad problems so went for 4gig instead lol.

He runs auto cad at 1600x1200 over 2 21" TFT's lol

And he had a 64bit 4000+ summer last year 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)

 

Quote:

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

 

windows xp uses 3.25gb of ram, its something to do with the architecture 64 bit can handle 4gb+

 

Quote:

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?

And as I said welcome.

 

yeah it is most CERTAINLY double that. otherwise we would then be stuck with an 8GB limit for x64 systems..

 

Wow, hello 2006.

 

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

 

Thanks Kondra, very interesting stuff

.

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 ...

You mean that only the XP SP1's ntkrpamp.exe kernel is suitable for modification, or you mean that this procedure will not work at all for XP SP3?

 

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.

You can find a very good explanation of all the stuff here:
http://www.geoffchappell.com/notes/windows/license/memory.htm
http://www.unawave.de/windows-7-tipps/32-bit-ram-sperre.html
http://support.microsoft.com/kb/888137
Quote:

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.

 

Quote:

Originally Posted by kondra

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.

You can find a very good explanation of all the stuff here:
http://www.geoffchappell.com/notes/windows/license/memory.htm
http://www.unawave.de/windows-7-tipps/32-bit-ram-sperre.html
http://support.microsoft.com/kb/888137

Yeah I read the sites you link long ago and know about the HAL 'problem' in XP SP3, that's why I asked for clarification, thanks Kondra.

Removing the limiter in Vista & Se7en is piece of cake, but XP SP3 is tougher.

From the comments to this article seems they managed some success by transplanting halmacpi.dll from XP SP1:

Quote:

Originally Posted by daNIL
Hi quay,

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)

Quote:

Originally Posted by ouay
whooooooaaaa it works now!
I've never seen so fast windows in my life! (Since old days of XP SP1 maybe).

Awesome. Thank you for your support! WD!

 

@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!

 

My pleasure

.

 

Only for completeness of this thread.

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.

 

so nice i found this thread

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?

thx,

 

Necroing again! Haha!

Nice this is of some help to you pranza!

- 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?