http://msdn.microsoft.com/en-us/library/aa366778.aspx
http://blogs.msdn.com/tom/archive/2008/04/10/chat-question-memory-limits-for-32-bit-and-64-bit-processes.aspx
 

Thanks for the references, but they basically repeat the information I provided in my opening piece, and do not answer my questions.

Can anyone provide assistance specifically tailored to this particular machine?

For example:
1) registry entries or system files that contain the memory settings as configured by WinXP.
2) an explanation of how and why WinXP is configuring memory on this machine in this particular way.

The 3GB limit your experiencing is not just a 32-bit Windows issue. Your system hardware/OS combination will limit you to how much RAM you can use. I have seen different Windows XP 32-bit systems that could access only 2.75GB of RAM up to 3.75GB with 4GB of ram installed.
So Windows XP is allocating as much as it can to your system.
I hope this helps. Good luck.

"Does that mean the computer has 3GB of user-mode memory?"
No, User mode is still 2gb. By default it is the lower 2gb is reserved for User Mode programs.

"This can be changed by using the /3G switch in boot.ini so that WinXP Pro allocates 3GB for user-mode and 1GB for kernel-mode."
IT will allow User Mode to go to 3gb, but it wont change how XP sees the RAM.

As stated previously, the hardware is the limiitng factor here. How much Windows reports, is going to be dynamic based on the hardware, Video card (how much shared memory etc,....). Using the /3gb and /pae might help, but it wont change the underlying fact that XP will NOT report 4gb of RAM....


Does that mean the computer has 3GB of user-mode memory?

/pae
http://msdn.microsoft.com/en-us/library/ms791485.aspx

/3GB
http://msdn.microsoft.com/en-us/library/ms791558.aspx

First, the /3GB switch has NO impact on how much memory will be "seen" by XP.   It only effects the size of the virtual address space that processes are allowed (changing that from 2GB/process to 3GB/process).   On some systems with the appropriate BIOS support, /PAE may help, but on desktop boards that's generally not the case (some Asus boards with a "memory hole" feature can see more memory with /PAE).

Your system can address 4GB of memory address space -- but there are system-level functions that must be assigned addresses before RAM is allocated.   These include things like BIOS shadowing; video aperture; PCI addresses; etc.    On most systems with 4GB you'll see between 3.2 and 3.5GB; but it can be much lower (particular on systems with multiple video cards).

If you want to confirm that the system is "seeing" the modules okay, just download the free CPU-Z and run it.   Click on the Memory tab to see the installed memory; or on the SPD tab to look at the reported SPD from each of the installed modules.  [http://www.cpuid.com/download/cpuz_149.zip ]

... but the bottom line is your system is working fine => and you do NOT want to add either the /3GB or the /PAE switch to BOOT.INI

CPU-Z reports 2x2GB as expected, in slots 1 and 3 -- slots 2 and 4 are empty... it's dual-channel memory... that's why the slots are staggered.

Given a machine with 4GB of installed RAM, could you please explain the relationship between the following RAM metrics:
1) The RAM amount that WinXP reports on the System Properties sheet.
2) The RAM amount allocated by WinXP for kernel-mode processes.
3) The RAM amount allocated by WinXP for user-mode processes.

>> Your system can address 4GB of memory address space -- but there are system-level functions that must be assigned addresses before RAM is allocated.   These include things like BIOS shadowing; video aperture; PCI addresses; etc. <<

Aren't all of the "system-level" RAM assignments taken from the kernel-mode memory pool ?

As far as I know WinXP creates exactly two memory pools: 1) the kernel-model pool and, 2) the user-mode pool.  Is there another memory pool that I don't know about?

Also, it's my understanding that WinXP 32-bit SP2+ automatically puts the CPU in PAE mode if the CPU supports hardware DEP... the Intel Core2 Duo supports hardware DEP... this machine has a Core2 Duo, so I would expect that at boot WinXP puts this machine in PAE mode.

Is that right?

If so, does the CPU being in PAE mode affect the way that WinXP allocates RAM to the kernel-mode and user-mode pools?

If so, how ?

