VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API

[FEHE]

Summary:
I ran into an issue with reading BIOS System Information on Windows 10 guest using Microsoft .NET API. The issue is specific to VirtualBox. The same application works fine on a VMware VM.

Details:
I have a Windows application that reads PC system information for security reasons. This application uses the following Microsoft .NET APIs (I am not allowed to insert external links here):
SystemInformation.DeviceModel
SystemInformation.DeviceManufacturer

I was using this application on a Windows 10 VM running on WMware and it was working fine.

Now I need to migrate this VM to VirtualBox platform. I exported the VM from vSphere, I imported it into VirtualBox, I also found VBoxManage setextradata commands to update System Model and System Manufacturer values as follows:

VBoxManage setextradata "ITE_Win10-2" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "Oracle"
VBoxManage setextradata "ITE_Win10-2" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "VirtualBox"


Nevertheless, the application does not get those values.

I tried to use the standard msinfo32 tool on the same VM, and interestingly enough that tool could read back the System Information values on both machines. So, the VBoxManage commands above did work on the VirtualBox VM.

The only thing that does not work right now is the .NET library, and specifically on VirtualBox. I suspect some sort of incompatibility between the two. However, since this application works on VMware VM, this incompatibility does not seem to be specific to virtual machines in general. It's the VirtualBox implementation that does not work.

Am I missing something here or is it a bug in VirtualBox? How can I get it fixed? I am not a developer myself, so I cannot propose a code change.

P.S. The application that I am using is a commercial software that has been published on Microsoft Store for years, so I have no reason to suspect it. It is using a standard Microsoft .NET API, so this is not a coding issue.

[fth0]

As a general idea: I could imagine that the .NET API reads some registry keys that were created at the time when Windows was installed, since the DMI information isn't supposed to change afterwards and registry accesses are probably cheaper than DMI accesses.

[FEHE]

As a general idea: I could imagine that the .NET API reads some registry keys that were created at the time when Windows was installed, since the DMI information isn't supposed to change afterwards and registry accesses are probably cheaper than DMI accesses.

I actually thought about that. I was thinking to create a new machine and run VBoxManage before installing Windows. On the other hand, if it were really the registry that stores this info, why do I not see the original value from the exported machine? I am afraid it could be a bigger issue.

[FEHE]

As a general idea: I could imagine that the .NET API reads some registry keys that were created at the time when Windows was installed, since the DMI information isn't supposed to change afterwards and registry accesses are probably cheaper than DMI accesses.

I tried that. Created a VM, updated system settings before installing. Did not help.

[fth0]

First of all, I don't know if the .NET APIs access DMI information at all, that was just an assumption. The documentation in SystemInformation.DeviceManufacturer Property is rather sparse.

Regarding the .NET APIs, I'd suggest to use Sysinternals Process Monitor to record and search for possible registry accesses. If you find corresponding registry keys, Google can probably deliver better detail information.

Regarding the DMI System information, it's perhaps located in the registry keys SystemManufacturer and SystemProductName under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation. Compare their values with the msinfo32 output.

[FEHE]

First of all, I don't know if the .NET APIs access DMI information at all, that was just an assumption. The documentation in SystemInformation.DeviceManufacturer Property is rather sparse.

Regarding the .NET APIs, I'd suggest to use Sysinternals Process Monitor to record and search for possible registry accesses. If you find corresponding registry keys, Google can probably deliver better detail information.

Regarding the DMI System information, it's perhaps located in the registry keys SystemManufacturer and SystemProductName under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation. Compare their values with the msinfo32 output.

Thank you for pointing me to Sysinternals. I found the registry keys that .NET API was reading. Those are:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]
"SystemManufacturer"
"SystemProductName"


However, there is still an issue with VirtualBox. I updated these keys via regedit and my software was able to read them, but when I restarted my VM, the keys were gone.

Finally, I checked these registry keys in VMware VM, they are all present under both paths. So this must be a bug in VirtualBox.

[scottgus1]

So this must be a bug in VirtualBox.

The only thing in Virtualbox that would possibly be able to cause a registry change in the VM OS would be the Guest Additions. Without Guest Additions, there is no way for Virtualbox to run commands inside the VM's OS.

So if you uninstall Guest Additions and try the test again and see what happens, then whether Virtualbox is causing this change will become apparent. (PS I don't know if you've done this before, but doing it again and reporting the results will make the report stand out and be easily see-able.)

[fth0]

However, there is still an issue with VirtualBox. I updated these keys via regedit and my software was able to read them, but when I restarted my VM, the keys were gone.

The latter is correct. The whole HKEY_LOCAL_MACHINE\HARDWARE registry section is volatile and only populated during Windows startup. In my own Windows 10 VMs, the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS section is empty (with the natural exception of the empty Standard key). Is this also the case in your setup?

Finally, I checked these registry keys in VMware VM, they are all present under both paths. So this must be a bug in VirtualBox.

I suspect that Windows uses a method to acquire the information from the BIOS that is not supported by VirtualBox. If I knew what method is used by Windows, I could check in the VirtualBox source code. But my google-fu wasn't good enough.

The only thing in Virtualbox that would possibly be able to cause a registry change in the VM OS would be the Guest Additions.

