VBoxSVC.EXE failure, crashing 3 long time active VMs

[PHolder]

I have a Windows 10 1909 Intel i7 4970 machine that I leave running with multiple VirtualBox guests active. (Usually around 3, and it was three in this case.) All three guests are also Windows 10 guests. It's the latest version of VB (6.1.12) with the latest guest additions. It's been running fine (and continuously) since I upgraded the VB to the current version, probably 2 or 3 weeks ago.

This morning I woke to find all three machines reporting:

A critical error has occurred while running the virtual machine and the machine execution should be stopped.
For help, please see the Community section on https://www.virtualbox.org or your support contract. Please provide the contents of the log file VBox.log, which you can find in the virtual machine log directory, as well as a description of what you were doing when this error happened. Note that you can also access the above file by selecting Show Log from the Machine menu of the main VirtualBox window.
Press OK to power off the machine.

And when I pressed the button to power off each machine, I got a chain of pop-ups of the sort (I have elided the actual VM name(s)):

Failed to open a session for the virtual machine {VM Name}.
Callee RC: E_FAIL (0x80004005)

I then went poking around in the Reliability Monitor and found:

VBoxSVC.exe
Faulting application name: VBoxSVC.exe, version: 6.1.12.39181, time stamp: 0x5f08d7c9
Faulting module name: ntdll.dll, version: 10.0.18362.815, time stamp: 0xb29ecf52
Exception code: 0xc0000374
Fault offset: 0x00000000000f9229
Faulting process id: 0x26c4
Faulting application start time: 0x01d65c64e48d2d8a
Faulting application path: C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: ba10d01c-ec0d-4ef5-807a-2b667143d887
Faulting package full name:
Faulting package-relative application ID:

[PHolder]

Sorry, typo, it's an i7 4790K.

[scottgus1]

Please provide the contents of the log file VBox.log

I think we might need this.

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

[PHolder]

Here's the log from the one of the three VMs I have yet to restart since the failure.

[scottgus1]

Thanks for the log.

One thing that I think should have been in the first post but wasn't:

00:00:02.216398 File system of '\\synologynas02\VirtualMachines\Windows10ForFunn.vdi' is ntfs

The guest VDI is on a NAS, not the normal kind of operation. If all the guests' disks are on the NAS, and the network goes down, the guests would see a loss of disk, and crash.

I haven't had a guest lose its disk but once, and that was because another guest was heavy-using the disk, so the first guest just BSODed and Virtualbox stayed up. But if Virtualbox itself lost connection to the VDI, then a Virtualbox crash could happen.

Has this happened more than once? If not it could have just been a glitch.

Did the NAS try a backup? Andrew@USOP over here: viewtopic.php?f=6&t=99326 suffered from his job's NAS running backups on the running guests which caused trouble.

[PHolder]

The guest VDI is on a NAS, not the normal kind of operation. If all the guests' disks are on the NAS, and the network goes down, the guests would see a loss of disk, and crash.

Ummm.. support for handling VDI disconnect is supposedly built into VB. I have had it happen before when there was a power glitch (unfortunately there is a switch in the middle between the VB Host and the NAS that is not on UPS yet.) When it happens, VB complains that the vdi is gone, and pauses the guest. It will supposedly even allow you to retry the operation after unpausing the guest. In my experience, this never actually works out right long term, so I think the support is not production quality, but it is a completely different symptom than what happened this time. According to my research that exception is a stack corruption in the VBoxSVC.EXE.

[scottgus1]

Ummm.. support for handling VDI disconnect is supposedly built into VB.

Ummm.. I'll have to acquiesce to your experience on this one, as I haven't run a guest with a drive on a shared folder before. I never figured the possible network glitches or bandwidth limitations to justify the apparent benefits. I could see that using a NAS for the guest disks as a possible storage preservation step, but there are problems that could develop, as Andrew found out, and better backup routines are available. And, as you say that the recovery from a network-glitch-disk-loss is not 100% reliable, I wouldn't trust it myself.

Computers are what they are. Everybody BSODs once in a while, even NASA's space probes. So a corruption in VboxSVC.exe could happen, especially on what appears to be a consumer-not-server-class PC. If it was a one-off we might never be able to track down the cause.

If it happens again, uninstall Virtualbox & reinstall, using right-click-run-as-administrator.