Jump to content

Get Windows XP x86 to recognize more than 4Gb with PAE?


AnX

Recommended Posts

Tomasz had modded the Windows XP x86 ntkrnlpa.exe so that it would support more than 4 gigs in PAE and it recognized all 8 gigs, my question is, how do I do that in XP?

Link to comment
Share on other sites


While I don't agree (at all) with doing this as it violates the EULA and license you have to run a Windows client OS, as well as cripples the OS kernel in many ways, Geoff Chappell has an article about how the 4GB restriction on client OSes can be bypassed here. If you want to use more than 4GB of RAM with an actual legally licensed copy of Windows client, however, you need an x64 license.

Read the whole sticky and *all* the links offered thereof at least twice. Then you'll be up to date on the matter.

Link to comment
Share on other sites

Right thread, but outdated post. This is the current one.

Now, a little contribution:

halmacpi.dll 5.1.2600.5574 (xpsp_sp3_qfe.080402-1256) from KB951126 => Patch at 0x17813 (same offset in 5574_qfe as in 5512).

ntkrpamp.exe 5.1.2600.6419 (xpsp_sp3_qfe.130704-0421) from KB2859537 ==> Patch at 0x15EF1A & 0x1B3A51 (offsets in 6419_qfe do differ from those in 5512).

usbport.sys 5.2.3790.5203 (srv03_sp2_qfe.130720-0956) from KB2862330 is also required, but needs no patching.

Of course, all the above offsets are for the ENU versions of the files mentioned.

I strongly recommend using the reliable n7epsilon's pechecksum.exe v. 1.4 for the mandatory checksum correction.

Link to comment
Share on other sites

As you can see, my windows is localized, so the offsets are different.

" - patch ntkrpamp.exe at offset 0x15DF1A from 75 1B to 90 90 " <- in my ntkrnlpa.exe 5.1.2600.6419 it is not 75 1B.

There are some calls to ExVerifySuite(x):

PAGE:0049CF88 loc_49CF88:                             ; CODE XREF: IoDeleteSymbolicLink(x)+4EjPAGE:0049CF88                 call    _ObIsLUIDDeviceMapsEnabled@0 ; ObIsLUIDDeviceMapsEnabled()PAGE:0049CF8D                 test    eax, eaxPAGE:0049CF8F                 jnz     short loc_49CFA2PAGE:0049CF91                 push    4PAGE:0049CF93                 call    _ExVerifySuite@4 ; ExVerifySuite(x)PAGE:0049CF98                 cmp     al, 1PAGE:0049CF9A                 jnz     short loc_49CFA2PAGE:0049CF9C                 push    ebxPAGE:0049CF9D                 call    _IopDeleteSessionSymLinks@4 ; IopDeleteSessionSymLinks(x)
PAGELK:0057550D loc_57550D:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+BEjPAGELK:0057550D                 cmp     ebx, ecxPAGELK:0057550F                 jnb     short loc_5754ECPAGELK:00575511                 push    7PAGELK:00575513                 call    _ExVerifySuite@4 ; ExVerifySuite(x)PAGELK:00575518                 cmp     al, 1PAGELK:0057551A                 jnz     short loc_575523PAGELK:0057551C                 mov     eax, 1000000hPAGELK:00575521                 jmp     short loc_575544PAGELK:00575523 ; ═════════════════════════════════════════════════════════════PAGELK:00575523PAGELK:00575523 loc_575523:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+D8jPAGELK:00575523                 cmp     _MmProductType, 690057hPAGELK:0057552D                 jz      short loc_57553FPAGELK:0057552F                 push    1PAGELK:00575531                 call    _ExVerifySuite@4 ; ExVerifySuite(x)PAGELK:00575536                 cmp     al, 1PAGELK:00575538                 mov     eax, 800000hPAGELK:0057553D                 jz      short loc_575544PAGELK:0057553FPAGELK:0057553F loc_57553F:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+EBjPAGELK:0057553F                 mov     eax, 100000hPAGELK:00575544PAGELK:00575544 loc_575544:                             ; CODE XREF: MmAddPhysicalMemoryEx(x,x,x)+DFjPAGELK:00575544                                         ; MmAddPhysicalMemoryEx(x,x,x)+FBjPAGELK:00575544                 mov     ecx, _MmNumberOfPhysicalPagesPAGELK:0057554A                 lea     edx, [ecx+esi]PAGELK:0057554D                 cmp     edx, eaxPAGELK:0057554F                 jbe     short loc_57555BPAGELK:00575551                 sub     eax, ecxPAGELK:00575553                 mov     esi, eaxPAGELK:00575555                 lea     eax, [esi+ebx]PAGELK:00575558                 mov     [ebp+arg_8], eax
PAGELK:0057A4E9 loc_57A4E9:                             ; CODE XREF: MmCreateMirror()+21jPAGELK:0057A4E9                 push    7PAGELK:0057A4EB                 call    _ExVerifySuite@4 ; ExVerifySuite(x)PAGELK:0057A4F0                 cmp     al, 1PAGELK:0057A4F2                 jz      short loc_57A515PAGELK:0057A4F4                 cmp     _MmProductType, 690057hPAGELK:0057A4FE                 jz      short loc_57A50BPAGELK:0057A500                 push    1PAGELK:0057A502                 call    _ExVerifySuite@4 ; ExVerifySuite(x)PAGELK:0057A507                 cmp     al, 1PAGELK:0057A509                 jz      short loc_57A515PAGELK:0057A50BPAGELK:0057A50B loc_57A50B:                             ; CODE XREF: MmCreateMirror()+42jPAGELK:0057A50B                 mov     eax, 0C000026AhPAGELK:0057A510                 jmp     loc_57A93A
So which should be changed to NOPs? Edited by roytam1
Link to comment
Share on other sites

