virtualbox.org

Hi,

I'm running into an issue with a VM running Xubuntu 20.04.
It seems like when there's a bit more HDD activity (via shared folders), the VM causes the host system to freeze for a split second before rebooting immediately. No error message, no BSOD.

I've checked the HDD in question with chkdsk and it reported no errors. I'm also running into absolutely no issues otherwise when this HDD is in use (outside of a VM), so I think it's unlikely to be a disk issue.
Windows Event Viewer doesn't really show much to go on. Between the Kernel-Power event and EventLog event telling me about the unexpected shutdown, there is only an entry about how the dump could not be created (funnily enough, due to "error during dump creation"). The entry before those was 40 minutes old at that point.

It's literally only this VM causing issues. My vagrant boxes do not encounter/cause any issues like this.

Edit: Now it also happened while I was looking at a log file. No substantial HDD activity at all. Could it be that the VM is just entirely messed up?

I'm running
Windows 10 2004
VirtualBox 6.1.12

This could indicate not limited to:

1) A error in VirtualBox kernel drivers (sounds unlikely 'cause otherwise it would have been reported a lot more often)
2) A error in other Windows drivers which conflict with VirtualBox
3) A conflict in various virtualization drivers
4) General host OS instability (caused by hw, e.g. RAM/CPU/MB/PSU or software, e.g. AntiVirus errors)

Start the guest from full power off, not save-state. Run until you see the problem happen, then shut down the guest from within the guest OS if possible. If not possible, close the Virtualbox window for the guest with the Power Off option set.

Please right-click the guest in the main Virtualbox window's guest list, choose Show Log. Save the far left tab's log, zip the log file, and post the zip file, using the forum's Upload Attachment tab.

Please right-click the guest in the main Virtualbox window's guest list, choose "Show in Explorer/Finder/File Manager". In the window that opens, zip the guest's .vbox file, and post the zip file, using the forum's Upload Attachment tab.

Thanks for chiming in.

birdie wrote:This could indicate not limited to:

1) A error in VirtualBox kernel drivers (sounds unlikely 'cause otherwise it would have been reported a lot more often)
2) A error in other Windows drivers which conflict with VirtualBox
3) A conflict in various virtualization drivers
4) General host OS instability (caused by hw, e.g. RAM/CPU/MB/PSU or software, e.g. AntiVirus errors)