Is there any way to check the following -- i.e. via command line functions, registry entries, etc:
1) Whether the CPU is in PAE mode.
2) How much RAM is allocated to user-mode pool.
3) How much RAM is allocated to kernel-mode pool.

I'd like to be able to find all of the above (1, 2 and 3) for any PC without speculating as to what the operating system did or did not do to configure memory.

I could write a program to check all of the above, but I'd rather not reinvent the wheel, if there's a solution already.

"1) Whether the CPU is in PAE mode."
Right click My Computer>Properties, and it should tell you at the bottom Physical Address Extension

"2 and 3" ???
I would be curious to see if it might be maintained in WMI, but bot sure. If you are using the 3gb switch, then you know User Mode has 3gb, and the Kernel Mode has the remainder..... I think it is either 2+2, or 3+1.... Might be wrong, but would welcome a correction if needed.....

garycase, just wanted to say I enjoy reading your posts. Always very technically detailed and thorough.....

:^)

garycase, thanks for the excellent post... that's exactly what I was looking for.

johnb6767, thanks for the Mark Russinovich reference... it looks great... I'll delve into it.

I was aware of the PAE report on the System Properties sheet... but wasn't sure whether it meant that the WinXP PAE kernel was running (i.e. the machine was in PAE mode), or simply that the machine was PAE capable.

To find out either way, I disabled the NX feature in BIOS... the PAE report went away on the System Properties sheet... I then re-enabled NX in BIOS... the System Properties sheet again reported PAE.

The test strongly suggests that the PAE report means that the machine is in PAE mode.

And it also corroborates the notion I posted above, that WinXP automatically enables PAE mode on CPU's that support hardware DEP.  By toggling the NX feature from BIOS I was also toggling PAE.

As an aside, WinXP 32-bit SP2+ apparently uses PAE only to gain access to the DEP feature... it apparently doesn't care about the fact that PAE allows access to 64GB of physical memory (36-bit addressing.)

Glad you found it helpful.

As I noted above, PAE is always on with DEP -- it's required.   You can disable BOTH in BOOT.INI (with /execute) ... but if DEP is enabled, PAE will be on.  

And as I also noted, /PAE doesn't help address memory beyond the 4GB barrier except for a few systems that support a "memory hole" feature (notably some Asus motherboards) ... but in no case can you gain access to more than 4GB.   Basically, /PAE is never useful in XP except for allowing DEP (which is a very good feature).

Mark Russinovich's articles and software utilities are great resources => that's why Microsoft bought his company :-)

Many 32-bit OS's [e.g. Server 2003 Enterprise and others] can access more than 4GB of memory using /PAE.   Clearly that's what RamDisk is doing, since they require /PAE to be enabled.   What they're doing is simply installing an OS extension that allows access to the additional memory using the /PAE capabilities of the hardware.    Whether you want your OS to be modified by a 3rd party application is questionable -- but I'd expect it works just fine.    Although personally I'd just use an x64 OS if I installed more than 4GB.  [Vista x64 works very well]

The 4GB physical RAM limit of WinXP 32-bit SP2+ was probably a MS marketing decision based on the general lack of 64-bit-aware device drivers at the time... and not a technical limit of PAE.  

This was probably due to the fact that many device drivers written for 32-bit Windows could not handle 64-bit memory pointers, and so created havoc in PAE's 64-bit environment.

This is evidenced by the fact that several other MS 32-bit OS's have physical RAM limits well in excess of 4GB... see the following list.

MS 32-bit OS's with PAE support, and their physical memory limits:
---
Windows 2000 Advanced Server       -- 8 GB
Windows 2000 Datacenter Server -- 32 GB
Windows XP -- 4 GB
Windows Server 2003 Enterprise Edition -- 32 GB
Windows Server 2003 R2 (or SP1) Enterprise Edition -- 64 GB
Windows Server 2003 Datacenter Edition -- 64 GB
Windows Server 2003 Standard Edition -- 4 GB
Windows Vista -- 4 GB
Windows Server 2008 Enterprise or Datacenter Edition -- 64 GB
Windows Server 2008 other editions -- 4 GB

Notice that the servers, especially the advanced versions, support up to 64GB (the limit of the PAE 36-bit address space), whereas the client OS's stick to 4GB (the 32-bit address space.)  

