Windows XP x64 only has 3.5GB Memory

What first comes to mind is to check the applicable "boot.ini" file, if it exists (typically at the root of a boot partition or floppy). The boot.ini file is a file used by the Windows 2000/XPServer 2003 and 64-bit versions' boot loader (NTLDR) to specify operating systems and with what parameters to load the operating systems.

If there is a parameter you are uncertain about, find more information about it. Be aware that a reduction of RAM availability need not be explicit. For example, a kernel or HAL may be explicitly defined in boot.ini and the defined kernel or HAL may limit or fail to make available all RAM.

Be aware that if a floppy drive has a boot loader with a boot.ini file, it takes precedence if the floppy precedes other devices in boot order.


The next thing that comes to mind is your use of sessions. It is clear from the picture you provided that the use of multiple sessions are permitted (otherwise the connection to the machine via Terminal Services/RDP would not have been possible). I am somewhat unfamiliar with the use and management sessions, but I would think that memory allocated to a resources from or for a session might not be available to other sessions. Also, it would seem plausible that a limitation on the amount of RAM might be explicitly set.

Please note that the task manager and system properties of Windows 2000/XP/Server 2003 family operating systems report on available RAM (in use plus free memory) rather that installed RAM.

Do you have physical access to the machine at issue?

I see from the screenshot that CPU-Z 1.65 was used. I have just finished testing this new version of CPU-Z and have determined it to be defective with regards to reporting the correct total memory size.

I used 2 x 1024MB DIMMs plus 2 x 256MB DIMMs PC3200 DDR SDRAM for my test. CPU-Z 1.65.0 x32 under reported the Memory Size as 2 GBytes (it also reports values in "GBytes", while previous versions reported "MBytes"). The SPD tab showed the correct information.

Previous version of CPU-Z did not have the described problem. I would recommend avoiding CPU-Z 1.65.0.

For the case described in this thread, it is likely that the valued displayed in the CPU-Z 1.65 x64 picture is correct (the thread starter had also reported that other software/firmware reporting 4GB of RAM).

Never seen such problem with XP x64!

But, Vista and later seem to have a problem where it sometimes falsely thinks RAM is "reserved" for something and refuses to use that RAM.

zzzzzzzzzz said:

What first comes to mind is to check the applicable "boot.ini" file, if it exists (typically at the root of a boot partition or floppy). The boot.ini file is a file used by the Windows 2000/XPServer 2003 and 64-bit versions' boot loader (NTLDR) to specify operating systems and with what parameters to load the operating systems.

If there is a parameter you are uncertain about, find more information about it. Be aware that a reduction of RAM availability need not be explicit. For example, a kernel or HAL may be explicitly defined in boot.ini and the defined kernel or HAL may limit or fail to make available all RAM.

Be aware that if a floppy drive has a boot loader with a boot.ini file, it takes precedence if the floppy precedes other devices in boot order.


The next thing that comes to mind is your use of sessions. It is clear from the picture you provided that the use of multiple sessions are permitted (otherwise the connection to the machine via Terminal Services/RDP would not have been possible). I am somewhat unfamiliar with the use and management sessions, but I would think that memory allocated to a resources from or for a session might not be available to other sessions. Also, it would seem plausible that a limitation on the amount of RAM might be explicitly set.

Please note that the task manager and system properties of Windows 2000/XP/Server 2003 family operating systems report on available RAM (in use plus free memory) rather that installed RAM.

Do you have physical access to the machine at issue?

Click to expand...

The boot.ini file I would think fine, unless my CD image was faulty, as it is an extremely recent install. I do not personally have physical access to the machine, but do you mean my RDP session may be causing this? I have a contact on the other end who could tell if the same results would occur without the remote session.

misternumberone said:

The boot.ini file I would think fine, unless my CD image was faulty, as it is an extremely recent install. I do not personally have physical access to the machine, but do you mean my RDP session may be causing this? I have a contact on the other end who could tell if the same results would occur without the remote session.

Click to expand...

I doubt that. I would check the BIOS.

The BIOS says 4GB.

misternumberone said:

The boot.ini file I would think fine, unless my CD image was faulty, as it is an extremely recent install.

Click to expand...

It does not matter how long ago the install was.

The issue at hand is very basic in nature and it is quite possible (likely) that issue is manifesting or being made to happen at OS load-time. The problem would be caused at load time, by a driver or drivers (often HAL or RAM drive driver), or a Windows service.

The boot.ini file is created and modified by various software, including Windows text mode and GUI setup, Service Packs, software updates (including those for the operating system), driver installers and configuration scripts, and other various software. Depending on the set of software (including operating system and drivers) installed and the order they were installed or run, the boot.ini file may contain significantly different data. The file may also be modified manually.

Check the boot.ini file. This can be easily and quickly (and typically cheaply) be done via remote session and is important to do. Remember to also check for a boot.ini on all floppy drives and not just hard disk boot partitions.

misternumberone said:

, but do you mean my RDP session may be causing this?

Click to expand...

Not necessarily (nor exclusionary) your RDP session, but rather a or multiple sessions or a (memory or RAM) limitation/assignation (optional or by design) placed on a session or sessions. A session need not be remote (local sessions).

misternumberone said:

I do not personally have physical access to the machine...I have a contact on the other end who could tell if the same results would occur without the remote session.

Click to expand...

It would be good to check the RAM usage of the local "Console" session.

I do remember reading about a limitation which I think was related to memory and the use of RDP 6.0, but do not clearly remember what it was about.

You can also try connection via a 5.2 version Remote Desktop Connection Client and see if results are consistent. The an installer for the 5.2 version of Remote Desktop connection may be obtained off a Windows Server 2003 family operating system (which does include Windows XP Professional x64 Edition) installation CD.