I'm sorry, but, with all due respect, I have not time nor interest in studying any localized versions (BRZ included).

Nor do I have your specific localized (CHT or CHS, I guess...) files to study, in case I found some time to do it.

If you grab the ENU version and compare it with the localized one, you'll surely find out the correct offsets.

Good luck!

BTW, IDA offsets are for the loaded executable, whereas the patching offsets refer to the binary file image before it's loaded, which can be found instead with an hexeditor. Moreover 0x75 means jnz, so the last of the 4 calls shown in you post cannot be the correct place to patch (because it contains no jnz). OK. Get yourself an hexeditor capable of hexstring searching and search for 0x3C017507B8 (for the 1st patch) and 0x3C01751B39 (for the 2nd one). I bet you'll find one occurrence only of each string, even in your localized version, and, if so, then just patch the 0x75XX to 0x9090 in each string, as required. Disclaimer: I guarantee nothing and you agree that whatever you do you do by your own decision and accept all responsibility for the results from your actions.

Much later additions:

For halmacpi.dll, the hexstring to search for is 0x537417803D (and once found, then patch the 0x74 to 0xEB).

These hexstrings ought to be unique (= appear just once in the executable file one intends to patch), and should be universal (= exist in whatever localized version one is intending to patch). HTH

Link to comment
Share on other sites

I'm sorry, but, with all due respect, I have not time nor interest in studying any localized versions (BRZ included).

Nor do I have your specific localized (CHT or CHS, I guess...) files to study, in case I found some time to do it.

If you grab the ENU version and compare it with the localized one, you'll surely find out the correct offsets.

Good luck!

BTW, IDA offsets are for the loaded executable, whereas the patching offsets refer to the binary file image before it's loaded, which can be found instead with an hexeditor. Moreover 0x75 means jnz, so the last of the 4 calls shown in you post cannot be the correct place to patch (because it contains no jnz). OK. Get yourself an hexeditor capable of hexstring searching and search for 0x3C017507B8 (for the 1st patch) and 0x3C01751B39 (for the 2nd one). I bet you'll find one occurrence only of each string, even in your localized version, and, if so, then just patch the 0x75XX to 0x9090 in each string, as required. Disclaimer: I guarantee nothing and you agree that whatever you do you do by your own decision and accept all responsibility for the results from your actions.

Much later additions:

For halmacpi.dll, the hexstring to search for is 0x537417803D (and once found, then patch the 0x74 to 0xEB).

These hexstrings ought to be unique (= appear just once in the executable file one intends to patch), and should be universal (= exist in whatever localized version one is intending to patch). HTH