That's not entirely true from my POV. For example, VirtualBox provides the DMI information via virtual hardware. A windows guest OS can query (virtual) hardware at any time and put the information in the registry to speed up further queries.

[FEHE]

So this must be a bug in VirtualBox.

The only thing in Virtualbox that would possibly be able to cause a registry change in the VM OS would be the Guest Additions. Without Guest Additions, there is no way for Virtualbox to run commands inside the VM's OS.

So if you uninstall Guest Additions and try the test again and see what happens, then whether Virtualbox is causing this change will become apparent. (PS I don't know if you've done this before, but doing it again and reporting the results will make the report stand out and be easily see-able.)

I never installed Guest Additions on this VM, but I agree that my statement was somewhat ambiguous, so I will try to rewrite.

It seems like VirtualBox is not emulating that part of hardware information that Windows 10 is copying into the registry key HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS at every boot. This HW information is similar to DMI info, but it seems like there is a different mechanism to access it, which is missing from the VirtualBox implementation (and which exists in VMware). And because this information is not available, Windows erases all values from that registry key. Maybe it is part of the routine to erase all values at boot and then copy those that are available.

[FEHE]

In my own Windows 10 VMs, the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS section is empty (with the natural exception of the empty Standard key). Is this also the case in your setup?

Yes, in my VB VM the whole key (section) is empty. However, if I look at my VMware VM, there is lot of info:

Code: Select all

[HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]
"BiosMajorRelease"=dword:00000004
"BiosMinorRelease"=dword:00000006
"ECFirmwareMajorRelease"=dword:00000000
"ECFirmwareMinorRelease"=dword:00000000
"BaseBoardManufacturer"="Intel Corporation"
"BaseBoardProduct"="440BX Desktop Reference Platform"
"BaseBoardVersion"="None"
"BIOSReleaseDate"="12/12/2018"
"BIOSVendor"="Phoenix Technologies LTD"
"BIOSVersion"="6.00"
"SystemFamily"=""
"SystemManufacturer"="VMware, Inc."
"SystemProductName"="VMware Virtual Platform"
"SystemSKU"=""
"SystemVersion"="None"

Here is also how the same info looks on a real PC:

Code: Select all

[HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]
"BiosMajorRelease"=dword:00000001
"BiosMinorRelease"=dword:00000004
"ECFirmwareMajorRelease"=dword:000000ff
"ECFirmwareMinorRelease"=dword:000000ff
"BaseBoardManufacturer"="Dell Inc."
"BaseBoardProduct"="6GYJMK"
"BaseBoardVersion"="A00"
"BIOSReleaseDate"="12/23/2020"
"BIOSVendor"="Dell Inc."
"BIOSVersion"="1.4.3"
"SystemFamily"="Latitude"
"SystemManufacturer"="Dell Inc."
"SystemProductName"="Latitude 5511"
"SystemSKU"="09D2"
"SystemVersion"=""

I suspect that Windows uses a method to acquire the information from the BIOS that is not supported by VirtualBox. If I knew what method is used by Windows, I could check in the VirtualBox source code. But my google-fu wasn't good enough.

I agree with that, but I am not sure I can help you to find this method. I will try to talk to my developers, but I am afraid they would not know beyond the .NET API call.

Do you think it's time to open a bug ticket? Does this look like an issue that they will fix with priority?

[fth0]

I am not sure I can help you to find this method.

Well, you sort of did! Thanks for providing the example contents of the registry!

The key ECFirmwareMajorRelease led me to What is ECFirmwareMajorRelease in registry?, and the answer in turn links to "a Microsoft document that explains SMBios support status in Windows" from 2005: SMBIOS.doc. Within that document, the section System Identification describes the necessary conditions for populating the HKLM\Hardware\Description\BIOS registry subkey. A comparison with the (publicly available) VirtualBox 7.0.12 source code showed that the Enable Targeted Content Distribution bit in the BIOS Characteristics Extension Byte 2 field of the Type 0 SMBIOS table is not set by VirtualBox.

Do you think it's time to open a bug ticket?

Yes, please create a ticket in the Bugtracker. I'll then comment the ticket as necessary.

Does this look like an issue that they will fix with priority?

That's a question which is difficult to answer. We'll see ...

[FEHE]

Yes, please create a ticket in the Bugtracker. I'll then comment the ticket as necessary.

I opened https://www.virtualbox.org/ticket/21943
Please let me know if I did something wrong, I will edit it then.

[fth0]

The ticket is well formulated (much better than many other tickets ), I had nothing to add.

[FEHE]

The ticket is well formulated (much better than many other tickets ), I had nothing to add.

There is a comment in the ticket, that I do not have enough knowledge to argue with. I left a general comment, but I would appreciate your feedback. Thanks.

[fth0]

FWIW, the comment in the ticket was triggered by a chat between its author and me, so there's nothing to add to the ticket from my side. Ultimately, klaus comment means that the VirtualBox developers have to consider additional boundary conditions in the direction of "never change a running system", and it's not clear yet if and how they will change the current behavior of VirtualBox. We'll have to see if they take a closer look at it after the current holiday period ...