Dave-H Posted Sunday at 10:22 PM Posted Sunday at 10:22 PM I must say that I couldn't see anything obviously wrong on reboot12's video either, no crashes or error messages. Is Explorer being sluggish the only issue? I've been using Explorer a lot since I applied the patch, and I've not noticed any difference in performance, apart from the USB issue I mentioned earlier, which now seems to be fixed. Incidentally, I've now determined what specifically is causing the out of memory problem on my browser. It's being caused by my Facebook Purity extension, which is why it was only happening on Facebook! If I disable the extension, the problem goes away. Of course, that isn't the answer. It works fine on the 64-bit version of the browser on Windows 10. The issue still is that although the extension might be causing high memory use in the browser, now that it supposedly has 16GB of RAM to play with, it shouldn't still be running out of RAM! 1
Ascii2 Posted Monday at 03:20 AM Posted Monday at 03:20 AM (edited) On 6/29/2025 at 5:22 PM, Dave-H said: Incidentally, I've now determined what specifically is causing the out of memory problem on my browser. It's being caused by my Facebook Purity extension, which is why it was only happening on Facebook! If I disable the extension, the problem goes away. Of course, that isn't the answer. It works fine on the 64-bit version of the browser on Windows 10. The issue still is that although the extension might be causing high memory use in the browser, now that it supposedly has 16GB of RAM to play with, it shouldn't still be running out of RAM! It is my understanding (I do not renumber why so; it may be hearsay) that the latest patcher, v3.5, includes a process RAM allocation limit; whereas, older versions (so sure how much older) did not. I am unsure of the reasoning why (but do have best guess) and I do not remember if such is consistent with the Windows XP (any flavor) with Service Pack 1 behavior. EDIT: Also, perhaps about 20 years ago, I knew rather better how PAE funcntions. It is my impression that while PAE does allow to more RAM usage (and against a virtual addressing resource penalty), there are still limits and individual processes might not be able to utilize more than a particular amount. I think for 64-bit Windows those limits are much (much) higher. The daniel_k HAL/NTKernel patcher seems to try to restore a more true PAE behavior. It would have been nice if the daniel_k HAL/NTKernel v3.5 patcher would have come with instructions and a changelog. Edited Tuesday at 12:13 AM by Ascii2
Ascii2 Posted Monday at 03:33 AM Posted Monday at 03:33 AM (edited) 10 hours ago, reboot12 said: @Dietmar @Mov AX, 0xDEAD I use the WinXPPAE 3.5 patch for a week and I noticed a problem with disk operations - the same is for the 64G version: Video when ram patch is used - lags: https://files.catbox.moe/ericzb.zip Video when no ram patch: https://www.sendspace.com/file/17e170 Testing config: Asus P8H61-M LE R2.0 RAM 2x4GB DDR3-1600 Dual-Channel CPU Intel Core i3-2120 WinXP SP2 Pro HDD: SATA in AHCI mode I notice a few things: It is my understanding that Windows XP with Service Pack 2 is used here (which presumably also using Service Pack 2 HAL and kernel). The patch author appears to have tested against Windows XP Professional with Service Pack 3 but not Windows XP Professional with Service Pack 2. reboot12 has not indicated which kernel and HAL file versions (both version number and variant/flavor of HAL or kernel) he has patched and tested. It would be also good to specific the relevant boot.ini configuration used. The problems experienced might not be due to defective patch but rather other bugs or defects in the patched files or elsewhere (such as other system files or other software). The videos do not demonstrate a problem with disk operations but rather performance of select operations. Edited Monday at 03:49 AM by Ascii2
reboot12 Posted Monday at 04:21 AM Posted Monday at 04:21 AM (edited) 1 hour ago, Ascii2 said: reboot12 has not indicated which kernel and HAL file versions Yea, I use SP2: ntkrnl2.exe SP2 5.1.2600.2180 (patched by WinXPPAE 3.5 on SP2 OS) + hal2.dll SP3 5.1.2600.5512 (patched by WinXPPAE 3.5 on SP3 OS because the patcher cannot patches the hal.dll SP2 version) ntkrnl3.exe SP3 5.1.2600.5512 + hal3.dll SP3 5.1.2600.5512 - both patched by WinXPPAE 3.5 on SP3 OS ntkl64g.exe SP3 5.1.2600.6368 + hal64g.dll SP3 5.1.2600.5512 - files from @Dave-H 64 GB of RAM patch.zip I test (for a short time) my XP SP2 on other machines and probably no lag issue but this is fresh installed OS - no any drivers, apps. maybe lag issue is only on my SandyBridge machine recently I changed 2x4GB RAM - maybe they cause the problem? my OS has all drivers and many applications installed - maybe some application or driver works badly with a RAM patcher? I have to test the patch for a long time on other computers + all drivers installed. boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="RAM v3.5" /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="WinXP" /noexecute=optin /fastdetect This is my table when DEP/PAE works on WinXP SP2 depending on the setting of the noexecute option in boot.ini So, I do not have to use boot.ini switch /PAE because noexecute=optin is enough. Edited Monday at 05:15 AM by reboot12
user57 Posted Monday at 06:47 AM Posted Monday at 06:47 AM if /PAE is on windows dont load NTOSKRNL.exe windows then load NTKRNLPA.exe it often sounds like that the things are like very simple, like it can be done within 5 mins but rather often these projects are big. you cant just do like many of them i would be happy if that would be the case, but rather teamwork is required, one person doing all of these isnt possible rather if someone would try he would just have to much to do (and in the end probably no problem was solved) - thats why i didnt want to join a other project then xp for example - we have still a lot to do with xp this one is also not a small one if you dig into the paging system - there are books that describe that mechanism´s and norms (assembly books for example) + getting these into the ntoskrnl before boot the bios also prints out "i have 8 gb ram" the message in the first post also just shows windows saying it have that, but there is no confirmation that it actually is doing that to look for what the patch actually changed there are file compare app´s this is a free one : https://www.file-upload.net/download-15511527/fc.exe.html a small patch theoretical could do it just like that, that´s in range of possibilities with the file compare tool you can look the disassembled code, so you can see with what the patch(es) interferes so thank you to all that help with us, a testing maybe loading multiple apps/executables would be a good idea these running app´s actually should use up more then 4 GB in total, maybe some chrome instances that would tell us more about the functionality of this patch a bit more just 1 app/executable cant pass the 32 bit limit without a selector/segment selector, except maybe there would be the switch option (like the ramdisc is doing) however what the patch maybe could do is that different apps can be mapped to higher ram then 4 GB that only require the right pages that represent the higher area over 4 GB into different executables/app´s to say is that like 99,99 % of app´s/executables dont use selectors, and i never have seen them (also in win7-10) for the purpose to pass more then 4 GB ram the switch solution (like a ramdisc do) works a bit different you can store like 16 gb of ram, thats not the problem - but each time you want to access a certain ram you have to remap that data to an certain virtual offset (thats what a ramdisc is doing, that is very fast but its a piece wise solution) - that solution dont use a selector but - i dont think windows can do that yet but again over multiple executables there we dont have that problem - 4 GB for each running application sounds not bad
user57 Posted Monday at 11:39 PM Posted Monday at 11:39 PM On 10/25/2022 at 6:25 AM, j7n said: Sorry four the double post. I added 16 gigs of RAM to my other computer for a 20 in total. It works well without an E-MU/Creative Sound Card. Maybe components that come on motherboards are better tested because they may get installed in a "server" environment. I have nVidia, Realtek NIC, Realtek sound, Intel Ahci. Even a crash of CPU-Z doesn't happen anymore. None of task managers, etc. crash, Daemon Tools works, Yamaha SYXG works. This ram is really difficult to fill up intentionally. All programs restore up, including games, no complaints from the OS at 19 GB used. No swap file. something like this 1
Ascii2 Posted Tuesday at 12:31 AM Posted Tuesday at 12:31 AM (edited) 22 hours ago, reboot12 said: Yea, I use SP2: ntkrnl2.exe SP2 5.1.2600.2180 (patched by WinXPPAE 3.5 on SP2 OS) + hal2.dll SP3 5.1.2600.5512 (patched by WinXPPAE 3.5 on SP3 OS because the patcher cannot patches the hal.dll SP2 version) ntkrnl3.exe SP3 5.1.2600.5512 + hal3.dll SP3 5.1.2600.5512 - both patched by WinXPPAE 3.5 on SP3 OS ntkl64g.exe SP3 5.1.2600.6368 + hal64g.dll SP3 5.1.2600.5512 - files from @Dave-H 64 GB of RAM patch.zip I test (for a short time) my XP SP2 on other machines and probably no lag issue but this is fresh installed OS - no any drivers, apps. maybe lag issue is only on my SandyBridge machine recently I changed 2x4GB RAM - maybe they cause the problem? my OS has all drivers and many applications installed - maybe some application or driver works badly with a RAM patcher? I have to test the patch for a long time on other computers + all drivers installed. boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="RAM v3.5" /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="WinXP" /noexecute=optin /fastdetect This is my table when DEP/PAE works on WinXP SP2 depending on the setting of the noexecute option in boot.ini So, I do not have to use boot.ini switch /PAE because noexecute=optin is enough. What is rather apparent is that you are using the initial kernel and HAL releases, where compatible with the daniel_k HAL/NTKernel v3.5 patcher. Especially for Windows XP with Service Pack 2, it is important to use newer HALs than were initially released for newer hardware during that time period (which would now be considered older hardware). The systems could have rather annoying bugs otherwise. Your computer, given the hardware, is such a case. A newer kernel would be better, unless there is an important reason that you must stay with the older version. HAL updates were only distrusted as (downloadable) hotfixes; whereas, kernel updates were both in regular updates and hotfixes. With regards to not having to use the /PAE switch because "noexecute=optin is enough". That is not correct. The reason why you might find that the /PAE switch need not be specified for PAE in your case is because you are explicitly specifying and overriding the kernel and HAL to use ("/kernel=" and "/hal=") rather than relying on the otherwise default (potentially "/PAE"-influanced) selection. (See https://web.archive.org/web/20061224201614/http://www.microsoft.com/technet/sysinternals/information/bootini.mspx for a reference on the various arguments you may use in boot.ini.) You also still have not specified the variants/flavors of the kernels and HALs used. Make sure that you have correctly matched the HAL and kernel. Edited Tuesday at 02:32 AM by Ascii2
reboot12 Posted Tuesday at 03:46 AM Posted Tuesday at 03:46 AM 2 hours ago, Ascii2 said: With regards to not having to use the /PAE switch because "noexecute=optin is enough". That is not correct. No. /PAE switch load Ntkrnlpa.exe I use only like this and PAE works: /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll Enabling PAE Windows automatically enables PAE if DEP is enabled on a computer that supports hardware-enabled DEP The PAE kernel can be enabled automatically without the /PAE switch present in the boot entry if the system has DEP enabled (/NOEXECUTE switch is present) or the system processor supports hardware-enforced DEP. Presence of the /NOEXECUTE switch on a system with a processor that supports hardware-enforced DEP implies the /PAE switch. If the system processor is capable of hardware-enforced DEP and the /NOEXECUTE switch is not present in the boot entry, Windows assumes /NOEXECUTE=optin by default and enables PAE mode. You need use /NOPAE because default (optin) is enabled: https://web.archive.org/web/20060313135704/http://support.microsoft.com/kb/900524/
Ascii2 Posted Tuesday at 04:19 AM Posted Tuesday at 04:19 AM (edited) 33 minutes ago, reboot12 said: No. /PAE switch load Ntkrnlpa.exe I use only like this and PAE works: /noexecute=optin /fastdetect /kernel=ntkrnl2.exe /hal=hal2.dll Enabling PAE Windows automatically enables PAE if DEP is enabled on a computer that supports hardware-enabled DEP The PAE kernel can be enabled automatically without the /PAE switch present in the boot entry if the system has DEP enabled (/NOEXECUTE switch is present) or the system processor supports hardware-enforced DEP. Presence of the /NOEXECUTE switch on a system with a processor that supports hardware-enforced DEP implies the /PAE switch. If the system processor is capable of hardware-enforced DEP and the /NOEXECUTE switch is not present in the boot entry, Windows assumes /NOEXECUTE=optin by default and enables PAE mode. You need use /NOPAE because default (optin) is enabled: https://web.archive.org/web/20060313135704/http://support.microsoft.com/kb/900524/ I am not doubting that you have been able to the a PAE kernel to load. The /PAE switch appears to modify the bootloader configuration behavior towards selection to PAE, but does not override explicitly specification the kernel and HAL. Yes, there are various criteria that is evaluated to determine what the bootloader would load, but the criteria should not usually override explicit and compatible specification. With regards to your sources for the DEP default handling behavior, it is my impression that the evaluation mechanism is against hardware provided DEP (which is often an option on BIOS that is reasonably configurable). Where hardware DEP is detectable by the bootloader (perhaps because BIOS has the feature disabled), I do not believe the bootloader selection behavior would necessarily tend towards selection of a PAE kernel. I have never tested that, however. With regards to Windows XP with Service Pack 2 HAL updates, I have compiled a list of fixes that I think should be useful to you: For Windows XP Professioal with Service Pack 2 Install in ascending order: HAL updates (all in ascending order): KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB896256 - Computers that are running Windows XP Service Pack 2 and that are equipped with multiple processors that support processor power management features may experience decreased performance KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB951126 - A multiprocessor computer that is running Windows XP stops responding on a black screen after you resume the computer from hibernation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Only need, to fully update: KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Other Fixes of interest despite not being HAL: KB952117 - When you try to put a Windows XP-based computer into hibernation or into standby, the computer stops responding Edited Tuesday at 04:21 AM by Ascii2
reboot12 Posted Tuesday at 04:47 AM Posted Tuesday at 04:47 AM (edited) @Ascii2 I make big tests: using Macrium Reflect clone OS to other HDD - still problem replace RAM modules - still problem use only 2GB RAM 1+1 - still problem using Macrium Reflect make disk image, then restore on other PC - Haswell 8GB RAM (4+4 Dual Channel), OS boot, find new devices, I install drivers. I test and it looks like there is no problem and WinXPPAE 3.5 works well :-) I use exactly same patched files and settings: ntkrnl2.exe SP2 5.1.2600.2180 + hal2.dll SP3 5.1.2600.5512, noexecute=optin I have to use the system for some time to make sure 100% that there is no problem. It seems that the problem is only on SandyBridge machines. Edited Tuesday at 05:14 AM by reboot12
Dave-H Posted Tuesday at 06:09 PM Posted Tuesday at 06:09 PM OK, I decided to have a try with daniel_k's patch to see if it produced any different results to the one I was already using, which was linked to here. It took me a while to get it installed. As I have a multi-boot machine, my file paths are not standard, which caused the batch file to fail. For instance, the batch file contains many instances of the path "%SystemDrive%\Windows\". As my Windows XP installation is in D:\WIN-NT this did not of course work! The author should really have used "%WinDir%" I would have thought, unless I'm missing something. Do be aware of this if you try to use this patch on a system which doesn't use the standard paths. Anyway, once I'd edited the batch file so all the paths were correct for my system, it still didn't work. It said it couldn't open SP3.cab, so couldn't extract the files it needed to patch. Why I do not know, It warns that it needs to be run as Administrator, but apart from the fact that I am of course an Administrator user on the machine, there is no option to run the batch file as an administrator as far as I can see when the installation is on FAT32 drives. Maybe that wasn't the issue, but I could execute the commands fine manually in Command Prompt, the batch file just didn't seem able to do that itself. Very strange. Anyway, I did the whole thing that way, manually executing the lines in the batch file one by one, and it all seems to have worked. Everything looks exactly the same as with the previous patch, the browser is still falling over on Facebook. It's certainly a much more complicated install routine than the patch I was using first. How the other patch does it by just using two extra files added in System32 and a simple modification to boot.ini is a mystery to me. In the daniel_k patch, you have to specify what sort of machine it is (ACPI Multiprocessor in my case) to get the right HAL files. How the other patch does it without having that specified is impressive! I'll let you know how I get on now with this patch. Cheers, Dave.
reboot12 Posted Tuesday at 06:22 PM Posted Tuesday at 06:22 PM (edited) 21 minutes ago, Dave-H said: How the other patch does it without having that specified is impressive! This is not impressive - simply this is patched ntkrpamp.exe for multi CPU/multi core use: Modern computers have multi-core processors and the use of RAM patch on old PC does not make sense because old computers with a single-core processor do not support a large amount of RAM and a patch is not needed. Therefore, the 64G patch does not contain other kernal and hal files. Edited Tuesday at 06:32 PM by reboot12
Dave-H Posted Tuesday at 06:38 PM Posted Tuesday at 06:38 PM So it would be a waste of time installing daniel_k's patch on a uniprocessor machine anyway? I wonder why he bothered to include the option! So, do you think the two patches I've tried are actually doing exactly the same thing, so there's no advantage of one over the other? One isn't making the extra RAM any more accessible to programs or the system than the other, for instance?
reboot12 Posted Tuesday at 06:52 PM Posted Tuesday at 06:52 PM (edited) 53 minutes ago, Dave-H said: So, do you think the two patches I've tried are actually doing exactly the same thing, so there's no advantage of one over the other? I don't know, but if you compare patched kernel files 5.1.2600.6368 in a hex editor and are changed exactly the same bytes in the same offsets, it means that they work the same. You must first patch using a patcher v3.5 kernel file 5.1.2600.6368 ntkrnlpa.exe 5.1.2600.6368 > https://catalog.update.microsoft.com/Search.aspx?q=2813170 WinXPPAE.bat script default patch all RAM: WinXPPAE.exe /M:ALL /NOBACKUP so, put ntkrnlpa.exe (GDR version) and WinXPPAE.exe in same folder then patch as above: winxppae /M:ALL Windows XP PAE Patcher 3.0 by daniel_k | HAL patches by <Mov AX, 0xDEAD> PAE will be enabled using all available RAM. Patching ntkrnlpa.exe (Uniprocessor PAE Kernel)... OK! File ntkrpamp.exe (Multiprocessor PAE Kernel) was not found. File hal.dll (Standard PC/Standard PC w/ C-Step i486 HAL) was not found. File halaacpi.dll (ACPI Uniprocessor PC HAL) was not found. File halacpi.dll (ACPI PC HAL) was not found. File halapic.dll (MPS Uniprocessor PC HAL) was not found. File halmacpi.dll (ACPI Multiprocessor PC HAL) was not found. File halmps.dll (MPS Multiprocessor PC HAL) was not found. No, this is not simple to compare - too big differences :-( Probably ntkl64g.exe is compiled from source code. org vs v35 differ only in 11 bytes: Search for differences 1. org_ntkrnlpa.exe: 2 070 016 bytes 2. 35_ntkrnlpa.exe: 2 070 016 bytes Offsets: hexadec. 138: C2 04 139: FF 03 13A: 1F 20 16B632: 07 00 16B637: 01 02 1703C2: 74 EB 1BE554: 10 00 1BE555: 00 02 1BE56A: 1B 00 1BE572: FC F8 1BE576: 01 02 11 difference(s) found. Edited Tuesday at 07:32 PM by reboot12
user57 Posted Tuesday at 11:11 PM Posted Tuesday at 11:11 PM i dont know but the name "ntkrln64g" sounds like it is a wrapper, maybe a kernel extender ? if not there like many versions of ntoskrnl´s you have to find the right version in that case the searched patches show 7 changes 138-13a is probaly the checksum, that checksum is a "elder driver signature" - if that one isnt currect the system driver (in this case the important ntoskrnl) is not loaded as you may reconized that patch did not touch that ntkrpamp.exe, you should check what ntoskrl was loaded (there are only 3, ntkrnlpa, ntoskrnl and ntkrpamp to check if it use up more then 4 gb ram you should repeat the test from page 7, there is also a page-file that actually can pass that limit you might turn that one off while doing that test
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now