hal.dll hal.dll+8bc7 0x806e6000 0x80706d80 0x00020d80 0x47f3693d 2/4/2008 19:08:45

NDIS.sys NDIS.sys+19530 0xf6d82000 0xf6dae980 0x0002c980 0x48025d03 14/4/2008 03:20:35

ntoskrnl.exe ntoskrnl.exe+79d30 0x804d8000 0x806e6000 0x0020e000 0x51d4d90f 4/7/2013 10:08:15

I got a crash today. The offsets changed are as you posted before.

I use /hal= and /kernel= switch for loading modified files.

Link to comment
Share on other sites

I got a crash today. The offsets changed are as you posted before.

I use /hal= and /kernel= switch for loading modified files.

But... let me understand this right:

1. ) You located the points to patch using the search hexstrings I provided, instead of fixed offsets, right?

2. ) You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right?

3. ) You replaced usbport.sys by the one reccommended, right?

4. ) It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right?

If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please.

Now... You've got a crash. Was it a BSOD? Was it a Black Screen? Was it a Full Freeze? Or did the machine just turn off?

And what exactly were you doing at that precise moment? Please do bear with me, my crystal ball is out on the shop, for tunning (again!).

Link to comment
Share on other sites

I got a crash today. The offsets changed are as you posted before.

I use /hal= and /kernel= switch for loading modified files.

But... let me understand this right:

1. ) You located the points to patch using the search hexstrings I provided, instead of fixed offsets, right?

2. ) You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right?

3. ) You replaced usbport.sys by the one reccommended, right?

4. ) It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right?

If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please.

Now... You've got a crash. Was it a BSOD? Was it a Black Screen? Was it a Full Freeze? Or did the machine just turn off?

And what exactly were you doing at that precise moment? Please do bear with me, my crystal ball is out on the shop, for tunning (again!).

both 1 to 4 are "Yes".

screenshot: http://i.imgur.com/YtnYYBn.png

and the crash was BSoD.

in that moment I was messing Win 8.1 VM(1GB RAM, 32bit) using VMPlayer 5.0.2.

dumpchk thinks VPCNetS2.sys cause the crash and I removed it now.

windbg !analyze -v report:

