virtualbox.org

Just wanted to chime in with the same issue and a slightly newer kernel:

• OS: Ubuntu Hirsute (21.04) beta
• Kernel: 5.11.0-11
• VirtualBox: 6.1.18_Ubuntu r142142
• Hardware: Lenovo X1 Carbon Gen9 with Intel Tiger Lake CPU: i7-1165G7, 16GB RAM.
• Guest: Win10 Pro 2004 x64 (2 VCPUs, 2GB RAM)

I used to run this VM on an Ubuntu 20.10 host on a Ryzen 3700U CPU without issues.

I would concur based on the stats gathered in this thread that this looks like an issue with Intel 10th and 11th gen CPUs (Ice/Tiger Lake).

I did notice one virtualization setting in my BIOS that I hadn't seen before: "Kernel DMA Protection"; when it was enabled the VM would crash within seconds of booting; disabling it allowed it to run 12 minutes, although this could be a mere coincidence...

Please let me know if there's any way I can assist in the resolution of this issue...

any solution?
still not working!

Ufuk wrote:
any solution?
still not working!

At this point nobody knows.

A ticket has been opened (https://www.virtualbox.org/ticket/20180) but the developers haven't commented yet.
We don't know if a solution will be provided in the next VB release or even if the problem has been acknowledged.

Any attempt to find the root cause and a workaround have failed.

I moved my VM to Qemu and I suggest anybody affected to do the same.

tested the beta Version 6.1.19 r143678 (Qt5.6.1)
the problem is not resolved.
but what are the developers waiting for?
which tests are more important than these ???

fantic10 wrote: but what are the developers waiting for?

Why don't you ask them? Do remember to quote your service contract reference number.

The rest of us, not due any support, must report the problem and then wait patiently for it to become a priority.

If indeed a problem is ever confirmed: so far the only fault being reported is by the Win10 guest. All VirtualBox does is acknowledge the report. The event doesn't seem to be related to anything nearby it in the log.

Disabling the Hyper-v para-v API to the guest will prevent VirtualBox from seeing the error report. However that may simply move the problem onto the guest's error reporting mechanism, i.e. the guest may BSOD.

Another thing you can do is trying disabling certain problematic features in the VM: don't use saved states (I suggest you make that permanent), disable 3D acceleration, disable audio: the latter two should be tried one at a time. If none of this makes a difference then it doesn't look like a VirtualBox related problem.

hottobar wrote:I moved my VM to Qemu and I suggest anybody affected to do the same.

FWIW, I have just done the same with mine. It's not entirely trivial; and then I am well versed with KVM/QEMU/virt-manager, having used these extensively over 5+ years, albeit with Linux and BSD guests.

Performance seems comparable at first glance. Some convenience features are definitely easier with VirtualBox: dynamic guest display resolution adjustment to virtual console size and shared folders are two I noted; until I get used to it, I suppose. Oh, and it's definitely easier to setup bridged networking in VirtualBox. With KVM/QEMU, I had to resort to NAT as I couldn't figure out how to set-up a bridge with my WLAN NIC without replacing NetworkManager with systemd-networkd, which would be a pain for things like switching WiFi networks among others.

Anyway, if there's interest I can post the steps I used for the VM conversion.

mpack wrote:If none of this makes a difference then it doesn't look like a VirtualBox related problem.

The fact that my Win10 VM, which used to work fine under a very close version of VirtualBox but on different hardware (Ryzen 3700U vs Intel Tiger Lake), now also works fine on that same Tiger Lake hardware but on a different hypervisor, certainly does suggest that there is an issue with VirtualBox. Many of the reports on this thread explicitly mention Tiger Lake/Ice Lake CPUs so a correlation looks likely IMHO.

sxc731 wrote:

hottobar wrote:I moved my VM to Qemu and I suggest anybody affected to do the same.

FWIW, I have just done the same with mine. It's not entirely trivial; and then I am well versed with KVM/QEMU/virt-manager, having used these extensively over 5+ years, albeit with Linux and BSD guests.

Unfortunately you're right, Qemu is not as user friendly as VirtualBox for desktop use.

Wifi bridging is something I haven't figured out yet and am using a wired connection for the time being.
Another problem is Linux->Win folder sharing, which on VB is pretty straightforward while on Qemu is confusing to say the least and I'm considering using RDP for that.

I really hope a solution will eventually be found to fix these Win 10 guest instabilities on VB...

If you want to post your procedure to migrate a Win10 guest to Qemu I think it would be useful to many.

hottobar wrote:I really hope a solution will eventually be found to fix these Win 10 guest instabilities on VB...

I have been looking for a way to circumvent the crashes in the 64-bit Windows kernel by using a kernel debugger, but didn't get there yet. But by coincidence, I've got a new idea this weekend when analyzing a VBox.log file from a totally different type of crash, where a user with an Intel 11th gen. CPU tried to start a VM with a Windows 7 32-bit ISO file.

If you still have the VirtualBox setup, can you please try what happens when starting from a Window 10 32-bit ISO?

fth0 wrote:If you still have the VirtualBox setup, can you please try what happens when starting from a Window 10 32-bit ISO?

I tried to configure a new VM with a 32bit ISO but Windows BSODs almost immediately with an UNEXPECTED KERNEL MODE TRAP error.

Interestingly enough, there is a commonality with the 64-bit cases:

The UNEXPECTED_KERNEL_MODE_TRAP is an Alignment Check Fault/Exception (0x11), which is typically a user mode exception. This doesn't make sense for me yet ...

the posts of the last days have disappeared.
I do not see them

Same here; looks like a faulty backup/restore?

Nope, I deleted them. Posts of "no change in version x" are not necessary, people can see changelogs for themselves.

The subject of this topic is the STATUS_DATATYPE_MISALIGNMENT error. Anything not useful to helping others work around that error will be deleted.

the problem remains however, I hope that this post is still known to programmers. at this point I will no longer disclose my tests.
do not delete this post

I am facing the same issue, and updated reports about new kernels / VBox versions / etc actually help a lot to avoid time consuming redundant testing.
Finding and parsing the changelog is an extra step when searching for a solution, plus it is not so obvious that this would even appear in a changelog, as it only occurs with particular combinations of CPU, kernel and VBox.
Really hoping for progress, this is quite a show-stopper for me.