Windows 10/11 VM crashed.

[grumblyman]

I'm not good at English, so I'm using a translation tool to write the text, so it may be difficult to read.

After applying a new cumulative update to my host OS on January 27th, my virtual machine started to hang or crash.
It hangs or crashes approximately 1-15 minutes after booting the virtual machine.

[Applied cumulative updates]
KB5009467
KB5009596

[System configuration]
VirtualBox 6.1.32 r149290 (Qt5.6.2)

*Host Machine
OS : Windows 10 Pro Ver. 21H2 (64bit)
CPU : AMD Ryzen 7 3700X
Memory : 32GB

*Virtual Machine
Windows 10 Pro (64bit)
Version : 21H2
CPU : 4
Memory : 9841MB
[System] > [Motherboard]
Chipset : ICH9
[System] > [Acceleration]
Paravirtualization Interface : Default
Hardware Virtualization : Enable Nested Paging = On
[Display] > [Screen]
Video Memory : 256MB
Graphics Controller : VBoxSVGA
VBoxGuestAdditions : Installed

Windows 11 Pro
Version : Insider Preview build 22533
CPU : 4
Memory : 4096MB
[System] > [Motherboard]
Chipset : ICH9
[System] > [Acceleration]
Paravirtualization Interface : Default
Hardware Virtualization : Enable Nested Paging = On
[Display] > [Screen]
Video Memory : 128MB
Graphics Controller : VBoxSVGA
VBoxGuestAdditions : Installed

The OS of the virtual machine to be crashed is Windows 10 and Windows 11.
The virtual machine with Ubuntu 18.04 installed did not crash even after leaving it for a while.

I uninstalled the cumulative updates for the host OS, but the event did not change.
I tried downgrading to VirtualBox 6.1.30, but the virtual machine still crashed.

Attached is the log of when Windows 10 crashed.
How to solve this problem?

[scottgus1]

You've a unique username:

00:00:02.538335 File system of 'C:\Documents and Settings\*******\.VirtualBox\HardDisks\Windows 10.vdi' is ntfs

I didn't know Windows allowed all asterisks (or any asterisks) in a user name....