READ_ADDRESS:  f7b5b000CURRENT_IRQL:  2FAULTING_IP:hal!HalpMovntiCopyBuffer+f806eebc7 8b06            mov     eax,dword ptr [esi]CUSTOMER_CRASH_COUNT:  1DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0xAPROCESS_NAME:  IdleLAST_CONTROL_TRANSFER:  from 806ea404 to 806eebc7STACK_TEXT:  80551d30 806ea404 8a2a3ffe f7b5affe 00000002 hal!HalpMovntiCopyBuffer+0xf80551d50 806eb295 f7b5affe 8b2c2ef8 00000002 hal!HalpCopyBufferMap+0xb680551d9c 806ea62e 88ad4880 878cfc20 012c2ed4 hal!HalpMapTransfer+0x17980551dec 806eb6e4 8923b3f8 00000000 8b2c2ed4 hal!HalpAllocateAdapterCallback+0xa280551e18 806eacd9 02ad4880 8c18f324 00000006 hal!HalAllocateAdapterChannel+0x12680551e3c f6d9b4fe 88ad4880 8923b3f8 00000088 hal!HalBuildScatterGatherList+0x22380551e94 f6d82a08 86aceae8 8820d008 881ad140 NDIS!ndisMAllocSGList+0xd980551eb0 f75bb3e7 8820d600 86acea80 881ad140 NDIS!ndisMSendX+0x1a0WARNING: Stack unwind information not available. Following frames may be wrong.80551f00 f6d82985 8820d000 881ad140 00000002 VPCNetS2+0x43e780551f28 ae051d40 8815c008 881ad140 88157840 NDIS!ndisMSendX+0x1d680551f50 ae051916 88157840 881ad140 87494b88 tcpip!ARPSendData+0x19880551f7c ae05165a 88157840 80551f02 00000001 tcpip!ARPTransmit+0x19380551fac ae05179f 8816e888 8da8a8c0 881ad140 tcpip!SendIPPacket+0x193805520f8 ae055b07 ae08fb98 86bb9a28 86bb99c0 tcpip!IPTransmit+0x289e80552164 ae055923 11b5157f 00000002 00000000 tcpip!TCPSend+0x5d880552188 ae04ea0e 00000002 00000002 805521b4 tcpip!ProcessPerCpuTCBDelayQ+0x95805521bc ae04e955 00000002 ae04e901 ae04e3d6 tcpip!ProcessTCBDelayQ+0xc4805521c8 ae04e3d6 00000000 8917f130 ae04e7f8 tcpip!TCPRcvComplete+0x20805521d4 ae04e7f8 f6da4c40 88157840 00000000 tcpip!IPRcvComplete+0x21805521d8 f6da4c40 88157840 00000000 8746e710 tcpip!ARPRcvComplete+0x580552228 f75bb74b 00382d98 80552250 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a48055226c f6da4b9f 8820d000 883b0120 00000000 VPCNetS2+0x474b805522a8 f63b6888 00000001 883b00e8 88379000 NDIS!ethFilterDprIndicateReceivePacket+0x1c2805522b8 882102f8 805523f8 f63b87cf 00382d98 Rtenicxp+0xd888805522bc 805523f8 f63b87cf 00382d98 80552360 0x882102f8805522c0 f63b87cf 00382d98 80552360 00000001 nt!KiDoubleFaultStack+0x2cf8805523f8 f63bbf92 88439578 8923b4f8 88ac3f90 Rtenicxp+0xf7cf80552410 f6d9ae99 88ac3000 8055d0c0 ffdff9c0 Rtenicxp+0x12f9280552428 80546f9f 88ac3fa4 88ac3f90 00000000 NDIS!ndisMDpcX+0x2180552450 80546e84 00000000 0000000e 00000000 nt!KiRetireDpcList+0x6180552454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28STACK_COMMAND:  kbFOLLOWUP_IP:VPCNetS2+43e7f75bb3e7 ??              ???SYMBOL_STACK_INDEX:  8SYMBOL_NAME:  VPCNetS2+43e7FOLLOWUP_NAME:  MachineOwnerMODULE_NAME: VPCNetS2IMAGE_NAME:  VPCNetS2.sysDEBUG_FLR_IMAGE_TIMESTAMP:  3e1f20e0FAILURE_BUCKET_ID:  0xA_VPCNetS2+43e7BUCKET_ID:  0xA_VPCNetS2+43e7
Edited by roytam1
Link to comment
Share on other sites

I got a crash today. The offsets changed are as you posted before.

I use /hal= and /kernel= switch for loading modified files.

But... let me understand this right:

1. ) You located the points to patch using the search hexstrings I provided, instead of fixed offsets, right?

2. ) You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right?

3. ) You replaced usbport.sys by the one reccommended, right?

4. ) It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right?

If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please.

both 1 to 4 are "Yes".

Then, congratulations! :thumbup

Now, was only because of your instigation that I came upon the idea of small unique search hexstrings unlike to change on localization as a method providing universal patches... and your success using them on a CHT version (which I did not investigate, all my work was done on the ENU version) constitutes the proof-of-concept for this method. So thanks! :yes:

Now, as for your BSOD: if your debugging is right (and I do think it is), then the problem is solved for now. Let at least one week of intensive use pass before putting VPCNetS2.sys back. If no other BSOD happens, I think you can consider VPCNetS2.sys really was the source of the problem. In that case, maybe searching for a later, newer version of that file might be in order. Let's wait and see. Of course, please do keep me posted on what happens next, OK?

Link to comment
Share on other sites

I got a crash today. The offsets changed are as you posted before.

I use /hal= and /kernel= switch for loading modified files.

 

But... let me understand this right:

1. )  You located the points to patch using the search hexstrings I provided, instead of  fixed offsets, right?

2. )  You fixed the checksums, using pechecksum.exe (as recommended) or using modifype.exe, right?

3. )  You replaced usbport.sys by the one reccommended, right?

4. )  It worked, right? Your XP machine became able to see and access more that 4 GiB RAM, right?

 

If all the above is right, please do post a new screenshot of the machine's My Computer's Properties, please.

 

both 1 to 4 are "Yes".

 

Then, congratulations! :thumbup

 

