38 replies to this topic

[stickywire]

Sorry for asking this, I've been reading the forum and FAQ but there is no clear answer.

 

I have a 32-bit XP with sp3, on a system with 8GB RAM (64-bit capable CPU).

 

PAE is forced enabled, and installed imdisk (and verified the awealloc service is running).  Using IMdiskTK.

 

No matter how big or how small the ramdisk is enabled, it takes up the actual working memory under 2.7GB (that how much my windows can see the RAM).

 

In the event log, it complained about AWE cannot allocate 8GB, 6GB, ..... which were mentioned in other posts within this forum.

 

Just so before I give up the fight, I just want to confirm a few things:

* XP 32-bit, even with PAE, can access no more than 4GB RAM (despite I have 8 on the system)?

 

* even in this case, is there a reason why awealloc cannot allocate even the smallest RAM disk outside of the usable RAM, as I would like to take advantage of the unusable RAM.  I must run XP due to drivers for several hardware.

 

Any other things I can try?   I've also tested Gavotte RAMdisk and got the same result in eventlog.

 

Thanks in advance.

[v77]

As it is said on Wikipedia, XP only supports 4GB, even with PAE. So, AWE will not help you.

Your only alternative is a ramdisk that uses the unmanaged memory. But there is sometimes incompatibilities because some drivers can also use this memory and, of course, the system is not aware of that.

Anyhow, ImDisk does not have this kind of feature.

[stickywire]

Thanks.   Yes, that was what I'm trying to do, making use of the unaddressable memory from 3-8GB as RAMdisk for temp and pagefile ideally.  I thought the awealloc will let us get pass that limit for ramdisk, but guess not the case for xp.  Too bad.   I've seen post from others that they were able to do that with Gavotte ramdisk for xp and make a ramdisk out of memory above 3GB-6GB, so was hoping imdisk will work.  Both didn't work for me.  Might give commercial ramdisk a try then.

 

Thanks.

[dencorso]

I have a i7 3770k on an Asus P8Z68-V LX, with 16 GiB of RAM. I've set on it XP SP3 with DEP disabled but PAE enabled, and use a 12 GiB Gavotte Ramdisk with a system managed Pagefile on it, and IE8's cookies, history and temporary internet files as subdirectories of its TEMP folder... It all works flawlessly. But it depends on the hardware one uses and in the way the BIOS gives access to it. What's your hardware exactly? My crystal ball is out for tunning again, sorry!

[stickywire]

Thanks for the info, I might try disabling the DEP.  I tried both IMdisk and Gavotte and both were having the same error in event log failing to allocate

.   

I got an AMD X2 4400e CPU, Gigabyte GA-LM78-USB3 mobo, 8GB DDR3 1600 RAM, WinXP sp3 32-bit.  Confirmed with Coreinfo.exe that PAE and NX bit are supported.

 

And I just tried the Primo Ramdisk trial and it works!  I have my 4GB RAM (minus video and other hardward mapping)  and then another 4GB RAM disk now for pagefile, so hardware supports it for sure.   A matter of figuring out how to get imdisk/gavotte to work.  I'll give DEP disabled a try.  Thanks!  

[cdob]

* XP 32-bit, even with PAE, can access no more than 4GB RAM (despite I have 8 on the system)?

Yes, XP limits to 4GB by default.

However, you may enable more RAM.
http://www.msfn.org/...n-4gb-with-pae/
Be aware: this approach is experimental

A RAMdisk (one PAE driver in the system) is a good idea still.

[dencorso]

After one installs the Gavotte ramdisk (with PAE enabled and - optionally - DEP disabled), the Gavotte will work using the low memory. To enable it to use the RAM not seen by Win XP SP3, one should then merge this .reg file to the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RRamdisk]
"Type"=dword:00000001
"Start"=dword:00000000
"ErrorControl"=dword:00000001
"Tag"=dword:0000000f
"Group"="System Bus Extender"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RRamdisk\Parameters]
"UsePAE"=dword:00000001
"BreakOnEntry"=dword:00000000
"DebugLevel"=dword:00000000
"DebugComp"=dword:ffffffff
"MediaType"=dword:00000002

or simply add by hand the UsePAE dword value and set it to 1, and then reboot. That should do the trick.

[stickywire]

Thanks cdob, interesting but may be more than I want to tackle.  Would be great if I can get the ramdisk using the memory >4GB range.

 