This is likely due to the server market, especially the high end of that market, being much more 64-bit-aware than the client OS market, in terms of the vendors that write device drivers, and the requirement of the server market for more physical memory relative to the client OS market.

As for the machine in question (a Dell Vostro 420)... the service manual gives a 4GB max limit for installed RAM, and as I mentioned, the machine has 2x2GB modules and two empty slots.

What might happen if I add 2x2GB modules in the empty slots, for a total of 8GB ?

The machine was built a few days ago and should have state of the art components... so I'm thinking that the FSB should electrically support 8GB... but Dell chose not to offer 64-bit OS's on this model and maybe that's why the service manual gives the 4GB limit.

Any thoughts ?

Agree.    As I noted earlier, /PAE doesn't alter the fact that you still have a 32-bit address -- and thus a 4GB addressing limit -- but adds a 4-bit register that's used to control memory paging ... allowing up to 64GB of memory to be managed (4 bits => 16 possible sets of pages x 4GB = 64GB).

Note that your comment about "... PAE's 64-bit environment ..." is wrong => /PAE does not create a 64-bit environment.   An x64 OS has a a much wider address register, so does not need any /PAE extensions.   I think the support for larger address space in the server space is more likely due to the large number of processes that tend to be running -- especially database processes.   These processes are still limited to the same 2GB virtual space (unless the /3GB switch is used) ... but with much more physical RAM there will be far fewer page faults -- thus much better performance.

As for your new Vostro -- it may "see" 8GB okay;  but I wouldn't recommend it.   Installing 4 double-sided modules in a desktop board that uses unbuffered memory places a VERY high load on the address and data bus ... and can result in memory system instability.   Many systems automatically compensate for this by slowing down the memory timings; forcing single channel mode; slightly increasing the voltage; or some combination thereof.   I only recommend using all four slots if your memory modules are single-sided (which 2GB modules will NOT be).    As should be very clear by now, there would be NO advantage in XP Pro to having additional memory installed anyway :-)

"This is likely due to the server market, especially the high end of that market, being much more 64-bit-aware than the client OS market, in terms of the vendors that write device drivers" - you really think so? Then please explain the difference between a 2008 enterprise and a standard edition. Do you think they use different drivers? No way. It's your money MS wants, nothing else. The more you pay, the more memory will be supported.

On the other hand, x64 is not expensive, the standard servers support as much RAM as the enterprise editions of 2008 32bit, more even. There the hope will be to sell new x64 versions of software which you can sell as being very well performing and so on. Customers shall be motivated to buy new versions of their old 32bit software.

>> Note that your comment about "... PAE's 64-bit environment ..." is wrong => /PAE does not create a 64-bit environment. <<

I think you're referring to the following:  A 32-bit OS on x86 or x64 CPU's in protected mode, whether in PAE mode or not, uses 32-bit linear address pointers, as we discussed.

WinXP 32-bit probably sets the CPU (x86 and x64) in protected mode... that's certainly the case on x86, but probably also on x64, so the above statement very likely applies to WinXP 32-bit.

However, I was referring to the Page Directory (PD) and Page Table (PT) structures of x86 and x64... the structures that implement the linear-to-physical address translation mechanism.

When the CPU is in 32-bit protected mode (aka legacy mode on x64) the PD and PT structures contain 64-bit pointers in PAE mode, whereas they contain 32-bit pointers when not in PAE mode.

That's the PAE 64-bit environment I was referring to.  It's required on WinXP 32-bit PAE mode because the PD and PT structures reside in, and point to, physical memory, and PAE mode implies more than 4GB of physical memory.  

The CPU needs more than 32-bits to address more than 4GB of RAM, and so it uses 64-bit pointers in the PD and PT structures to do so.

Granted, not all 64-bits of PD and PT pointers are used for addressing... the actual number is 36, 40, or 48 bits, depending on the CPU model, and on the implementation of CPU on a system board.

I'd like to hear your thoughts on how these matters affect device drivers, and consequently MS's decision to limit the 32-bit versions of XP and Vista to 4GB of RAM (ostensibly due to driver compatibility issues.)

