Detecting installed memory using GetPhysicallyInstalledSystemMemory

[klk206]

I have Windows 7 32-bit guest running on Windows 10 64-bit host. There is 4.096 Gb memory reserved for this VM, and the total memory on the host is 32 Gb.

In my app written for the guest OS I am trying to determine the amount of memory in the system using GetPhysicallyInstalledSystemMemory API call. The call seems to succeed because it returns TRUE, however the value it returns, 36866165243686319, is wrong. (The function seems to return without modifying the argument's value.)

My questions are:

- Is this a bug that needs to be reported or is this implementation specifics?

- If the latter, is there another way to learn the amount of available memory given this behavior?

- Is there a way to learn whether the app is running in virtual machine so that I could choose the method dynamically?

[socratis]

If you're running the app inside your guest, and your guest OS knows what it's memory is, then it sounds like a bad_written_app?

You can't be having an app running inside an OS give the wrong number, when the OS itself gives the right number...

[klk206]

I do not understand what you mean. This code:

Code: Select all

#include "windows.h"
#include "sysinfoapi.h"
#include <iostream>

ULONGLONG getSystemMemory(void)
{
	ULONGLONG mem;
	BOOL err = GetPhysicallyInstalledSystemMemory(&mem);
	return mem;
}

int main()
{
    std::cout << getSystemMemory() <<"\n"; 
}

sets err to 0 and outputs 14757395258967641292, which is nonsense, when compiled on the guest OS (x86 target), and outputs 33554432, as expected, when compiled for the same target on the host OS.

The guest OS does show in Control Panel that it has 3.50 Gb of memory.

[andyp73]

sets err to 0 and outputs 14757395258967641292

According to the Microsoft documentation for the GetPhysicallyInstalledSystemMemory() function the return value is a boolean. If it is returning 0 then that is false and the value returned in the TotalMemoryInKilobytes parameter is invalid.

As it is returning false then you should call GetLastError() to determine why. My guess is that it will return ERROR_INVALID_DATA and we have an issue with the SMBIOS data tables.

-Andy.

[socratis]

and we have an issue with the SMBIOS data tables.

I remember some recent activity in the mailing list about that, but I'm not so sure if it had anything to do with that specific value...

[klk206]

The error code is indeed 13, ERROR_INVALID_DATA. (Sorry, I should have checked the error code.)

[andyp73]

I have had a chat with one of the VirtualBox devs and they don't expose the SMBIOS/DMI memory tables as standard. If you run the following command with the guest shutdown:

VBoxManage setextradata <vmname> "VBoxInternal/Devices/pcbios/0/Config/DmiExposeMemoryTable" 1 

the correct tables then get exposed and the GetPhysicallyInstalledSystemMemory() function returns the right value.

-Andy.

[klk206]

This worked. Thank you very much.

Is there a reason this is not normally exposed? Might I suggest adding a checkbox in VirtualBox Manager GUI that would allow exposing it if desired?

[socratis]

Is there a reason this is not normally exposed?

This setting was not exposed up to 5 years ago. When it was implemented it was deemed necessary to not make it the default as to not break existing installations, mainly customers' installations.

Might I suggest adding a checkbox in VirtualBox Manager GUI that would allow exposing it if desired?

Highly unlikely. Such specialized settings are only settable from the CLI, not the GUI. If every available option was in the GUI, that would be really confusing.