Thanks dencorso, I'll give it a try. The key diff with my registry entry right now are that the "Tag" and "group" keys are missing from mine, and the rest of the entries in both sections are the same including UsePAE.  

 

thanks for everyone's help!

[dencorso]

Are you sure you're using Rramdisk.sys v. 1.0.4096.5 ?

[stickywire]

Ah... I'm on 1.0.2003.1209   No wonder, thanks for pointing that out!  Hope it'll work this time.

[dencorso]

Well,  no version from before 2008 knows anything about PAE!

ChangeLog:
1.0.4096.5 volume label indicates whether upper memory is in use <released Nov 30, 2008>
1.0.4096.5 fixed some compatibility problems with ASUS motherboards
1.0.4096.3 strengthened the zeroing-out on initialization
1.0.4096.2 loading a too large NTFS formatted image file results in an invalid ramdisk
<versioning scheme changed>
1.0.2008.0101 support >=4G ram under 32bit windows (UsePAE=1)    <released Jan 01, 2008>
1.0.2007.0523 x64 support
1.0.2003.1209 fix SMP/HT compatibility
1.0.2003.1126 fix re-format problem & some typo
1.0.2003.1125 merge rdpack and rdj to rdutil
1.0.2003.1124 add DiskSizeK registry, more compatible w/ antivirus software

In any case, do tell us whether it's working, now. You may just substitute Rramdisk.sys by the newer one, on the unbooted system, using a live linux disc or a WinPE disc, and it should just work.

Attached Files

•  Gavotte_ReadMe_ENU_SortOf.7z   3.06KB   1147 downloads

[stickywire]

Thanks, appreciate your help!  I'll give it a try on the weekend and report back!  Gotta clean up the imdisk and primo trial.

[stickywire]

sorry took a while to spend time on it.  After installing the new 1.0.4 version, it now shows the disk volume RamDisk-PAE, available memory below 4GB is not decreased, and no error in eventlog, so it's working!   Thanks for the help dencorso!

[dencorso]

My pleasure!
Glad you've got it working.

[gid]

The 4 GB RAM limitation for 32 bit Windows is an artificial one, imposed by Microsoft with Service Pack 2 !

 

32 bit XP can be patched to support up to 64 GB of RAM !

 

http://iknowu.duckdn...e_PAE_Limit.htm

 

 

Special mention must be made of Windows XP SP2 and SP3. If you were fortunate enough to have 4GB in a machine for running
a client version of Windows up to and including Windows XP SP1,and your hardware had memory remapping so that some of your
4GB was above the 4GB address, and your third-party drivers worked correctly with memory above 4GB, then you will have
faced an unfortunate side-effect when upgrading to Windows XP SP2: you will have bought a downgrade of how much RAM
Microsoft permits you to use. How well did Microsoft disclose this side-effect in advance?

It was disclosed eventually. The Knowledge Base article "The amount of RAM reported by the System Properties dialog box and
the System Information tool is less than you expect after you install Windows XP Service Pack 2 reports that enabling PAE in
Windows XP SP2 does not allow the use of memory above 4GB". Italso talks of changes to the HAL. What actually was changed so
strains credibility that I had to be goaded into studying it. As much as anyone talks of defective 32-bit drivers that simply assume a
32-bit physical address space, it will forever remain that the most prominent example of such an assumption is what Microsoft itself
coded into the 32-bit HAL for Windows XP SP2. The difference is that Microsoft would have us believe that when Microsoft writes
code that makes such an ordinarily fautly assumption, it’s not a defect but a defence.

 

