virtualbox.org

Hi dear community,

i was reading this community since years and got almost every answer I could think of. Using Virtual Box with several Windows VMs on basis of CentOS (5 years), Slackware (10 years) and now Fedora (3 Month) .

- My Host-Server, Fedora 31 with Intel Core i7-6700 Quad Core: 64 GB DDR4: 2× 250 GB SSD.
- My VirtualBox runs 6.1.12 r139181
- no raid, ext4, SMART does not give any hints on SSD issues.
- Paravirtualization: Standard
- Having several Win10 installs and one Win81

Out of a sudden all the VMs are crashing - WIN10 with BSOD, WIN81 with kinda reboot.
Even a new VM install of WIN10 from ISO crashes within a minute with BSOD

Host System had no updates for about a week
- I was working for over a week with all instances without any issues.
- After this behavior I did dnf upgrade because, I thougth initially that the WIN10 instances had a bad update this morning.

Only change on the host-server:
- IPSEC-Tunnel
- Firewall-Rules
- using Port 3389

I have attachd
- a VM-Log for the WIN81
- a VM-Log for the WIN10-Install.

So as you can imagine, I need help, I'm lost.

Thanks for any advice
Schorsch

Please help me if I missed anything or lacking forum rules...

Shall I move to Windows Guest Systems?

It seems to me that I am facing an issue on Fedora regarding Hyper V.
I have running at the moment:
- 2x Windows 10
- 1x Windows 8.1

Could it be that these two Windows 10 guest are the issue using Hyper V at the same time?

00:00:08.732200 GIM: HyperV: Guest OS reported ID 0x1040a0000271b
00:00:08.732216 GIM: HyperV: Open-source=false Vendor=0x1 OS=0x4 (Windows NT or derivative) Major=10 Minor=0 ServicePack=0 Build=10011
00:00:08.732233 GIM: HyperV: Enabled hypercall page at 0x0000000000291000
00:00:08.732509 GIM: HyperV: Queried extended hypercall capabilities 0x1 at 0x0000000000007000
00:00:08.732526 GIM: HyperV: Enabled TSC page at 0x000000000000c000 - u64TscScale=0xc04cf200000000 u64TscKHz=0x34007e (3 407 998) Seq=1
00:00:08.732592 TM: Switching TSC mode from 'VirtTscEmulated' to 'RealTscOffset'
00:00:08.732654 GIM0: HyperV: Enabled APIC-assist page at 0x000000000000d000
00:00:08.749032 RTC: period=0x10 (16) 2048 Hz
00:00:08.945068 GIM1: HyperV: Enabled APIC-assist page at 0x000000003ffff000
00:00:08.948138 GIM2: HyperV: Enabled APIC-assist page at 0x000000003fffa000
00:00:08.949476 GIM3: HyperV: Enabled APIC-assist page at 0x000000003fff3000
00:00:12.207528 AHCI#0: Reset the HBA
00:00:12.207576 VD#0: Cancelling all active requests
00:00:19.468044 OHCI: Software reset
00:00:19.468140 OHCI: USB Reset
00:00:19.497112 HDA: Codec reset
00:00:19.497135 HDA: Reset
00:00:19.519341 OHCI: USB Operational
00:00:19.523696 HDA: Codec reset
00:00:19.523708 HDA: Reset
00:00:21.199004 HDA: Codec reset
00:00:21.771265 GIM: HyperV: Guest indicates a fatal condition! P0=0x7e P1=0xffffffffc0000005 P2=0xfffff80235669d64 P3=0xffffd208fa595a38 P4=0xffff8e80f453f920
00:00:21.771313 GIMHv: BugCheck 7e {ffffffffc0000005, fffff80235669d64, ffffd208fa595a38, ffff8e80f453f920}
00:00:21.771314 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

Schorsch28 wrote:Please help me if I missed anything or lacking forum rules...

Everything is fine with your posts, no problems, Just have to wait for someone who knows the solution to come along. (note that this person is not necessarily me... )

You're running official Virtualbox and Guest Additions from www.virtualbox.org, that's good.

Mentions of Hyper-V are the 'paravirtualization' communication channel between the virtualization-aware guest Windows OS's and the Virtualbox hypervisor. You don't have Hyper-V or anything else interfering on your Fedora host:

00:00:00.767194 HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support

Windows 8 guest BSOD 0x3b:

10:12:18.488602 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x3b P1=0xc0000005 P2=0xfffff9600011d646 P3=0xffffd000383fd2c0 P4=0x0

