GlobalMemoryStatusEx returns very big virtual memory size on x64
thor2008
http://msdn2.microsoft.com/en-us/library/aa366589(VS.85).aspx I get very big
values. It seems like a bug on x64 platforms (I could be wrong and in fact it
might be a cast problem).
The values below are in bytes (I don't think my computer has 8191 = 0x1FFF
GB total virtual memory)
Total Virtual Memory 8796092891136
Avail Virtual Memory 8796008636416
And more, the same code compiled as x32 bit binary and as x64 bit binary
returned different values but only for VM size (but if you look close you may
see a mask 0x07FFFFFF which can be applied):
c:\>TestVMMemx32
There is 40 percent of memory in use.
There are 1045644 total Kbytes of physical memory.
There are 620312 free Kbytes of physical memory.
There are 2370016 total Kbytes of paging file.
There are 1940864 free Kbytes of paging file.
There are 2097024 total Kbytes of virtual memory.
There are 2051124 free Kbytes of virtual memory.
There are 0x07FFE000 0x00000000 total bytes of virtual memory.
There are 0x07D30D00 0x00000000 free bytes of virtual memory.
Difference 47001600
c:\>TestVMMemx64
There is 40 percent of memory in use.
There are 1045644 total Kbytes of physical memory.
There are 622360 free Kbytes of physical memory.
There are 2370016 total Kbytes of paging file.
There are 1941460 free Kbytes of paging file.
There are 8589934464 total Kbytes of virtual memory.
There are 8589889576 free Kbytes of virtual memory.
There are 0xFFFFE000 0x00000000 total bytes of virtual memory.
There are 0xFFD40A00 0x00000000 free bytes of virtual memory.
Difference 45965312
c:\>
And now it returns bad values on x32 windows 2003 if i have 2 pagefiles with
custome sizes
Joseph M. Newcomer
On Wed, 27 Feb 2008 07:55:02 -0800, thor2008 <thor...@discussions.microsoft.com> wrote:
> Even with the sample code from
>http://msdn2.microsoft.com/en-us/library/aa366589(VS.85).aspx I get very big
>values. It seems like a bug on x64 platforms (I could be wrong and in fact it
>might be a cast problem).
>
>The values below are in bytes (I don't think my computer has 8191 = 0x1FFF
>GB total virtual memory)
>
>Total Virtual Memory 8796092891136
>Avail Virtual Memory 8796008636416
****
Sounds about right. Put a few commas in to delimit it and it becomes obvious:
8,796,092,891,136
VM in WIn64 is 8TB, that is 8,192 GB. The VM is *available*. It might be limited by
running out of swap space on a tiny 1TB (relatively speaking) hard drive, but there's
nothing intrinsic in the architecture that says that VM is not available, only a minor
implementation detail (you run out of swap space). Note that Win32 allows 2GB of VM for
every process, even if the entire hard drive connected to the machine was only a 2GB
drive. Unless you booted with the /3GB option, in which case it would have told you there
was 3GB of VM available, even if you had only a 2GB drive.
****
>
>And more, the same code compiled as x32 bit binary and as x64 bit binary
>returned different values but only for VM size (but if you look close you may
>see a mask 0x07FFFFFF which can be applied):
>
>c:\>TestVMMemx32
>There is 40 percent of memory in use.
>There are 1045644 total Kbytes of physical memory.
>There are 620312 free Kbytes of physical memory.
>There are 2370016 total Kbytes of paging file.
>There are 1940864 free Kbytes of paging file.
>There are 2097024 total Kbytes of virtual memory.
>There are 2051124 free Kbytes of virtual memory.
>
>There are 0x07FFE000 0x00000000 total bytes of virtual memory.
>
>There are 0x07D30D00 0x00000000 free bytes of virtual memory.
>
>Difference 47001600
>c:\>TestVMMemx64
>There is 40 percent of memory in use.
>There are 1045644 total Kbytes of physical memory.
****
Running Win64 will not add more physical memory to your machine, so the amount of physical
memory remains the same
*****
>There are 622360 free Kbytes of physical memory.
*****
Obviously this value varies dynamically, so this is going to change from instant to
instant based on various parameters, but it appears Win64 has a similar amount free, which
is not overly surprising
*****
>There are 2370016 total Kbytes of paging file.
*****
This simply means you have configured your paging files the same in both versions of the
system; you could go into the VM settings and double this on either system, so apparently
you have used the out-of-the-box settings, which are probably the same
****
>There are 1941460 free Kbytes of paging file.
*****
This would change from instant to instant based on system load, so its similarity is
actually surprising
*****
>There are 8589934464 total Kbytes of virtual memory.
>There are 8589889576 free Kbytes of virtual memory.
****
Given the architecture of Win64 allows 8,192GB of VM, these numbers appear to be correct
****
>
>There are 0xFFFFE000 0x00000000 total bytes of virtual memory.
>
>There are 0xFFD40A00 0x00000000 free bytes of virtual memory.
>
>Difference 45965312
>c:\>
>
>And now it returns bad values on x32 windows 2003 if i have 2 pagefiles with
>custome sizes
****
Well, that could be a kernel bug in the implementation of the API. You might consider
reporting this to Microsoft.
joe
****
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
sainjure
is displayed by the system information application run on the same system.
(Start->Program->Accessories->System Tools->System Information)
Also on Windows Server 2008 the API returns wrong results. I have also tried
using the WMI_OperatingSystem class and the WMI_PageFile class to check the
same. But they both return me wrong results on Windows Server 2008 machine.
Can any brilliant mind comment on this?
Joseph M. Newcomer
GlobalMemoryStatusEx, and therefore you are using the wrong API to derive this
information.
Note that the specifications of GlobalMemoryStatusEx carefully state
ullTotalVirtual: Total size of the user mode portion of the virtual address space of the
calling process, in bytes.
So it is telling you EXACTLY WHAT IT IS SPECIFIED TO TELL YOU: that the total size of your
process's virtual memory is the number specified
Define "wrong results". Is it the *same* "wrong" result (which is the correct result: the
amount of virtual address space addressible by the process) returned by
GlobalMemoryStatusEx, or is it a *different* "wrong" result?
Note that I do not know what API *is* used, but it is not GlobalMemoryStatusEx, which is
telling you something completely different, and is telling you what it is supposed to tell
you.
The API is telling you, as it is specified to tell you, the potential range of virtual
addresses available to you for whatever purposes you may need them. For example, that you
could use VirtualAlloc to allocate storage anywhere (within granularity-aligned
boundaries) in that massive address space, so it is telling you the range of legitimate
addresses you can supply. It is not telling you the per-system configuration limits that
may ultimately limit your usage of that address space.
joe
sainjure
within the System Information application?
(Start->Program->Accessories->System Tools->System Information
GGump Chuang
but it is not the value of ulTotalVirutal,
it is the difference of ulTotalPageFile and ulTotalPhys
> On Wednesday, February 27, 2008 10:55 AM thor200 wrote:
> Even with the sample code from
> http://msdn2.microsoft.com/en-us/library/aa366589(VS.85).aspx I get very big
> values. It seems like a bug on x64 platforms (I could be wrong and in fact it
> might be a cast problem).
>
> The values below are in bytes (I don't think my computer has 8191 = 0x1FFF
> GB total virtual memory)
>
> Total Virtual Memory 8796092891136
> Avail Virtual Memory 8796008636416
>
> And more, the same code compiled as x32 bit binary and as x64 bit binary
> returned different values but only for VM size (but if you look close you may
> see a mask 0x07FFFFFF which can be applied):
>
> c:\>TestVMMemx32
> There is 40 percent of memory in use.
> There are 1045644 total Kbytes of physical memory.
> There are 620312 free Kbytes of physical memory.
> There are 2370016 total Kbytes of paging file.
> There are 1940864 free Kbytes of paging file.
> There are 2097024 total Kbytes of virtual memory.
> There are 2051124 free Kbytes of virtual memory.
>
> There are 0x07FFE000 0x00000000 total bytes of virtual memory.
>
> There are 0x07D30D00 0x00000000 free bytes of virtual memory.
>
> Difference 47001600
> c:\>TestVMMemx64
> There is 40 percent of memory in use.
> There are 1045644 total Kbytes of physical memory.
> There are 622360 free Kbytes of physical memory.
> There are 2370016 total Kbytes of paging file.
> There are 1941460 free Kbytes of paging file.
> There are 8589934464 total Kbytes of virtual memory.
> There are 8589889576 free Kbytes of virtual memory.
>
> There are 0xFFFFE000 0x00000000 total bytes of virtual memory.
>
> There are 0xFFD40A00 0x00000000 free bytes of virtual memory.
>
> Difference 45965312
> c:\>
>
> And now it returns bad values on x32 windows 2003 if i have 2 pagefiles with
> custome sizes
>> On Saturday, March 01, 2008 7:31 PM Joseph M. Newcomer wrote:
>> See below...
>> On Wed, 27 Feb 2008 07:55:02 -0800, thor2008 <thor...@discussions.microsoft.com> wrote:
>>
>> ****
>> Sounds about right. Put a few commas in to delimit it and it becomes obvious:
>> 8,796,092,891,136
>>
>> VM in WIn64 is 8TB, that is 8,192 GB. The VM is *available*. It might be limited by
>> running out of swap space on a tiny 1TB (relatively speaking) hard drive, but there's
>> nothing intrinsic in the architecture that says that VM is not available, only a minor
>> implementation detail (you run out of swap space). Note that Win32 allows 2GB of VM for
>> every process, even if the entire hard drive connected to the machine was only a 2GB
>> drive. Unless you booted with the /3GB option, in which case it would have told you there
>> was 3GB of VM available, even if you had only a 2GB drive.
>> ****
>> ****
>> Running Win64 will not add more physical memory to your machine, so the amount of physical
>> memory remains the same
>> *****
>> *****
>> Obviously this value varies dynamically, so this is going to change from instant to
>> instant based on various parameters, but it appears Win64 has a similar amount free, which
>> is not overly surprising
>> *****
>> *****
>> This simply means you have configured your paging files the same in both versions of the
>> system; you could go into the VM settings and double this on either system, so apparently
>> you have used the out-of-the-box settings, which are probably the same
>> ****
>> *****
>> This would change from instant to instant based on system load, so its similarity is
>> actually surprising
>> *****
>> ****
>> Given the architecture of Win64 allows 8,192GB of VM, these numbers appear to be correct
>> ****
>> ****
>> Well, that could be a kernel bug in the implementation of the API. You might consider
>> reporting this to Microsoft.
>> joe
>> ****
>> Joseph M. Newcomer [MVP]
>> email: newc...@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>> On Wednesday, March 05, 2008 7:44 AM sainjur wrote:
>>> Why doesn't the values returned by GlobalMemoryStatusEx, match the one that
>>> is displayed by the system information application run on the same system.
>>> (Start->Program->Accessories->System Tools->System Information)
>>>
>>> Also on Windows Server 2008 the API returns wrong results. I have also tried
>>> using the WMI_OperatingSystem class and the WMI_PageFile class to check the
>>> same. But they both return me wrong results on Windows Server 2008 machine.
>>>
>>> Can any brilliant mind comment on this?
>>>
>>> "Joseph M. Newcomer" wrote: