Windows 10 guest OS crashes with STATUS_DATATYPE_MISALIGNMENT exception

[hottobar]

My Windows 10 20H2 guest OS keeps crashing and rebooting after a few minutes of uptime, even when left at idle with no user activity. The amount of uptime before crash varies, from a couple of minutes to maybe 30'.

This is an extract of the VBox.log file with the exception (full log attached):

00:04:04.476177 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff80426ae4793 P3=0xffffbd0cd2c0237a P4=0x7010008004002001
00:04:04.476246 GIMHv: BugCheck 1e {ffffffff80000002, fffff80426ae4793, ffffbd0cd2c0237a, 7010008004002001}
00:04:04.476246 KMODE_EXCEPTION_NOT_HANDLED
00:04:04.476246 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
00:04:04.476246 P2: fffff80426ae4793 - EIP/RIP
00:04:04.476247 P3: ffffbd0cd2c0237a - Xcpt param #0
00:04:04.476247 P4: 7010008004002001 - Xcpt param #1
00:04:07.226307 AHCI#0: Reset the HBA
00:04:07.226322 VD#0: Cancelling all active requests
00:04:07.226560 AHCI#0: Port 0 reset
00:04:07.227608 VD#0: Cancelling all active requests
00:04:07.367081 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago
00:04:09.277149 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x1e P1=0xffffffff80000002 P2=0xfffff80426ae4793 P3=0xffffbd0cd2c0237a P4=0x7010008004002001

The VM's guest OS was freshly installed from Microsoft's ISO. No third party AV software nor drivers installed.

My host setup:

• OS: Ubuntu 20.04.1
• Kernel: tested with 5.8.0-41-generic (Ubuntu) and 5.9.16-050916-generic (mainline)
• System: HP ProBook 650 G8
• CPU: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
• VirtualBox: tested with 6.1.16 (Ubuntu's repo) and 6.1.18 r142142 (Oracle's repo)

Conditions that do not cause a crash:

• running the VM in safe mode
• running the VM in a different host with Ubuntu 20.04.1, kernel 5.8, Virtualbox 6.1.18 r142142, CPU AMD Ryzen 9 3900X
• converting the VM's vdi file to qcow2 and running it with KVM

What have been tested without success (VM still crashes):

• running it with a different CPU profile, "i7-6700K" instead of "host"
• uninstalling the VirtualBox Guest Additions
• changing the paravirtualization interface from "Default" to "Legacy"

This issue has been discussed in this forum post: ​https://forums.virtualbox.org/viewtopic.php?f=7&t=101667

Searching the forums for similar problems led to these apparently relevant discussions, all with no solutions nor workarounds:

• ​https://forums.virtualbox.org/viewtopic.php?f=7&t=101280
• ​https://forums.virtualbox.org/viewtopic.php?f=7&t=101353
• ​https://forums.virtualbox.org/viewtopic.php?f=7&t=99789

[fth0]

In the VirtualBox forums, this problem has been reported by at least 8 users in the last weeks and months. I've analyzed those cases and from my POV the following conditions apply:

1. The host CPU is always a 10th/11th generation Intel CPU, so far i7-1065G7, i5-1135G7 or i5-1185G7. Using older Intel CPUs or AMD CPUs does not exhibit the problem. VirtualBox does not know up to 20 new and previously reserved bits in the CPUID leaf 7.

2. On the host, a Linux kernel 5.8 or later is always running. Using a Linux kernel 5.4 does not exhibit the problem.

3. VirtualBox versions 6.1.14, 6.1.16 or 6.1.18 are being used. Running a VM with the same virtual disk in KVM or VMware does not exhibit the crash.

4. In the guest, Windows 10 or Windows Server 2016|2019 is running. Using Windows 7 or Linux does not exhibit the problem. It suffices to start a VM from a Windows 10 ISO and to wait, so no VirtualBox component is running inside the guest.

5. The crash occurs independent of the chosen Graphics Controller. It also occurs without configured audio and network devices.

The STATUS_DATATYPE_MISALIGNMENT exception inside the Windows guest OS is the most prevalent type of crash. There are several other types of crashes occurring less often, but always in the Windows kernel space. I could add them here if necessary.

