Page 1 of 1

VMs crash when VM OS Version set to Window 2019

Posted: 5. Nov 2020, 01:09
by meslzu
Hello,

Virtualbox 6.1.16 (also 6.1.14) - host Win10 2004 19041.572

I can't start VMs because I receive the message that a critical error occurred
Ex. trying to install Windows 2019 crash at very beginning of setup (also fresh new VM (4gb ram - 40GB dynamic VDI disk)

Could you help me to find the problem?

Edit: updated post reverted to VirtualBox-6.1.14-140239 the error persist (also recreating a new VM)

EDIT2: followed the advices I have freed up resource on the host machine and now other VMs run correctly

BUT I think I found a bug:

With Windows server 2019 setup if I set OS Version in VM settings to "Windows 2019" the VM crash at very beginning of the setup
Instead it start without problem with OS set to "Windows 2016" or "Windows 2012"


Could you confirm that?
What are the difference in the emulation between this two settings?

A quick look at the code https://www.virtualbox.org/svn/vbox/tru ... Global.cpp
reveal that the proposed VM settings are the same


{ "Windows", "Microsoft Windows", "Windows2016_64", "Windows 2016 (64-bit)",
VBOXOSTYPE_Win2k16_x64,
VBOXOSHINT_64BIT |
VBOXOSHINT_HWVIRTEX |
VBOXOSHINT_IOAPIC |
VBOXOSHINT_USBTABLET |
VBOXOSHINT_USB3,
2048,128, 50 * _1G64, GraphicsControllerType_VBoxSVGA, NetworkAdapterType_I82540EM, 0, StorageControllerType_IntelAhci, StorageBus_SATA,
StorageControllerType_IntelAhci, StorageBus_SATA, ChipsetType_PIIX3, AudioControllerType_HDA, AudioCodecType_STAC9221 },

{ "Windows", "Microsoft Windows", "Windows2019_64", "Windows 2019 (64-bit)",
VBOXOSTYPE_Win2k19_x64,
VBOXOSHINT_64BIT |
VBOXOSHINT_HWVIRTEX |
VBOXOSHINT_IOAPIC |
VBOXOSHINT_USBTABLET |
VBOXOSHINT_USB3,
2048,128, 50 * _1G64, GraphicsControllerType_VBoxSVGA, NetworkAdapterType_I82540EM, 0, StorageControllerType_IntelAhci, StorageBus_SATA,
StorageControllerType_IntelAhci, StorageBus_SATA, ChipsetType_PIIX3, AudioControllerType_HDA, AudioCodecType_STAC9221 },


I updated the attached logs with both settings (OK - 2016 and KO - 2019)

Thank you

Re: VMs crash at startup

Posted: 5. Nov 2020, 17:09
by scottgus1
Double-posting like you did here: viewtopic.php?f=6&t=100485&p=487886#p487871 is against the rules. Please don't do it again.

You had a triple-fault guru meditation after touching the CD-ROM.
00:00:04.392293 Host RAM: 16375MB (15.9GB) total, 1119MB available
00:00:04.624238 RamSize <integer> = 0x0000000100000000 (4 294 967 296, 4 096 MB, 4.0 GB)00:00:04.624514 VRamSize <integer> = 0x0000000008000000 (134 217 728, 128 MB)
RAM is seriously over-committed. Stop some programs on the host OS.

Give the guest 2 processors. Windows 2019 is like 10 with less eye candy and more server, and 10 likes two processors. You have 4 available.

Re: VMs crash when VM OS Version set to Window 2019

Posted: 13. Nov 2020, 11:15
by meslzu
Thank you scottgus1

I followed your advices and now I partially solved the problem but I think I've found a bug

I updated the first post with the new behavior of the problem
Thank you

Re: VMs crash when VM OS Version set to Window 2019

Posted: 13. Nov 2020, 17:27
by scottgus1
There should be no difficulty running the guest as a 2016 guest with 2019 installed, as far as I know.

The only trouble I know of with the 2019 template, which was reported by forum guru fth0 to be in both the 2019 and 2016 templates, is that the Paravirtualization interface on Guest Settings > System > Acceleration should be set to Hyper-V (it may be set to none or something else). Note this does not enable Hyper-V on the host PC, it only allows the guest OS and Virtualbox to talk to each other in a 'language' that the guest OS understands.

Unfortunately this might not be your guest's problem: both your "ko" and "ok" logs show paravirtualization set to "none". Set it to Hyper-V anyway.

I don't see any difference in your logs, except that the guest guru-meditates in the 2019 log, whereas the 2016 log finishes correctly. There might be a difference in there. More lynx-eyed folks than me will have to find it.

Meanwhile, if the 2019 OS runs on the 2016 template, letting it do so shouldn't be a problem.

Re: VMs crash when VM OS Version set to Window 2019

Posted: 13. Nov 2020, 18:39
by meslzu
Thank you scottgus1

As you suggested I modified the VMs to set System > Acceleration to Hyper-V
but also after that the VM only works when is set to 2016, keep crashing when set to 2019

So it seems that the OS version settings affect something in the running of VM (I thought the setting was only about the icon and the preset when you create a new VM)

Meanwhile I use it with 2016 setting but I'm curios to find out why and crack the bug ;)

Re: VMs crash when VM OS Version set to Window 2019

Posted: 13. Nov 2020, 22:41
by fth0
meslzu wrote:I'm curios to find out why and crack the bug ;)
Perhaps I can help you with that:

If you search both VBox.log files for CMPXCHG16B, you'll see the differences. If you then take a look at the VirtualBox source code at ConsoleImpl2.cpp#L936, you don't have to be a developer to guess what's probably missing. ;)

PS: I've created a bug ticket: 20034.

Re: VMs crash when VM OS Version set to Window 2019

Posted: 16. Nov 2020, 09:53
by meslzu
Thank you fth0,

I agree, the problem is definitely caused by the missing cmpxchg16b in 2019 os type

Meanwhile code is changed we can stay with 2016 settings

Re: VMs crash when VM OS Version set to Window 2019

Posted: 16. Nov 2020, 11:19
by fth0
Hmm, my theory doesn't hold any more (or is incomplete):

Coincidentally, I needed a Windows Server 2019 VM yesterday, and I deliberately set one up with standard settings to see the crash for myself. While the log message showing the hack didn't appear as expected, the CPU feature was provided to the guest OS nonetheless, and no crash occurred. There must be more ...

Re: VMs crash when VM OS Version set to Window 2019

Posted: 16. Nov 2020, 14:25
by fth0
I can fill in the missing bit now:

The hack (or workaround) is only necessary, if the host CPU is missing either the EPT or the Unrestricted Guest CPU feature, which is only the case for older CPUs. Your host CPU is missing the latter.