The HAL, meaning Hardware Abstraction Layer, is the component that drivers deal with when getting their DMA to work correctly
with the translation between linear and physical addresses for memory. The HAL models DMA operations in terms of abstracted
adapters which each have some number of so-called map registers according to whether double-buffering may be needed for
transfers that the HAL discovers involve physical memory that is too high for the device to access. Where the Knowledge Base
article says “the modified HAL grants unlimited map registers”, what it means is that the modified HAL assumes for itself that
double buffering is never required for any DMA operations on a device that can handle 32-bit physical addresses
Rather than “reduce driver compatibility issues”, this change makes a certainty of them! You could have a system in which
every driver that does DMA is coded correctly for its use of DMA functions, yet the HAL from Windows XP SP2 would ensure that
DMA for memory above 4GB misbehaves, just as feared from a buggy driver. Problems with defective DMA by drivers are avoided
not by this intrinsically dangerous change to the HAL but by the limit that the kernel introduced on the maximum physical address
for memory that the kernel will ever use. The best that can be said for the change to the HAL is that it strips the code of a case
that is made redundant by the change to the kernel.
Having seen that some 32-bit drivers assume all physical addresses fit 32 bits and thereby think to escape some coding
obligations regarding double buffering for their 32-bit device, Microsoft deliberately adopted the same faulty assumption into the
HAL, i.e., into arguably the second most critical executable in all of Windows. A company that can do such a thing is clearly not
thinking primarily of its product’s technical integrity.However it happened, the practical result is that Windows Vista is
the first client edition of 32-bit Windows to have all the code for using memory above 4GB but not the permission to use any of this
code. Windows XP SP2 and SP3 don’t have the permission either, but they anyway don’t have all the code.
 

[gid]

Oops...I didn't see the link posted by cdob.

So there's *another* patch to enable 4 GB+ RAM support !

NICE !

 

I've got to check that one out too...

 

I wonder if these patches also work on XPe POSready 2009...

[dencorso]

The > 3.2-3.5 GiB patch remains unreliable due to incomplete patching of the xp hal. Until that's solved, using a RAMDisk is the only useful solution.

[photor]

The > 3.2-3.5 GiB patch remains unreliable due to incomplete patching of the xp hal. Until that's solved, using a RAMDisk is the only useful solution.

Is there any similar approach for Win7 32-bit to use >4GB RAM?

[alacran]

If you install XP-SP1, it do no has that limitation and you are able to see and use all memory, I allready tested it long time ago installing XP SP-1 on VHD, using WinVblock driver to let it run in VHD fixed size and using GrubforDos to chain load XP.

[Wonko the Sane]

If you install XP-SP1, it do no has that limitation and you are able to see and use all memory, I allready tested it long time ago installing XP SP-1 on VHD, using WinVblock driver to let it run in VHD fixed size and using GrubforDos to chain load XP.

... and v77 already knew that :

http://reboot.pro/to...ement/?p=188778

 

Wonko

[crashnburn]

Seriously!?? That was the whole reason I moved from XP 32 to Win 7 64 to use 8G RAM

 

... and v77 already knew that :

http://reboot.pro/to...ement/?p=188778

 

Wonko

 

 

 

Hmmm. 

Time to patch the kernel?   

 

http://iknowu.duckdn...e_PAE_Limit.htm

 

Or get back to SP1? 

http://www.geoffchap...ense/memory.htm

 

Wonko

 

 

[Wonko the Sane]

 

Seriously!?? That was the whole reason I moved from XP 32 to Win 7 64 to use 8G RAM

Well, you could have upgraded to Server 2003 (still 32 bit), remaining essentially in the same "XP environment".

The issue with these approaches is often limited by the hardware (and related drivers), in a nutshell, besides the marketing/pricing aspect the good MS guys found out that a lot of crappy hardware (or drivers, or both) was in the hands of customers resulting in unstable systems and instead of fixing the issue decided to remove some capabilities from the "end customer OS" reserving it to the server series (which supposedly would run on "better" hardware).

On the other hand, a number of devices for "end customers" may have not Server 2003 manufacturer drivers and the XP drivers may be not installable or not stable.

 

Wonko

[Zoso]

I like this idea! didnt know XP SP1 allows more RAM than SP2 or 3 either.. I dont think I even have an SP1, might have to find a copy of that to play with.

The > 3.2-3.5 GiB patch remains unreliable due to incomplete patching of the xp hal. Until that's solved, using a RAMDisk is the only useful solution.

I'll try this a.s.a.p. and report back here.

thanks

[alacran]

I like this idea! didnt know XP SP1 allows more RAM than SP2 or 3 either.. I dont think I even have an SP1, might have to find a copy of that to play with.


I'll try this a.s.a.p. and report back here.

thanks

 

Particularly Intel drivers for x86 are known to be a problem (I can confirm this) because even if they know perfectly well how to make drivers for x64 (using all available memory), I guess they as a MS partner make on purpose x86 drivers having issues when you use more than 4 GB of RAM in x86, just to help MS pushing x64 systems.

So make an image of system before installing any driver, latter go one by one when you install drivers and reboot after each one to detect any incompatible driver.