>> I think the support for larger address space in the server space is more likely due to the large number of processes that tend to be running -- especially database processes.   These processes are still limited to the same 2GB virtual space (unless the /3GB switch is used) ... but with much more physical RAM there will be far fewer page faults -- thus much better performance. <<

That is absolutely the case for servers.

>> Installing 4 double-sided modules in a desktop board that uses unbuffered memory places a VERY high load on the address and data bus ... and can result in memory system instability. <<

Reading between the lines, the implications are:
1) Desktop system boards are generally not designed for heavy electrical loads on the FSB.
2) Unbuffered RAM places a much higher electrical load on the FSB than buffered RAM.

Any additional detail you can provide on these issues would be welcomed.

>> As should be very clear by now, there would be NO advantage in XP Pro to having additional memory installed anyway <<

It's very clear.  However, I was thinking of dual booting XP32 and XP64 using BING... the 8GB would come in handy on XP64.

>> you really think so? ... <<

Good points... hadn't thought about it that way.

>> RamDisk Plus 9.0 <<

Clearly shows that the 4GB RAM limit of XP and Vista 32-bit is not technical in the strict sense.

Unbuffered RAM places one electrical load per memory chip on the data and address buses -- that's 16 loads per module for double-sided modules.   Buffered RAM places one load per MODULE -- the buffering takes care of the loads for the individual chips.   Clearly that's a HUGE difference.   And the higher the load, the more deformed the waveform is -- thus the less reliable the memory subsystem.

... this is a bit of advertising; but it's nevertheless an excellent tutorial on various memory issues -- note in particular item #10, which addresses the buffered/unbuffered issue:  http://www.corsairmemory.com/memory_basics/index.html

Agree with the basic details on addressing ... it's a question of semantics.   x64 OS's do not use /PAE in the sense that there's extra support needed in the BIOS for the added addressing registers, as the additional bits are already in the CPU's addressing registers (as you correctly noted, they do NOT use 64 bits for this -- I believe the Intel implementation is actually 44 bits, but it's been a while since I delved into those details, so it may be 40 or 48 -- memory's the first thing to go as you age a bit.   In any event, it's "enough" that we aren't likely to hit THAT limit anytime soon !! :-)   (famous last words)

I really don't know the reasons behind the decision to limit XP & Vista to 4GB.   I suspect it was simply the consquence of the 32-bit addressing limit, and a feeling that 4GB was "enough" ... at  the time it XP was designed that was a HUGE amount of memory.  [I remember when 64K seemed like a HUGE amount of memory !!]    Vista is another story ... but I suspect the answer there is simply that it wasn't deemed worth the computational overhead to implement PAE when there was an x64 version (which works very nicely, by the way).    The server space is a different issue -- there's a MUCH greater need for large amounts of memory, so they had little choice but to add the code necessary to allow more processes to run without significant page faults.

I suspect the potential issues with non-compliant device drivers indeed impacted those choices ... as I think you are implying with your question above.   There ARE a LOT of 3rd parties that can "much up" the OS if they provide non-compliant drivers ... an issue Microsoft's been wrestling with for a couple decades now.

r.e. dual booting XP32 and XP64 with BING -- works very well.   I can boot to XP Home, XP Pro (two versions), XP MCE, XP x64, Vista Home Premium, Vista Ultimate x32, and Vista Ultimate x64 on this system thanks to the "magic" of BING :-)    But I only have 4GB installed (2 x 2GB).   If I wanted 8GB, I'd buy a pair of 4GB modules [http://www.newegg.com/Product/Product.aspx?Item=N82E16820220356 ]

I do plan to build a system later this year with Server 2008 and a lot of memory (probably 16GB) ... but I'll use a server motherboard with registered modules.

I'll close now to award points...

Thanks for the excellent discussion !

Same great comments here so I will be brief and add my two cents:

The only time I've seen the /3GB switch used is in SQL boxes or Exchange boxes, if you do need to use this switch make sure you throw in the /userva="amount of memory you want to give back to the kernel"  so you dont deplete your PTE's and cripple your box.

@qualchoice-it

Thank you for your comment ... it's good to know.