This is what is so puzzling about this issue: I have used this VM on the same exact system (no hardware/deliberate software changes at least, but there might've been Windows Updates in the meantime) before with absolutely no issues. I have no clue why this started happening.

scottgus1 wrote:Start the guest from full power off, not save-state. Run until you see the problem happen, then shut down the guest from within the guest OS if possible. If not possible, close the Virtualbox window for the guest with the Power Off option set.

Please right-click the guest in the main Virtualbox window's guest list, choose Show Log. Save the far left tab's log, zip the log file, and post the zip file, using the forum's Upload Attachment tab.

Please right-click the guest in the main Virtualbox window's guest list, choose "Show in Explorer/Finder/File Manager". In the window that opens, zip the guest's .vbox file, and post the zip file, using the forum's Upload Attachment tab.

I have always started the VM fresh and it's impossible to shut down/close the VM normally as the issue is that while running it for a couple of minutes my entire system freezes for less then a second and then immediately reboots with no chance for me to intervene.

The latest log and the vbox files are attached to this post. Thanks for looking into this.

I don't see anything egregiously wrong in the log or the .vbox, myself.

Can you please make a brand new Xubuntu guest, using the New Guest Wizard's defaults? Set the processor count to 2, regular and video RAM and network same as what you have now in the old Xubuntu guest, no other changes. Try installing Xubuntu in that guest and run it, see if the same crash happens.

scottgus1 wrote:I don't see anything egregiously wrong in the log or the .vbox, myself.

Can you please make a brand new Xubuntu guest, using the New Guest Wizard's defaults? Set the processor count to 2, regular and video RAM and network same as what you have now in the old Xubuntu guest, no other changes. Try installing Xubuntu in that guest and run it, see if the same crash happens.

So I've tried this and a few other things just now.
I've set up a fresh VM like you said, installed Xubuntu (I actually also tried it with regular ole Debian yesterday, same issue) and after a while it crashed.
Then I disabled the shared folders. It crashed.
Then I uninstalled the guest additions. It crashed.

On a hunch, I actually replaced the sound card in my computer because the one I was using is only kinda supported on Windows 10; that didn't help, either. Crashed again.

I have absolutely no clue what is going on here. Vagrant boxes work perfectly and I have no other issues with my system. It's just this.

Edit:
I've updated VirtualBox to the version that was released yesterday and I've enabled Hyper-V.
Now, instead of crashing my entire system, I actually get an error message and some log entries. I've attached the log... maybe you can make anything of this?

You had a guru meditation over a triple fault, which is Virtualbox's throwing up its hands because it can't figure out what to do.

Hyper-V is enabled, which has in the past and might now be the cause of the guru meditation.

You also have 3D acceleration enabled, and your Nvidia drivers are being caught in hardening:

00:00:03.244506 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: rc=VERR_CR_X509_CPV_NOT_VALID_AT_TIME fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume8\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_ba8c9c14f3d320cb\
nvldumdx.dll: Certificate is not valid

This is an ongoing issue, no one knows if it's Nvidia's or Virtualbix's fault or both yet.
Turn off 3D or try Nvidia drivers from around June or earlier 2020.

Try Xubuntu again with Hyper-V and 3D acceleration off.

Vagrant's guests should show what settings they are set to use. We don't grok Vagrant here, so we couldn't help reading their scripts or setup files. But if you could Vagrantize an Xububtu guest which does run, then at some point there would be a .vbox file in that working guest's folder, which you could zip and post along with the old failing Xubuntu's .vbox file, we could compare them.

In the VM configuration of your previous VM, go to System > Acceleration. Set Paravirtualization Interface to Default or KVM, and enable Nested Paging. Does the problem persist?

scottgus1 wrote:You had a guru meditation over a triple fault, which is Virtualbox's throwing up its hands because it can't figure out what to do.

Hyper-V is enabled, which has in the past and might now be the cause of the guru meditation.

You also have 3D acceleration enabled, and your Nvidia drivers are being caught in hardening:

00:00:03.244506 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: rc=VERR_CR_X509_CPV_NOT_VALID_AT_TIME fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume8\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_ba8c9c14f3d320cb\
nvldumdx.dll: Certificate is not valid

This is an ongoing issue, no one knows if it's Nvidia's or Virtualbix's fault or both yet.
Turn off 3D or try Nvidia drivers from around June or earlier 2020.

Try Xubuntu again with Hyper-V and 3D acceleration off.

Vagrant's guests should show what settings they are set to use. We don't grok Vagrant here, so we couldn't help reading their scripts or setup files. But if you could Vagrantize an Xububtu guest which does run, then at some point there would be a .vbox file in that working guest's folder, which you could zip and post along with the old failing Xubuntu's .vbox file, we could compare them.

Yeah, Hyper-V caused a bunch of other issues so I disabled it again. I also had 3D acceleration off while I tested this VM today.
I went ahead and changed the settings of my current VM to match that of comparable vagrant boxes, but the same issues crop up.

fth0 wrote:In the VM configuration of your previous VM, go to System > Acceleration. Set Paravirtualization Interface to Default or KVM, and enable Nested Paging. Does the problem persist?

I already tested my VMs with these settings and none of it helped, unfortunately.

What I'm gonna try next is just run a Xubuntu live CD without installing it for a while and see if it also crashes.
Edit: The crash does not happen when running a live CD. It only crashes when a HDD image is in use. I've also tried using it from a different HDD which is 100% okay. I don't understand this.

Edit 2: I now went to the extreme and completely reinstalled Windows. I checked my HDDs again using chkdsk doing a "deep" scan and no errors cropped up. The crashes still happen. Anyone have new ideas?

I apologize for bumping this thread. This issue is really frustrating and I want to see if there are more suggestions for things to try.

What I did do in addition to what I wrote in my previous post was disabling USB for the VM; that didn't do anything, either.

EDIT: I figured it out!! I'm running a beta version of Proxifier (it doesn't handle VirtualBox!) which causes my VM to crash. When I closed the Proxifier process, I was able to run a VM for an hour with no problem at all. Then I started Proxifier again and within minutes, my system crashed like before.

So, pro tip: Don't have Proxifier running while using VirtualBox until this is resolved. (I contacted Proxifier support so that they can look into it.)

Edit 2: I was able to identify the actual issue. I was connecting to a VPN via port 53 - and Proxifier reacted to these packets as if they were DNS packets... understandably so, considering the port. These packets were considered malformed and I guess at some point that causes a crash.
Switching to a different port resolved this issue.

Really glad you found the problem!

Your issue was very strange, and wasn't happening to many others (Vagrant-modified guests run but Virtualbox-only guests crash )

A local 3rd-party program was the cause. Glad you're up and running!