VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.
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.
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
I tried that. Created a VM, updated system settings before installing. Did not help.
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.
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.
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
Thank you for pointing me to Sysinternals. I found the registry keys that .NET API was reading. Those are:fth0 wrote: ↑26. Dec 2023, 00:26 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.
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.
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.)
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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?
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.
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.
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
I never installed Guest Additions on this VM, but I agree that my statement was somewhat ambiguous, so I will try to rewrite.scottgus1 wrote: ↑27. Dec 2023, 14:15The 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.)
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.
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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"
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 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?
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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.
Yes, please create a ticket in the Bugtracker. I'll then comment the ticket as necessary.
That's a question which is difficult to answer. We'll see ...
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
I opened https://www.virtualbox.org/ticket/21943fth0 wrote: ↑28. Dec 2023, 16:33 Yes, please create a ticket in the Bugtracker. I'll then comment the ticket as necessary.
Please let me know if I did something wrong, I will edit it then.
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
The ticket is well formulated (much better than many other tickets ), I had nothing to add.
-
- Volunteer
- Posts: 5678
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: VirtualBox implementation of Windows guest is incompatible with Microsoft .NET API
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 ...