Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


AnX

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

Recommended Posts

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.

I did update it to latest version downloadable in realtek.com, but same BSoD happens.

Share this post


Link to post
Share on other sites

I have also tried to manually patch the files using dencorso's method. It resulted in the boot process getting stuck.

Searching further I found the Chinese XP64G patch. I assumed it was only for Chinese or English systems, but it also seems to work just fine with other localized kernel files. The patch does not alter the ntoskrnl file directly, but creates a copy and adds a separate boot entry.

Comparing the differences between methods I found that the Chinese patch also modifies the following bytes in hal.dll at 0x1DCFF:

10 68 00 00 00 01 53 C7 05 C4 32 02 80 40 00 00 00 BE 00 00 01

to:

30 68 FF FF FF FF 53 C7 05 C4 32 02 80 00 40 00 00 BE 00 00 03

Share this post


Link to post
Share on other sites

I have also tried to manually patch the files using dencorso's method. It resulted in the boot process getting stuck.

Searching further I found the Chinese XP64G patch. I assumed it was only for Chinese or English systems, but it also seems to work just fine with other localized kernel files. The patch does not alter the ntoskrnl file directly, but creates a copy and adds a separate boot entry.

Comparing the differences between methods I found that the Chinese patch also modifies the following bytes in hal.dll at 0x1DCFF:

10 68 00 00 00 01 53 C7 05 C4 32 02 80 40 00 00 00 BE 00 00 01
to:

30 68 FF FF FF FF 53 C7 05 C4 32 02 80 00 40 00 00 BE 00 00 03

the assembly code around this is:

INIT:8002DCF5 loc_8002DCF5:                           ; CODE XREF: HalInitSystem(x,x)+307jINIT:8002DCF5                 mov     _HalpPhysicalMemoryMayAppearAbove4GB, 1INIT:8002DCFCINIT:8002DCFC loc_8002DCFC:                           ; CODE XREF: HalInitSystem(x,x)+30FjINIT:8002DCFC                 push    1INIT:8002DCFE                 push    10hINIT:8002DD00                 push    1000000hINIT:8002DD05                 push    ebxINIT:8002DD06                 mov     dword_800232C4, 40hINIT:8002DD10                 mov     esi, 10000hINIT:8002DD15                 call    _HalpAllocPhysicalMemory@16 ; HalpAllocPhysicalMemory(x,x,x,x)INIT:8002DD1A                 cmp     eax, ediINIT:8002DD1C                 jnz     short loc_8002DD20INIT:8002DD1E                 xor     esi, esi
EDIT: the page you found may be this (in Chinese):

http://www.pediy.com/kssd/pediy12/142776.html

Edited by roytam1

Share this post


Link to post
Share on other sites

@roytam1: Great find! Thanks for the link, Are you currently trying scdeny's XP64G patch, are you back to XP SP1 halmacpi or are you still using the patched hal generated from my universal search hexstring? I think scdeny's XP64G patch ought to be tested, alright.

Share this post


Link to post
Share on other sites

@roytam1: Great find! Thanks for the link, Are you currently trying scdeny's XP64G patch, are you back to XP SP1 halmacpi or are you still using the patched hal generated from my universal search hexstring? I think scdeny's XP64G patch ought to be tested, alright.

I haven't test "new" hal patch on the system that can crash(I have the patch from you running on the machine in $workplace, but since it is not using Realtek NIC I don't know how to crash it)

Share this post


Link to post
Share on other sites

It's alright! Take your time. But do it when it's convenient for you, and then, please do report it in this thread, OK?

BTW, when you do test scdeny's patch, do test it with VPCNetS2.sys present , too. Both crash instances were related to networking, after all...

Share this post


Link to post
Share on other sites

BTW for those using USB WebCam with 4GB/64GB patch, it is better to replace usbvideo.sys from 2K3 SP2.

Share this post


Link to post
Share on other sites

BTW for those using USB WebCam with 4GB/64GB patch, it is better to replace usbvideo.sys from 2K3 SP2.

If this is the case, the latest version of that file is in KB2868038 (Usbvideo.sys v.5.2.3790.5198) and should be preferred.

Share this post


Link to post
Share on other sites

@roytam1: Great find! Thanks for the link, Are you currently trying scdeny's XP64G patch, are you back to XP SP1 halmacpi or are you still using the patched hal generated from my universal search hexstring? I think scdeny's XP64G patch ought to be tested, alright.

I'm home now and tested new hal patch with exact environment with the procedure that caused BSoD before.

And test passed. ;)

Share this post


Link to post
Share on other sites

@roytam1: Great find! Thanks for the link, Are you currently trying scdeny's XP64G patch, are you back to XP SP1 halmacpi or are you still using the patched hal generated from my universal search hexstring? I think scdeny's XP64G patch ought to be tested, alright.

I'm home now and tested new hal patch with exact environment with the procedure that caused BSoD before.

And test passed. ;)

although the hal.dll is patched, the rtenicxp.sys is updated to latest version, it is still crashed.