Are there any other known problems with VirtualBox and 10th/11th generation Intel CPUs?

[hottobar]

Tested again the same VM, Linux 5.10.25 mainline kernel, and VBox 6.1.18 r142142 (Oracle's repo) with the same results:

00:00:05.011688 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff8063ec6457e P3=0x48589ee8 P4=0x0
00:00:05.011754 GIMHv: BugCheck 1e {ffffffff80000002, fffff8063ec6457e, 48589ee8, 0}
00:00:05.011755 KMODE_EXCEPTION_NOT_HANDLED
00:00:05.011755 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
00:00:05.011755 P2: fffff8063ec6457e - EIP/RIP
00:00:05.011755 P3: 0000000048589ee8 - Xcpt param #0
00:00:05.011755 P4: 0000000000000000 - Xcpt param #1

[hottobar]

Tested again the same VM, Linux 5.10.25 mainline kernel, and VBox 6.1.20 r143896 (Oracle's repo) with the same results:

00:30:18.095230 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff80582ce4793 P3=0xffffba80840362fc P4=0x7010008004002001
00:30:18.095305 GIMHv: BugCheck 1e {ffffffff80000002, fffff80582ce4793, ffffba80840362fc, 7010008004002001}
00:30:18.095306 KMODE_EXCEPTION_NOT_HANDLED
00:30:18.095306 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
00:30:18.095306 P2: fffff80582ce4793 - EIP/RIP
00:30:18.095306 P3: ffffba80840362fc - Xcpt param #0
00:30:18.095306 P4: 7010008004002001 - Xcpt param #1

[slvr]

FYI, I still see a kernel mode exception crash w/a Win10 (32-bit) VM and Linux x86_64 5.10.34 mainline kernel and VBox 6.1.22...

00:00:07.120137 GIM: HyperV: Guest indicates a fatal condition! P0=0x7f P1=0x11 P2=0x0 P3=0x0 P4=0x0
00:00:07.120177 GIMHv: BugCheck 7f {11, 0, 0, 0}
00:00:07.120178 UNEXPECTED_KERNEL_MODE_TRAP
00:00:07.120178 P1: 0000000000000011 - x86 trap number
00:00:07.120178 P2: 0000000000000000 - reserved/errorcode?
00:00:07.120178 P3: 0000000000000000 - reserved
00:00:07.120178 P4: 0000000000000000 - reserved
00:00:10.432240 GUI: Request to close active machine-window.

[farzad]

I am experiencing the same issue:

02:25:53.052036 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff8011bee4793 P3=0xffff890f26a0233a P4=0x7010008004002001
02:25:53.052096 GIMHv: BugCheck 1e {ffffffff80000002, fffff8011bee4793, ffff890f26a0233a, 7010008004002001}
02:25:53.052098 KMODE_EXCEPTION_NOT_HANDLED
02:25:53.052098 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
02:25:53.052099 P2: fffff8011bee4793 - EIP/RIP
02:25:53.052099 P3: ffff890f26a0233a - Xcpt param #0
02:25:53.052099 P4: 7010008004002001 - Xcpt param #1
02:25:56.008625 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago
02:25:56.843982 AHCI#0: Reset the HBA
02:25:56.843993 VD#0: Cancelling all active requests
02:25:56.844190 AHCI#0: Port 0 reset
02:25:56.845278 VD#0: Cancelling all active requests
02:26:07.277458 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x1e P1=0xffffffff80000002 P2=0xfffff8011bee4793 P3=0xffff890f26a0233a P4=0x7010008004002001
02:26:07.277620 GIM: HyperV: Reset initiated through MSR
02:26:07.277640 Changing the VM state from 'RUNNING' to 'RESETTING'
02:26:07.279613 GIM: HyperV: Resetting MMIO2 regions and MSRs

Linux Host: Linux pop-os 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC x86_64 x86_64 x86_64 GNU/Linux
Guest: Windows 10
CPU: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
VirtualBox: 6.1.18

[LievenV]

Same problem after a kernel upgrade from 5.3 to 5.12 on openSUSE 15.2.

00:02:04.990941 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff8055c6150da 
P3=0x0 P4=0x0
00:02:04.991083 GIMHv: BugCheck 1e {ffffffff80000002, fffff8055c6150da, 0, 0}
00:02:04.991084 KMODE_EXCEPTION_NOT_HANDLED
00:02:04.991084 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
00:02:04.991085 P2: fffff8055c6150da - EIP/RIP
00:02:04.991085 P3: 0000000000000000 - Xcpt param #0
00:02:04.991085 P4: 0000000000000000 - Xcpt param #1

OS: openSUSE 15.2
Kernel: 5.12.2-3.g6c0f44c-default #1 SMP Mon May 10 12:31:05 UTC 2021 (6c0f44c) x86_64
VirtualBox: 6.1.22 (from openSUSE repository (build.opensuse.org/home:frispete))
CPU: 8 × 11th Gen Intel® Core™ i7-1185G7 @ 3.00GHz
Guest: Windows 10 20H2

[zenone87]

I am experiencing the same issue. VirtualBox is impossible to use in this condition.

00:00:05.272516 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffff80000002 P2=0xfffff80057d34e11 P3=0xfffff80057cae000 P4=0xfc
00:00:05.272590 GIMHv: BugCheck 1e {ffffffff80000002, fffff80057d34e11, fffff80057cae000, fc}
00:00:05.272591 KMODE_EXCEPTION_NOT_HANDLED
00:00:05.272591 P1: ffffffff80000002 - exception code - STATUS_DATATYPE_MISALIGNMENT
00:00:05.272591 P2: fffff80057d34e11 - EIP/RIP
00:00:05.272591 P3: fffff80057cae000 - Xcpt param #0
00:00:05.272591 P4: 00000000000000fc - Xcpt param #1

OS: Fedora 34
Kernel: 5.11.20-300.fc34.x86_64
Virtualbox: 6.1.22 r144080 (Qt5.15.2)
CPU: 11th Gen Intel® Core™ i7-1185G7 @ 3.00GHz × 8
Guest: Windows 10 LTSC

[fth0]

TL;DR for VirtualBox users: Disable Split Lock Detection on the Linux host as a workaround, using the Linux kernel parameter split_lock_detect=off.

---

TL;DR for VirtualBox developers: Handle the Split Lock Detection MSRs in VirtualBox as a solution.

---

After a deep investigation, I've mostly understood the core issue:

Intel added Split Lock Detection to its 10th gen. CPUs ([1], [2], [3]), which can generate #AC (Alignment Check) exceptions independent of CR0.AM and EFLAGS.AC ([3]). Intel added another MSR bit for controlling the MSR from [3] to its 11th gen. CPUs ([4]).

The Linux kernel added Split Lock Detection between kernels 5.4 and 5.8 ([1], [2], [5], [7]), enabled by default. On the Linux host, it can be disabled with the kernel parameter split_lock_detect=off ([7]). This can serve as a workaround for the time being.

In the Windows 10 (64-bit) guest, the highly sophisticated and obfuscated Microsoft PatchGuard implementation crashes with a diversity of Windows exceptions, with the commonality of an occurred Alignment Check exception (no source for that ;-) ).

The Linux kernel patches for Split Lock Detection evolved in extensive discussions up to version v17 ([5]). In the earlier version v8 ([6]), there was a suggestion what to do for KVM, and I'd suggest to emulate those MSRs in VirtualBox, too:

---

==Expose to guest==

To expose this feature to guest, need to

1. Report the new CPUID bit to guest.
2. Emulate IA32_CORE_CAPABILITIES MSR.
3. Emulate TEST_CTL MSR. Since this patch series enable split lock

detection in host kernel by default, if do not emulate MSR_TEST_CTL for guest, guest will run with the value set by host without knowing that. So guest will run with split lock detection enabled due to the host's value. Thus guest running with buggy firmware and old kernel will fail because they lack the ability to handle #AC for split lock. So need to emulate MSR_TEST_CTL and separate its value between host and guest.

---

[1] ​https://lwn.net/Articles/790464/ LWN.net "Detecting and handling split locks"

[2] ​https://lwn.net/Articles/806466/ LWN.net "Developers split over split-lock detection"

[3] Intel SDM Vol. 4 Ch. 2.17.3 (10th gen. MSRs) Reg. 33H MSR_TEST_CTRL Bit 29

[4] Intel SDM Vol. 4 Ch. 2.17.4 (11th gen. MSRs) Reg. CFH IA32_CORE_CAPABILITIES Bit 5 (SPLIT_LOCK_DISABLE_SUPPORTED)

[5] ​https://lore.kernel.org/lkml/20200126200535.GB30377@agluck-desk2.amr.corp.intel.com/ [PATCH v17]

[6] ​https://lwn.net/ml/linux-kernel/1556134382-58814-1-git-send-email-fenghua.yu%40intel.com/ [PATCH v8 00/15]

[7] ​https://www.kernel.org/doc/html/v5.8/admin-guide/kernel-parameters.html

[Klaus Espenlaub]

Just to mention it here: #20165 is a duplicate and has a log for a 10th generation CPU (Ice Lake). The log above is for a 11th generation CPU (Tiger Lake).

[fth0]

Replying to klaus:

Just to mention it here: #20165 is a duplicate and has a log for a 10th generation CPU (Ice Lake). The log above is for a 11th generation CPU (Tiger Lake).

If you'd like to clean up: #19998 is another duplicate.

[slvr]

Just FYI, I noticed the split_lock_detect=off kernel parameter as a possible workaround, and I just verified that it does allow my Win10 guest to boot with Oracle's official build of VirtualBox 6.1.22 on a Slackware Linux x86_64 host with kernel 5.10.41, where I'd previously get a KERNEL_MODE_TRAP crash on every startup of the Win10 guest.

[    0.079780] Kernel command line: BOOT_IMAGE=linux ro root=10304 vt.default_utf8=0 i8042.nopnp=1 pci=nocrs split_lock_detect=off resume=/dev/nvme0n1p5
[    5.515797]     split_lock_detect=off

00:00:00.802688 CPUM: Matched host CPU INTEL 0x6/0x7e/0x5 Intel_Core7_IceLake with CPU DB entry 'Intel Core i7-6700K' (INTEL 0x6/0x5e/0x3 Intel_Core7_Skylake)

00:00:00.912498 Full Name:                       "Intel(R) Core(TM) i3-1005G1 CPU @ 1.20GHz"

[fth0]

@klaus:

Please take note of 20090. It is not a duplicate, but seems to have the same cause. The VirtualBox EFI BIOS seems to hang with 100% CPU usage, and disabling Split Lock Detection works around it.

[fth0]

Please try one of the VirtualBox test builds 6.1.23r145550 or later, which should solve the issue, and report back. TIA.

[fth0]

Please try VirtualBox 6.1.24, which should solve the issue, and report back. TIA.

[jamesrh]

I had the same symptoms. System details:

Host

• i5 System76 Lemur Pro laptop
• Ubuntu 20.04 w/ XFCE
• Kernel 5.11.0-7620-generic 21~1626191760~20.04~55de9c3~dev-Ubuntu SMP x86_64 GNU/Linux

Guest

• Windows 10 64bit Home

on VirtualBox version 6.1.18-dfsg-5pop0~1624392638~20.04~b904788~dev

Installing VirtualBox 6.1.24 from the virtualbox repo with apt solved the issue:

echo "deb https://download.virtualbox.org/virtualbox/debian focal contrib" | sudo tee -a /etc/apt/sources.list
wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -

sudo apt purge virtualbox-ext-pack virtualbox-guest-utils virtualbox
sudo apt update; sudo apt upgrade; sudo apt autoremove

sudo apt install virtualbox-6.1

Windows has been as stable as it ever is for a full day (it has not crashed, just is an annoying OS).

[galitsyn]

Hi guys,

We just released a new version of VirtualBox today. This issue should be fixed there. Closing it. Please leave a comment if it is still actual for you. As usual, builds are available on Downloads page. Thank you for reporting.