Windows 10 guest BSOD 0x1e booting from CD-Rom:

00:00:03.393780 VMMDev: Guest Log: BIOS: Booting from CD-ROM......
00:00:24.702980 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffffc0000005 P2=0xfffff801488407c7 P3=0x0 P4=0xffffffffffffffff

Windows 10 guest:

00:00:00.788574 NumCPUs (in the guest) = 0x0000000000000004 (4)
00:00:00.867917 CPUM: Logical host processors: 8 present, 8 max, 8 online, online mask: 00000000000000ff
00:00:00.867999 CPUM: Physical host cores: 4

All four physical cores are available for the guest to use, with the 1 core in the Windows 8 guest, you might be overloading the host. Set Windows 10 to 2 cores.

BSODs in both guests are more indicative of a host OS or Virtualbox problem.

If you changed this setting:

Schorsch28 wrote:- Paravirtualization: Standard

change it back to "default".

I would suggest a complete uninstall and reinstall of Virtualbox. Also try an intensive host memory test.

Hi scottgus1,

ok, thanks a lot for your reply.
This indicates me at least to be on the right perspective - the issues seems to be on the host side.

Just a few days ago I exactly did what you recommend. I reinstalled Virtualbox via appt WGET. But no success.

Unbelivable, but connected to the BSOD-issues: If I activate stronswan with ipsec for tunneling to a trusted network - this causes the BSOD in the guest systems. I do not need to access the guest hosts via RDP / IPSEC-Tunnel. Just the active Bridge with ipsec already causes the BSODs.

I did not have the time yet to look after the logs. Rather I switched on tunneling via VPN.

So, I will follow back on this thread, if I'll find something and let you know.

Best regards
Schorsch

Hi,

I just want to add to the thread that I am too facing the same issues.
Host is Linux Mint 20 'Ulyana' currently running Virtual Box 6.1.10_Ubuntu r138449
I am currently running several linux and windows guests. The two Linux guests, Xubuntu and Linux Lite, both work fine.

The Windows 10 guests however are suddenly resetting after a random amount of time, and it seems to be getting more and more frequent. Two weeks ago I could run it for hours when it suddenly happened, but when this just happened now I barely had time to collect data from the event viewer before the guest reset.
It eventually results in the guest not being able to boot and it 'needs to be repaired'.
It also happens to a newly installed instance of windows 10 with an iso from Microsoft.

Every time I have checked the vbox logs on a guest that has recently reset it seems to be the same pattern of event before it resets;

From the vbox log attached:
00:01:18.959663 VD#0: Cancelling all active requests
00:01:20.419201 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago
00:01:29.279337 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x3b P1=0xc0000005 P2=0xfffff8037b01b67a P3=0xffffaf033cc5eb20 P4=0x0
00:01:29.279690 GIM: HyperV: Reset initiated through MSR
00:01:29.279885 Changing the VM state from 'RUNNING' to 'RESETTING'

From the Windows Event Viewer:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000001e (0xffffffffc0000005, 0xfffff8047b2a2a6f, 0x0000000000000000, 0xffffffffffffffff). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: ...

Edit: Virtual box version

Same issue, posted about a month ago with no resolution given. Using fedora 32 64 bit though. Win 10/2016/2019 same issue.

Same here as well. Running Virtualbox 6.1.14 on Arch Linux 5.8.10 on a Dell XPS laptop with Intel i7-1065G7 proc. Issue also occurs with latest Virtualbox test build and development snapshot. I can run through the official ISO install of Windows 10, then just let it sit there for 10-15 mins and guarantee BSOD (usually KMODE exception).

Same VMs can run in VMWare Workstation on the same host just fine. Additionally same VMs can run on my AMD Ryzen 3700X box just fine running same version of Arch Linux and Virtualbox.

One other thing I noticed...EFI is completely broken. If you try to create a VM with EFI turned on, it just goes a black screen. EFI VMs boot up fine on the AMD box however.

I found a workaround for these issues! Hopefully it helps you out as well.

I've been getting random kernel panics and finally was able to capture a dump and analyze it. Found the offending process was VMWare Workstation (since I have been forced to use that without Vbox working). Pulling up the log from the dump showed thousands of 'kernel: x86/split lock detection: #AC: vmx-vcpu-0/3709 took a split_lock trap at address: 0x557357975651' followed by a double fault panic. Searching around for split_lock I came across this: https://lwn.net/Articles/816918/. Although they are only talking about VMWare here, I figured Virtualbox is no different from being affected.