BugCheck 1000000A, {f7bd3000, 2, 0, 806eebc7}READ_ADDRESS:  f7bd3000 CURRENT_IRQL:  2FAULTING_IP: hal!HalpMovntiCopyBuffer+f806eebc7 8b06            mov     eax,dword ptr [esi]CUSTOMER_CRASH_COUNT:  1DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0xAPROCESS_NAME:  pngout.exeLAST_CONTROL_TRANSFER:  from 806ea404 to 806eebc7STACK_TEXT:  f78aa9e0 806ea404 88ff7ffe f7bd2ffe 00000002 hal!HalpMovntiCopyBuffer+0xff78aaa00 806eb295 f7bd2ffe 8b28a564 00000002 hal!HalpCopyBufferMap+0xb6f78aaa4c 806ea62e 8889c5a0 87664f88 0128a540 hal!HalpMapTransfer+0x179f78aaa9c 806eb6e4 892f69d0 00000000 8b28a540 hal!HalpAllocateAdapterCallback+0xa2f78aaac8 806eacd9 0289c5a0 8c0d3064 00000006 hal!HalAllocateAdapterChannel+0x126f78aaaec f6d9b4fe 8889c5a0 892f69d0 00000088 hal!HalBuildScatterGatherList+0x223f78aab44 f6d82a08 88ca3ae0 87142310 00000000 NDIS!ndisMAllocSGList+0xd9f78aab60 ae051d40 882f1f40 87142310 88ca3ae0 NDIS!ndisMSendX+0x1a0f78aab88 ae051916 88ca3ae0 87142310 88ca07d0 tcpip!ARPSendData+0x198f78aabb4 ae05165a 88ca3ae0 f78aab02 00000001 tcpip!ARPTransmit+0x193f78aabe4 ae05179f 882dfd50 e4a8a8c0 87142310 tcpip!SendIPPacket+0x193f78aad30 ae055b07 ae08fb98 87338138 873380d0 tcpip!IPTransmit+0x289ef78aad9c ae055923 5a8bcdfc 00000002 00000000 tcpip!TCPSend+0x5d8f78aadc0 ae04ea0e 00000002 00000002 f78aadec tcpip!ProcessPerCpuTCBDelayQ+0x95f78aadf4 ae04e955 00000002 ae04e900 ae04e3d6 tcpip!ProcessTCBDelayQ+0xc4f78aae00 ae04e3d6 00000000 892f6ad0 ae04e7f8 tcpip!TCPRcvComplete+0x20f78aae0c ae04e7f8 f6da4c40 88ca3ae0 00000000 tcpip!IPRcvComplete+0x21f78aae10 f6da4c40 88ca3ae0 00000000 88844f28 tcpip!ARPRcvComplete+0x5f78aae60 f6375f05 006624f8 f78aaf00 00000002 NDIS!ethFilterDprIndicateReceivePacket+0x5a4WARNING: Stack unwind information not available. Following frames may be wrong.f78aaf9c f6379547 886d7d98 892f6ad0 88845030 Rtenicxp+0x13f05f78aafb4 f6d9ae99 88844000 8839a008 ffdff9c0 Rtenicxp+0x17547f78aafcc 80546f9f 88845044 88845030 00000000 NDIS!ndisMDpcX+0x21f78aaff4 80546b0b a75cfd44 00000000 00000000 nt!KiRetireDpcList+0x61f78aaff8 a75cfd44 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2b80546b0b 00000000 00000009 0081850f bb830000 0xa75cfd44STACK_COMMAND:  kbFOLLOWUP_IP: Rtenicxp+13f05f6375f05 ??              ???SYMBOL_STACK_INDEX:  13SYMBOL_NAME:  Rtenicxp+13f05

Share this post


Link to post
Share on other sites

Is there a variety of that driver specific for 2003? If so, do try it (maybe some renaming will be required to just substitute the .sys without reinstalling the driver, though).

Share this post


Link to post
Share on other sites

Looking at the Downloads...

http://support.asus.com/download.aspx?SLanguage=en&p=1&s=24&m=M5A99FX%20PRO%20R2.0&os=29&hashedid=LVnr9hOsmMV1eWsw

Is there a variety of that driver specific for 2003? If so, do try it (maybe some renaming will be required to just substitute the .sys without reinstalling the driver, though).

...there are 3 (three) versions, all allowing for x86 and x64 of XP, Vista, and Windows 7, the latest also supporting Windows8.x.

Generally speaking, you will (almost) -never- find drivers specifically for Server 2003 (I always use the XP ones). I'm betting that the problem is that the x86 Driver is "inadvertantly" being loaded High(?). May I suggest using the XP x64 Driver? :unsure:

Share this post


Link to post
Share on other sites

found another issue:

patched kernel (with any hal) makes EAC can't read Virtual Drive created with Daemon Tools.

Share this post


Link to post
Share on other sites

the issues come from mixing versions from different SP levels. Use the Server 2003 as workstation OS which supports PAE and can use all RAM:

Share this post


Link to post
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...