How I overcame the 4GB limit on Windows XP 32bit
Immediately make a reservation, “overcome” in the title reflects only the fact that now my XP sees all the memory installed on the motherboard. I did not think of a way, I just used it and now I want to share it.
The question of four gigabytes of memory in Windows XP (here, and then 32 bits) was raised on the Internet repeatedly. And it was also repeatedly concluded that it is impossible to see more than four in principle, and since the equipment also requires address space, it is even less. Usually 3.25 GB or so. Very detailed and convincingly the history of the issue is highlighted here: Four gigabytes of memory is an unattainable goal?
I was also worried about this question. Although, it would seem, you can put a 64-bit system, or even a Windows Server (as you know, it even sees the entire memory in the 32-bit version), but I wanted to use Windows XP. Twice in the last 3 years, I switched to Windows 7, the first time to 64-bit, the second time to 32-bit, but in the end, both times went back to XP, which has been living with me without reinstalling since 2007.
The last time I abandoned the seven in favor of the old woman literally two weeks ago. Moreover, it should be noted that the seven was at least 32-bit, but it was unlocked the ability to see all the available memory. Unlock method is available on the Internet. And now, with a new force, I wanted to resolve this issue in XP.
Searches led to this site: Patch Vista's Kernel to Address more than 4 GB of Memory
The article is devoted to unlocking Windows Vista, but in the comments, a couple of people describe a similar method for Windows XP. I decided to follow their advice and try out this technique in practice.
')
First you need a Windows XP SP1 distribution. Perhaps, just the first service pack will work, I don’t know, I don’t have it. In general, only one file is needed there. Namely, the library file Hardware Abstraction Layer. Starting from the second service pack, this library works with PAE “fictitiously”, i.e. even if the extended address translation mode is enabled - it does nothing and does not go beyond four gigabytes. But the library from the first service pack works fully and can be addressed to all available memory, in the same way as 32-bit Windows Server works with memory. In the installed Windows XP, this file is called hal.dll, but there are several HAL files in the distribution, and only one of them is installed into the system under the name hal.dll during the installation process. It was necessary to find out which of the files should be used on my specific equipment. This is done simply, you need to call Properties in the context menu of the explorer on the hal.dll file in the installed Windows. The file is located in the% systemroot% \ system32 folder, and this is what I saw:
In the Windows XP SP1 distribution in the I386 folder, I took the HALMACPI.DL_ file. This is the archive in which there is one file that halmacpi.dll is looking for. I extracted it with WinRAR, but you can do with the command line:
expandable HALMACPI.DL_ HALMACPI.DLL
The resulting file must be placed in the% systemroot% \ system32 folder, which I did. I want to note once again that if someone wants to repeat my steps, the file must be taken with the name specified in the property “Original file name” in the properties of hal.dll from the installed Windows XP.
The second thing you need to do is get the patched version of the Windows kernel. As you know, there are 4 kernel versions:
In the instruction that I used, it was said about the kernel ntkrnlpa.exe and in my installation of Windows it is worth it. What to do if another core comes across - I honestly do not know.
First of all, I made a copy of the kernel, called it krnl16.exe, in principle, the name does not matter. Next HEX-editor (I used DOS-Navigator, the old memory) need to find the sequence
Here 1000h = 4096 MB, replaced by 4000h = 16384 MB. Those. raise the limit to 16GB. In principle, you can enter a larger number. The patched file should also be located in system32.
Now it remains to edit the boot.ini. You need to copy the existing line and add a couple of parameters. I had the line:
multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS.XP = "Microsoft Windows XP Professional RU" / FASTDETECT / USEPMTIMER / NOSERIALMICE / NOEXECUTE = OPTIN
I added /KERNEL=KRNL16.EXE /HAL=HALMACPI.DLL / PAE to it and the result was:
multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS.XP = "Microsoft Windows XP Professional RU 16Gb" / FASTDETECT / USEPMTIMER / NOSERIALMICE / NOEXECUTE = OPTIN /KERNEL=KRNL16.EXE / HAL = HALMACPI. DLL / PAE
Now it is possible to boot into the standard Windows with its inherent memory limit, as well as into the patched one, since I did not replace a single system file, but only added two, which are included in the work using the above boot.ini parameters
Reboot!
And ... BSOD.
In principle, this can be. As follows from the review of the history of the problem on ixbt, the reason why Microsoft turned off the addressing of the upper memory was the existence of driver curves for different equipment, the curvature of which, however, manifested itself only in the full mode of PAE. It is likely that one of them fails, for 6 years a lot of things have accumulated in the system, but which one? I try to run in safe mode, and Hurray! Here they are, my gigabytes:
But how to determine the failed module? Googling, I found a technique for this, which is to analyze a small memory dump created by Windows during a BSOD. The analysis is performed by the Blue Screen View program, but all the methods I found to enable the recording mode did not lead to success: the dump was not created, so I had to use the scientific method of typing. To begin, I uninstalled what was unnecessary in the system. Namely Guardant protection driver and ATI driver from an old video card.
Reboot.
The result exceeded my expectations. Honestly, I didn’t expect the spear method to produce such results, and I tried it just to do anything. Which driver caused the problem, I don’t know for sure, but I think that most likely Guardant.
But the main thing: the goal is achieved, and now I'm thinking about expanding the memory to 8 GB.
The question of four gigabytes of memory in Windows XP (here, and then 32 bits) was raised on the Internet repeatedly. And it was also repeatedly concluded that it is impossible to see more than four in principle, and since the equipment also requires address space, it is even less. Usually 3.25 GB or so. Very detailed and convincingly the history of the issue is highlighted here: Four gigabytes of memory is an unattainable goal?
I was also worried about this question. Although, it would seem, you can put a 64-bit system, or even a Windows Server (as you know, it even sees the entire memory in the 32-bit version), but I wanted to use Windows XP. Twice in the last 3 years, I switched to Windows 7, the first time to 64-bit, the second time to 32-bit, but in the end, both times went back to XP, which has been living with me without reinstalling since 2007.
The last time I abandoned the seven in favor of the old woman literally two weeks ago. Moreover, it should be noted that the seven was at least 32-bit, but it was unlocked the ability to see all the available memory. Unlock method is available on the Internet. And now, with a new force, I wanted to resolve this issue in XP.
Searches led to this site: Patch Vista's Kernel to Address more than 4 GB of Memory
The article is devoted to unlocking Windows Vista, but in the comments, a couple of people describe a similar method for Windows XP. I decided to follow their advice and try out this technique in practice.
')
First you need a Windows XP SP1 distribution. Perhaps, just the first service pack will work, I don’t know, I don’t have it. In general, only one file is needed there. Namely, the library file Hardware Abstraction Layer. Starting from the second service pack, this library works with PAE “fictitiously”, i.e. even if the extended address translation mode is enabled - it does nothing and does not go beyond four gigabytes. But the library from the first service pack works fully and can be addressed to all available memory, in the same way as 32-bit Windows Server works with memory. In the installed Windows XP, this file is called hal.dll, but there are several HAL files in the distribution, and only one of them is installed into the system under the name hal.dll during the installation process. It was necessary to find out which of the files should be used on my specific equipment. This is done simply, you need to call Properties in the context menu of the explorer on the hal.dll file in the installed Windows. The file is located in the% systemroot% \ system32 folder, and this is what I saw:
In the Windows XP SP1 distribution in the I386 folder, I took the HALMACPI.DL_ file. This is the archive in which there is one file that halmacpi.dll is looking for. I extracted it with WinRAR, but you can do with the command line:
expandable HALMACPI.DL_ HALMACPI.DLL
The resulting file must be placed in the% systemroot% \ system32 folder, which I did. I want to note once again that if someone wants to repeat my steps, the file must be taken with the name specified in the property “Original file name” in the properties of hal.dll from the installed Windows XP.
The second thing you need to do is get the patched version of the Windows kernel. As you know, there are 4 kernel versions:
- ntoskrnl.exe is a single-processor Windows kernel.
- ntkrnlmp.exe is a multiprocessor Windows kernel.
- ntkrnlpa.exe is a single-processor Windows kernel with more than 3 GB of RAM.
- ntkrpamp.exe is a multiprocessor Windows kernel with more than 3 GB of RAM.
In the instruction that I used, it was said about the kernel ntkrnlpa.exe and in my installation of Windows it is worth it. What to do if another core comes across - I honestly do not know.
First of all, I made a copy of the kernel, called it krnl16.exe, in principle, the name does not matter. Next HEX-editor (I used DOS-Navigator, the old memory) need to find the sequence
- BB 00 00 10 00 33 FF 6A 07 8B F0 and replace it with
- BB 00 00 40 00 33 FF 6A 07 8B F0
Here 1000h = 4096 MB, replaced by 4000h = 16384 MB. Those. raise the limit to 16GB. In principle, you can enter a larger number. The patched file should also be located in system32.
Now it remains to edit the boot.ini. You need to copy the existing line and add a couple of parameters. I had the line:
multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS.XP = "Microsoft Windows XP Professional RU" / FASTDETECT / USEPMTIMER / NOSERIALMICE / NOEXECUTE = OPTIN
I added /KERNEL=KRNL16.EXE /HAL=HALMACPI.DLL / PAE to it and the result was:
multi (0) disk (0) rdisk (0) partition (1) \ WINDOWS.XP = "Microsoft Windows XP Professional RU 16Gb" / FASTDETECT / USEPMTIMER / NOSERIALMICE / NOEXECUTE = OPTIN /KERNEL=KRNL16.EXE / HAL = HALMACPI. DLL / PAE
Now it is possible to boot into the standard Windows with its inherent memory limit, as well as into the patched one, since I did not replace a single system file, but only added two, which are included in the work using the above boot.ini parameters
Reboot!
And ... BSOD.
In principle, this can be. As follows from the review of the history of the problem on ixbt, the reason why Microsoft turned off the addressing of the upper memory was the existence of driver curves for different equipment, the curvature of which, however, manifested itself only in the full mode of PAE. It is likely that one of them fails, for 6 years a lot of things have accumulated in the system, but which one? I try to run in safe mode, and Hurray! Here they are, my gigabytes:
But how to determine the failed module? Googling, I found a technique for this, which is to analyze a small memory dump created by Windows during a BSOD. The analysis is performed by the Blue Screen View program, but all the methods I found to enable the recording mode did not lead to success: the dump was not created, so I had to use the scientific method of typing. To begin, I uninstalled what was unnecessary in the system. Namely Guardant protection driver and ATI driver from an old video card.
Reboot.
The result exceeded my expectations. Honestly, I didn’t expect the spear method to produce such results, and I tried it just to do anything. Which driver caused the problem, I don’t know for sure, but I think that most likely Guardant.
But the main thing: the goal is achieved, and now I'm thinking about expanding the memory to 8 GB.
- Note 1. As the technique uses the dll from the first service pack, it is likely that it contains any vulnerabilities that are closed by subsequent service packs. I have not studied this question.
- Note 2. Some drivers in the patched Windows XP can cause a BSOD. However, they are extremely small in nature.
- Note 3. In the original source of valuable knowledge , it is reported that some systems have problems with USB when using this technique. I have no problems yet. At least, keyboards, mice and flash drives work in normal mode.
Source: https://habr.com/ru/post/202406/
All Articles