So I put split_lock_detect=off in my kernel bootup parameters and rebooted...sure enough the Vbox issues I've been having are resolved. EFI mode works, Windows VMs are no longer BSODing. I had one Windows VM in particular that would BSOD on boot every single time. Now it's booting fine. I tested taking out the split_lock_detect parameter and the issues return. Put it back in and they are gone. I'm hoping this fixes my random kernel panics as well.

Hi,

I have tried the boot parameter you gave, but it doesn't help.
However, I found the following:
I have an IPSec road-warrior connection configured on my host. Without that connection, the WIndows10 guest runs just fine. When I connect the IPSec tunnel, the guest will powercycle shortly after.

This has driven me nuts, I even deleted my guest completely, and I couldn't reinstall it. It always kept powercycling after the first (regular) reboot during the installation process. Stopping IPSec let me finish the installation properly and I have a running guest again.

COuld it be IPSec-related for you too?

Folks,

I’ve been having problems trying to run ANY version of Windows 10 x64 as a guest under VirtualBox running on a Mint 20 (Cinnamon) host. I’ve tried Windows 10 releases 1803, 1809, 1903, 1909, and 2004 under versions 6.0.24 and 6.1.14 of VirtualBox. (I also tried an x86 version of Win 7 Pro). In all cases I was able to start the installation of Windows, and sometimes the installation would finish and Windows would actually start running before crashing. In other cases, the installation would crash at various (random) spots. Just now, I tried installing a Microsoft-provided Windows 10 image for VirtualBox (User name = ‘IEUser’). This prebuilt image also crashed after a couple of minutes!

These “Blue screen” crashes occur at random, but very frequently. Many different error code are displayed, KMODE, UNEXPECTED_STORE_EXCEPTION, and others.

I tried the “split_lock_detect=off” boot parameter, but that didn’t help. I’ve also tried changing a number of VirtualBox settings, but nothing I do seems to make any difference.

MOST SIGNIFICANTLY, I was able to run the latest Win 10 as a guest under VMware Workstation Player (under the same Mint 20 system as above) with no problems at all! (I’d prefer using VirtualBox since the VMware product remove the ‘Unity” option for Linux hosts.)

Since ALL Windows guests fail, it seems my problem must be caused by some incompatibility between Mint 20 (+ Ubuntu 20?) and VirtualBox. My test system is fairly old Dell XPS 8300 (I5-2300, 6GB of RAM, 120GB SSD) but runs Win 10 or Mint 20 fine as standalone systems.
==========================================================
UPDATE: I've attached the VBox.log file from the particular case of VirtualBox 6.1.10_Ubuntu r138449 with the guest being Windows 1809. Please note the "crash" being indicated as:

GIM: HyperV: Guest indicates a fatal condition! P0=0x3b P1=0xc0000005 P2=0xfffff80573839ee99 P3=0xffff8d8540ead6d0 P4=0x0

followed by: SYSTEM_SERVICE_EXCEPTION (which is the message displayed by the Windows guest)
===========================================================
Any thoughts/suggestions would be greatly appreciated!

Wayne

Hi,

It's maybe too late but i had the same problem with Windows crashing once i start IP Sec.
I figured it out that it was my usb C Dongle (that i used with my rj45 network cable) that cause this issue.

I don't know exactly why but that solve my problem but if that can help others !
----------
Zedcece

FrankWeis wrote:Hi,

I have tried the boot parameter you gave, but it doesn't help.
However, I found the following:
I have an IPSec road-warrior connection configured on my host. Without that connection, the WIndows10 guest runs just fine. When I connect the IPSec tunnel, the guest will powercycle shortly after.

This has driven me nuts, I even deleted my guest completely, and I couldn't reinstall it. It always kept powercycling after the first (regular) reboot during the installation process. Stopping IPSec let me finish the installation properly and I have a running guest again.

COuld it be IPSec-related for you too?

I don't have much time to troubleshoot this, but over some time I have had good experience with this fix.
I am using a VPN connection to a corporate network, and disconnecting from it makes my Windows boxes work normally.

Not sure if this information helps, but it's an IPsec tunnel to L2TP host (according to the configuration). PPP settings enabled: [PAP, CHAP, MSCHAP, MSCHAPv2, EAP, Allow BSD data compr., Allow deflate data compr., Use TCP header compr., Use protocol field compr. negotiation, Use address/control compr.].