Emulated hardware BIOS info is not propagated to Windows hosts' registry

[fehe]

This issue was discussed and analyzed in details in ​https://forums.virtualbox.org/viewtopic.php?t=110769.

Description

When Windows host is started, the BIOS information is copied automatically to the registry key [HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]. The process and the requirements for this functionality are described by Microsoft in ​http://download.microsoft.com/download/5/D/6/5D6EAF2B-7DDF-476B-93DC-7CF0072878E6/SMBIOS.doc.

Based on the analysis of the VirtualBox source code done by user "fth0", the issue happens due to 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.

How to reproduce the issue

1. Create a Windows 10 VM
2. Set HW info using VBoxManage:

  VBoxManage setextradata "VM name" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "Oracle"
  VBoxManage setextradata "VM name" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "VirtualBox"

3. Power-up the VM
4. Check registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation]
5. Check registry key [HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]

The latter key will be empty after boot, which in turn creates an issue for Microsoft .NET API:

​https://learn.microsoft.com/en-us/dotnet/api/microsoft.toolkit.uwp.helpers.systeminformation.devicemanufacturer?view=win-comm-toolkit-dotnet-7.1

​https://learn.microsoft.com/en-us/dotnet/api/microsoft.toolkit.uwp.helpers.systeminformation.devicemodel?view=win-comm-toolkit-dotnet-7.1

and maybe some others.

We also checked the content of this registry key in a Win10 VM running in VMware and on a real PC - the data is populated correctly (see the forum link).

[Klaus Espenlaub]

Microsoft's document doesn't state that the Enable Targeted Content Distribution bit must be set. Just that it is a prerequisite for populating the registry etc. - yes, it would be required to be set for participating in the "Designed for Windows" logo program starting with Vista. VirtualBox doesn't participate in any such logo programs.

Bottom line: applications have to live with whatever they get through the registry or WMI (which will be used by the .NET API). The links you point to are stating it clearly that empty values can happen when Windows can't find out the value.

Changing the bit is a potential compatibility issue for existing VMs: suddenly there would be information which wasn't there before. Tricky.

[fehe]

I cannot modify Microsoft .NET API. It reads from the registry. The value is automatically populated by the guest OS once the bit is set. So it is a virtual hardware issue.

[fehe]

Believe me when I say that I am a big fan of "never change a running system" approach. However, we need to find a balance between that and a normal evolution of the system. For example, I was happy with Windows 95, I hate that they discontinued Windows 7, but you cannot stop the technological progress and you need to keep up with it.

In this particular case, what side effects are you expecting anyway? Up until now the bit was not set and the registry is not populated. Now the registry will contain the HW info under the condition that the user had set it with VBoxManage. If they haven't used this info before, how will it affect them now?

Also you can limit this functionality to Windows VMs only. VirtualBox has this info from the VM properties.

Can you give it at least a try to see that this bit is working and the HW info is propagated into the registry as expected?

Once again I want to remind you that this is working fine in VMware, so why would it break something in VirtualBox?

[fehe]

Another solution that I can suggest is to make this functionality a configurable setting in the VM properties.

[Klaus Espenlaub]

My point is that there might be (VirtualBox) VMs out there which behave as expected purely because the .NET API is returning empty strings. Because that's how things in VirtualBox behaved for 15+ years. Never populating the registry. My guess that this could be the case is as good or bad as your guess that it wouldn't be the case.

However, adding a setting is going to be difficult to use (and document) properly. Not worth it.

If you get the latest development snapshot test build (unfortunately we can't currently update the macOS ones, they're not including the change) then it will have the "keep fingers crossed" change included.

[fehe]

I obviously do not understand all the specifics of VirtualBox product, but my impression was that you were reluctant to introduce this change. However, after the last comment it seems like the fix will be available for the Windows host version in the next release. Could you please confirm my understanding. Thanks.

[fth0]

On the VirtualBox test builds page, you'll find the VirtualBox 7.0.97 "Development snapshots" and the VirtualBox 6.1.49 and 7.0.13 "test builds".

From Klaus' words I'd deduce that only the VirtualBox 7.0.97 development snapshots contain the change, which postpones the potential risks until a future VirtualBox 7.1 release.

[Klaus Espenlaub]

I am still reluctant, which shows in the way we're integrating the change. Which is as fth0 describes: right now it is part of the development snapshots only, and once it's verified to work (and not causing immediate screams of endless trouble with Windows activation) it can go into 7.0.

It's impossible to test in the usual sense for problems with activation, because Microsoft doesn't want to have a clear specification out there. Unavoidable to leave the fun to random guinea pigs from our user base, but at the same time no reason to ruin everyone's day without prior warning.

[fehe]

Thank you both, I appreciate your help. I should be able to test the fix by the end of the month.

Please keep posting to this ticket if there are any issues.

[fehe]

I installed the latest development snapshot VirtualBox-7.0.97-161444-Win.exe, but the issue is still present. Can somebody please check this? Thanks.

[Klaus Espenlaub]

The change is in r102788 (which went into the Oracle 7.0.97 builds with revision 160969 and later).

[fehe]

I tried tualBox-7.0.97-161444-Win.exe and the fix did not work.

[fth0]

What "did not work": Enabling the registry key or only your use of the .NET API?

[fehe]

@fth0, I did not see your comment.

I followed the same steps, that I put into the description of the ticket. I imported a VM, I updated DMI values and then I powered up the VM. And I did not see the data being copied into [HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS]. The key remained empty after boot.