PAE patch updated for Windows 10. Win 10 pae patch by evgeny who AFAIK is Russian, has nothing to do whatsoever with. – Windows XP SP2/SP3, – Windows.
@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.
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 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. 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!
Code: I decided to make a tutorial as a proof of concept, because I would really like to see more people reversing the Windows kernel and maybe fix the USB issues I had in the past. Always keep in mind if it does not work simply use Windows 2003 Server to support more than 4 GB RAM. Code: - In the virtual machine open boot.ini and change the following line from: multi(0)disk(0)rdisk(0)partition(1) WINDOWS='Microsoft Windows XP Professional' /noexecute=optin /fastdetect to multi(0)disk(0)rdisk(0)partition(1) WINDOWS='Microsoft Windows XP Professional' /PAE /fastdetect /debugport=COM2 /baudrate=115200 Save the file after the change. We have to configure this to be COM port 2, otherwise a connection is not possible.
The /PAE switch is set, because otherwise we get a kernel exception if patching the loaded kernel with WinDbg later on. If we use hal.dll from XP SP1 and do not set the /PAE switch Windows will load the mulit processor kernel without PAE. Rename the file 'C: Windows system32 hal.dll' to 'hal.dll' and copy hal.dll from XP SP1 (internal file name halmacpi.dll) to 'C: Windows system32 hal.dll'.
Shut down the virtual machine and change the settings. In VMware Menu VM Settings. Hardware tab Add. select 'SerialPort' Next choose 'Output to named pipe' Next enter the following: - Named pipe:. Pipe com1 - This end is the server.
The other end is an application. Device status: check 'Connect at power on' Finish - on the right side under 'I/O mode' check 'Yield CPU on poll' OK - Create a command file named 'StartWinDbg-VMWare-XP-SP3.cmd' on drive C: with the following content: set NTSYMBOLPATH=C: SymbolsXPSP3 start C: WINDDK 7600.16385.1 Debuggers windbg -b -k com:pipe,port=. Pipe com1,baud=115200,resets=0,reconnect - The parameter -b means we wanna start kernel debugging.
This attaches the OS as early as possible to WinDbg. Start WinDbg with the command file 'StartWinDbg-VMWare-XP-SP3.cmd' and press Ctrl+Alt+K inside WinDbg to breakin on the first symbol load at the next boot.
Start the VMWare machine, boot XP SP3 and wait for a debugger connect. You should see the following text inside WinDbg: Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. All rights reserved. Waiting for pipe.
Pipe com1 Waiting to reconnect. Will breakin on first symbol load at next boot.
Connected to Windows XP 2600 x86 compatible target at (Sat Mar 1 08:18:31.593 2014 (UTC + 1:00)), ptr64 FALSE Kernel Debugger connection established. Symbol search path is: C: SymbolsXPSP3 Executable search path is: Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible Built by: 2600.xpsp.0 Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720 System Uptime: not available nt!DebugService2+0x10: 80531eb2 cc int 3 - If VMWare closes during the debugger connect simply start VMWare and the virtual machine once again. At the WinDbg kd prompt enter 'bp nt!ExVerifySuite' and press 'Enter'. This will set a breakpoint at the entry point of the function ExVerifySuite inside the NT kernel. Press F5 (Go) to let the virtual machine run. When our breakpoint is hit press Shift + F11 (Step Out).
This will return to the code location after the call to ExVerifySuite. Press F10 (Step Over) to go one step further.
Now we should see the following inside the WinDbg window: kd bp nt!ExVerifySuite kd g Breakpoint 0 hit nt!ExVerifySuite: 805384ce 8bff mov edi,edi kd gu nt!MiPagesInLoaderBlock+0x5b: 806a784f 3c01 cmp al,1 kd p nt!MiPagesInLoaderBlock+0x5d: 806a7851 751b jne nt!MiPagesInLoaderBlock+0x7a (806a786e) - In the WinDbg menu go to View Memory on the upper left we will see 'Virtual:' enter the address of our last code line here '806a7851' we now see the two bytes 75 1b these have to be patched to 90 90 (nop). In menu go to View Disassembly we can now see that the code has changed from 806a7851 751b jne nt!MiPagesInLoaderBlock+0x7a (806a786e) br=1 to 806a7851 90 nop 806a7852 90 nop - Type 'bc 0' at the kd prompt to clear our breakpoint and press F5 (Go) to run the virtual machine. If we look inside the task manager or run sysdm.cpl now we see the full RAM and not only 3 to 4 GB as usual. We have verified that the patch is working. Now we need to retrieve the correct patch location inside the kernel file.
Start up IDA 32 Bit and load ntkrpamp.exe as 'PE Executable'. Go to Menu Search text. String: ExVerifySuite check 'Find all occurences' OK.
Hi Kondra, thank you VERY much for this detailed Howto! I will definetely try this within the coming weeks.
However before this - I will try to redo my previous test with english kernel on a different machine which has more than 4GB of RAM, because I think the reason why this did not work is that my machine does not seem to support memory remapping. I think this is the case, because when I boot up the machine on Windows XP Pro 64Bit I see the same amount of free memory (3,25GB). This could be the explanation why it did not work as intended before. When I'm done with this, I will give the WinDbg-thing a try. I will let you know the results (including USB-plans). Again: Thank you very much, I can see how much time you spent for this!
Firstly let me say I've seen a number of similar questions on SuperUser, and I don't think this is a duplicate. (Most address 4GB RAM installed. I have 6GB) I have Windows XP 32-bit running on a i7-based Xeon system with 6GB of RAM. I only see 3.5GB of RAM in Windows.
Is there any way to squeeze more visible RAM out of this set up? Even an extra 1GB would be great. Does having 6GB (vs 4GB) of RAM installed help at all? (I.e Even if I loose the 3.5-4.0 GB region, can I use the area above it?) P.S. Will eventually move to Windows 7 64-bit, but can't for now. Even with Physical Address Extensions enabled Windows XP still allows only 4 GB of memory.
I know this can be a little confusing since Windows Server 2003 allows up to 64 GB of RAM (with the proper processor support). Sadly your OS is bounded to 4 GB in this case. The kernel may support up to 64 GB with PAE, but it is locked down in XP. It seems the only reason they still include it is for DEP support. From: Although support for PAE memory is typically associated with support for more than 4 GB of RAM, PAE can be enabled on Windows XP SP2, Windows Server 2003, and later 32-bit versions of Windows to support hardware enforced.
EDIT: I just want to add that this 4GB cap includes dedicated video memory or memory set aside for a on board GPU. As near as I can understand: 32-bit processors natively have 4GB (2^32 bit ) of address space - Period. Because of (Memory-Mapped Input/Output) a portion of this space is also used to communicate with, and address the memory of, your peripheral devices (ie gfx cards). In order to support multiple memory intensive applications and to compensate 8GB+ mainboard support, Intel (and later, AMD) introduced (Physical Address Extension) to increase the addressing space to 48 bits (and later 52 bits), respectively. This is accomplished by sending memory addresses in 2+ 'chunks' - the first 32 bits on 1 cycle, and the remaining bits on consecutive cycles thereafter. However, for this new framework to be utilized, hardware manufacturers had to integrate support for DCA (aka DAC) into their respective products, typically requiring extensive hardware revision and special PAE enabled drivers. Software also had to be rewritten to support Large Address Awareness, allowing more than the default 2GB of application memory space.
Windows Xp Sp3 Download Free Full Version
Needless to say, because of the amount of software and hardware revision involved, and with the advent of 64-bit processors soon afterward, the technology (while popular in server and enterprise environments) never significantly penetrated the end-user market. : The original releases of Windows XP and Windows XP SP1 used PAE mode to allow RAM to extend beyond the 4 GB address limit. However, it led to compatibility problems with 3rd party drivers which led Microsoft to remove this capability in Windows XP Service Pack 2. Windows XP SP2 and later, by default, on processors with the no-execute (NX) or execute-disable (XD) feature, runs in PAE mode in order to allow NX.18 The no execute (NX, or XD for execution disable) bit resides in bit 63 of the page table entry and, without PAE, page table entries on 32-bit systems have only 32 bits; therefore PAE mode is required in order to exploit the NX feature. However, 'client' versions of 32-bit Windows (Windows XP SP2 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility 14 via the licensing limitation mechanism,13 even though these versions do run in PAE mode if NX support is enabled.
Windows Xp Sp3 Final Download
So based on this it would seem that if you have pre-SP2 XP you could get more than 4GB memory.