Now, was only because of your instigation that I came upon the idea of small unique search hexstrings unlike to change on localization as a method providing universal patches...  and your success using them on a CHT version (which I did not investigate, all my work was done on the ENU version) constitutes the proof-of-concept for this method. So thanks! :yes:

 

Now, as for your BSOD: if your debugging is right (and I do think it is), then the problem is solved for now. Let at least one week of intensive use pass before putting VPCNetS2.sys back. If no other BSOD happens, I think you can consider VPCNetS2.sys really was the source of the problem. In that case, maybe searching for a later, newer version of that file might be in order. Let's wait and see. Of course, please do keep me posted on what happens next, OK?

I got another BSoD now.

 

 

READ_ADDRESS:  f7b22000CURRENT_IRQL:  2FAULTING_IP:hal!HalpMovntiCopyBuffer+f806eebc7 8b06            mov     eax,dword ptr [esi]CUSTOMER_CRASH_COUNT:  2DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0xAPROCESS_NAME:  taskmgr.exeLAST_CONTROL_TRANSFER:  from 806ea404 to 806eebc7STACK_TEXT:  f78aae18 806ea404 8a2a7ffe f7b21ffe 00000002 hal!HalpMovntiCopyBuffer+0xff78aae38 806eb295 f7b21ffe 8c063cc0 00000002 hal!HalpCopyBufferMap+0xb6f78aae84 806ea62e 879845a0 883883e8 01063c9c hal!HalpMapTransfer+0x179f78aaed4 806ea85c 8799d750 00000000 8c063c9c hal!HalpAllocateAdapterCallback+0xa2f78aaefc 806eada2 029845a0 8c19520c 0000002d hal!IoFreeMapRegisters+0xcef78aaf24 f6d9b5c5 879845a0 8c063ccc 00000001 hal!HalPutScatterGatherList+0xacf78aaf3c f6d97be4 87986f20 87986000 00000000 NDIS!ndisMFreeSGList+0x25f78aaf54 a7cf7364 8799d850 87d804e0 00000000 NDIS!ndisMSendCompleteX+0x34WARNING: Stack unwind information not available. Following frames may be wrong.f78aaf78 a7cf7e17 87d804e0 8795a2cc 80541b40 Rtenicxp+0x1c364f78aaf9c a7cf2588 87986000 8799d850 87987030 Rtenicxp+0x1ce17f78aafb4 f6d9ae99 87986000 87831268 ffdff9c0 Rtenicxp+0x17588f78aafcc 80546f9f 87987044 87987030 00000000 NDIS!ndisMDpcX+0x21f78aaff4 80546b0b aa2ea6cc 00000000 00000000 nt!KiRetireDpcList+0x61f78aaff8 aa2ea6cc 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2b80546b0b 00000000 00000009 0081850f bb830000 0xaa2ea6ccSTACK_COMMAND:  kbFOLLOWUP_IP:Rtenicxp+1c364a7cf7364 ??              ???SYMBOL_STACK_INDEX:  8SYMBOL_NAME:  Rtenicxp+1c364FOLLOWUP_NAME:  MachineOwnerMODULE_NAME: RtenicxpIMAGE_NAME:  Rtenicxp.sysDEBUG_FLR_IMAGE_TIMESTAMP:  52cbad18FAILURE_BUCKET_ID:  0xA_Rtenicxp+1c364BUCKET_ID:  0xA_Rtenicxp+1c364  Probably caused by : Rtenicxp.sys ( Rtenicxp+1c364 )
Link to comment
Share on other sites

Here's what I think: kondra's patches to ntkrpamp.exe are well understood and tested up already and the 2k3 usbport.sys is safe, so if anything may be wrong, whatever it is, it must be with the much more recent friendship7's patch to halmacpi.dll... so... try falling back to your copy of XP SP1 halmacpi.dll, and let's see what happens: if no more BSOD's, you're good for now, and we must look deeper into the patching of halmacpi.dll...

Link to comment
Share on other sites

Well, Andre sure has a point! Yes. Update the drive first. If the BSOD's go away, fine.

If not, then fall back to the XP SP1 halmacpi.dll, at least to help us determine whether the problem is with the patched halmacpi.dll or not.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...