In other words, if you feel the need to obfuscate the logs (like usernames, which can be very common, and one will still need the password, and the correct one of the 4 billion IPv4 addresses or one of the galaxy's worth of IPv6's to try it on, and we're all getting pen-tested by bots as we speak) please tell us what data type you obfuscated, so we know what data to distrust. Obfuscated but unreported logs may be ignored and/or deleted in the future.

You're running 6.1.32, which might have some bugs. Hopefully our forum gurus can determine the cause. Meanwhile you might try reverting to 6.1.30 or 6.1.26 and see if the VMs become stable again. https://www.virtualbox.org/wiki/Download_Old_Builds

[grumblyman]

Hi scottgus1.
Thank you for reading this.

I didn't know Windows allowed all asterisks (or any asterisks) in a user name....

I'm sorry, I hid the username with asterisks.
I guess I did something unnecessary...

You're running 6.1.32, which might have some bugs. Hopefully our forum gurus can determine the cause. Meanwhile you might try reverting to 6.1.30 or Hopefully our forum gurus can determine the cause. Meanwhile you might try reverting to 6.1.30 or 6.1.26 and see if the VMs become stable again.

Okay.
Downgrading to 6.1.30 didn't work, so I'll try 6.1.26 to see if it becomes stable.

[fth0]

Your issue is probably not related to the other reported issues with VirtualBox 6.1.32, so I don't expect downgrading to help in this case.

I've seen this special variant of the Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT) several times in the previous years (*). It occurs when a VM using the VirtualBox (U)EFI BIOS is restarted from within the guest OS. What happens if you start the VM again after the crash?

As a workaround, try not to restart the guest OS, but to shut it down and then start the VM anew. When you shut down the guest OS, make sure not to use Windows Fast Start (either disable it inside the Windows guest OS, or hold down the Shift key when selecting the shut down in the Windows Start Menu.

(*) AFAIK, the VirtualBox developers couldn't reliably reproduce this issue in the past.

[grumblyman]

Hi fth0.
Thank you for reading this.

You are right, downgrading VirtualBox did not solve the problem.

What happens if you start the VM again after the crash?

Windows starts booting as normal. Of course, the system suddenly stops, so I do it twice in a row and it automatically starts the automatic Windows repair. (For some reason, the auto-repair fails, but I can still boot.)

As a workaround, try not to restart the guest OS, but to shut it down and then start the VM anew.

It's true that the Windows 10 VM setup uses the UEFI BIOS, so the "restart the OS" fails.
I understood that this is a specification.
So you're saying that "Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)" didn't cause the system to crash?

When you shut down the guest OS, make sure not to use Windows Fast Start (either disable it inside the Windows guest OS, or hold down the Shift key when selecting the Selecting the shut down in the Windows Start Menu.

I'm not sure if "Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)" has anything to do with the system crash.
I'll try to change the "Fast Startup" setting, as it seems to be worth a try at least.
However, since there was no "Fast Startup" item in the control panel, I used the Registry Editor to change the setting.

Code: Select all

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
"HiberbootEnabled"=dword:00000000

We will provide the verification results later.
(I'm assuming we'll have to revert to the host OS backup since we don't want it to be unusable as is.)

[fth0]

It's true that the Windows 10 VM setup uses the UEFI BIOS, so the "restart the OS" fails.
I understood that this is a specification.
So you're saying that "Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT)" didn't cause the system to crash?

No. Ok, I'll try to explain a bit better what I see in the VBox.log file you provided:

The virtual machine (VM) is configured to use the VirtualBox (U)EFI BIOS and not the VirtualBox legacy BIOS. In consequence, the VM starts booting from the (U)EFI BIOS at 00:00:03.375 and then from the virtual hard disk, including loading the VirtualBox Guest Additions, until everything is done at 00:00:45.

At 00:03:28, a normal reboot is initiated from within the guest OS (either by you or the guest OS itself), which is not a crash. During this reboot, after booting from the (U)EFI BIOS again at 00:03:45.284, at 00:03:45.983 the Guru Meditation 1155 (VINF_EM_TRIPLE_FAULT) occurs, and this is the crash.

If my description does not match your perception of the events, reproduce your issue, note down the wall clock times of important events and provide a (zipped) VBox.log file accompanied with your description.

[grumblyman]

Hi fth0.

Thank you for the detailed explanation.
(It's hard to understand English...)

What I understood from your explanation is that the VM is not crashing, but experiencing a (unexplained) reset.
However, when I reboot in a VM using (U)EFI, the final result is "Guru Meditation", right?

Is it possible to analyze the unexplained reset from VirtualBox logs?

If not, I would like to revert to a backup, as it may be due to the state of my PC.

[fth0]

It's hard to understand English...

You could try if Google Translate gives a good translation of my posting into Japanese (if I guessed correctly).

What I understood from your explanation is that the VM is not crashing, but experiencing a (unexplained) reset.
However, when I reboot in a VM using (U)EFI, the final result is "Guru Meditation", right?

No. The VM is crashing with the Guru Meditation after a reboot. Perhaps your understanding of the terms "crash", "reset" and "reboot" is not correct ...

Is it possible to analyze the unexplained reset from VirtualBox logs?

Possible, yes. Feasible, no. Anyway, I wouldn't hold my breath.

[grumblyman]

Thanks for the reply.

No. The VM is crashing with the Guru Meditation after a reboot. Perhaps your understanding of the terms "crash", "reset" and "reboot" is not correct ...

It seems that I misunderstood that the VM was crashing when the guest OS was crashing.
Please let me correct it.
It was not a VM crash that was occurring, but a guest OS crash (rebooting on its own).

I have personally investigated this.
I actually thought that the "Avast! Free Anti-Virus" installed on the host OS was suspicious, so I did a search and found someone who had a similar problem.
I found someone who had a similar problem. I read that the following settings stabilized the operation of VirtualBox, so I tried them and the operation stabilized.
I didn't touch this setting, so I don't know how it relates to Windows updates, but it may have triggered it.

Code: Select all

Settings of Avast! Free Anti-Virus on the host OS
[Menu] - [Settings] - [General] - [Troubleshooting]
Uncheck "Enable hardware-assisted virtualization"
Restart the host OS

Thank you very much for your help in investigating the problem.

[grumblyman]

Hi, scottgus1

After all it was caused by my PC environment.
I posted the details before, but the anti-virus software was bad.

We apologize for the inconvenience, but this case has been resolved successfully.

Thank you for your cooperation.

[scottgus1]

Not a problem at all. Glad you got things going!