Ubuntu on Windows 11 Home host - Guest keeps shutting down (or crashing?)

[coloradotechie]

Hi,

Any ideas on how to troubleshoot a guest VM randomly shutting down or crashing? I can't tell if it is a host issue or a guest issue.

Details:

I have Ubuntu 20.0.4.3 LTS running on a Windows 11 Home host. The host machine is a laptop and the Ubuntu guest is running a website. Sometimes the ubuntu guest will go 7-14 days without issue, however, other times it will go 4-8 hours and my website monitor will tell me there is a problem. (This happened yesterday: the website was up for 4 hours and then randomly it wasn't because the guest VM where the website is running was off).

When my website is down, I log into the Windows 11 host and I see that the Guest VM isn't running. There are no Windows errors on the screen and everything looks fine.

Thus, I start up the Ubuntu Guest VM again, the website starts, and I might be good for a few hours, or a few days until this randomly happens again.

Because the host is a laptop I've verified that the "When plugged in, put my device to sleep after" setting is set to "Never". (Also, when the issue happens I just need to shake the mouse and the computer screen wakes up, so it doesn't feel like a host-OS-going-to-sleep issue).

I've looked through the event viewer and nothing is jumping out.

Is there something in Virtual Box that will let me try to troubleshoot this issue? (And I'm not super great at linux, so I was trying to start my troubleshooting with VirtualBox).

Thank you~!

[scottgus1]

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

Right-click the VM in the main Virtualbox window's VM list, choose Show in Explorer/Finder/File Manager. In the "Logs" subfolder, zip the VM's "vbox.log", and post the zip file, using the forum's Attachments tab. (Configure your host OS to show all extensions so you can find the "vbox.log", not "vbox.log.1", etc.)

[coloradotechie]

Thank you.

I'm unable to reproduce the issue on-demand and when the issue does occur, the the guest VM is already shut-off and the VirtualBox window for the guest VM is already closed.

I did find the logs and zip them up and it turns out on some of the log files the last messages in them are errors. Scrolling up to look at the entries beginning 10 seconds before the errors I see:

Code: Select all

00:00:45.824129 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=1, Machine-state=6
00:00:46.625225 Audio: Warning: Scheduling hint of stream '[WasAPI] Output:0' is bigger (5ms) than used period size (0ms)
00:00:46.642936 Audio: Warning: Scheduling hint of stream '[WasAPI] Line-In:0' is bigger (10ms) than used period size (0ms)
02:40:41.812199 GUI: UICommon: Commit data request...
02:40:41.900066 GUI: UICommon: Handling aboutToQuit request..
02:40:42.867716 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Running, InUninit=1)
02:40:42.867736 Console: Machine state changed to 'Stopping'
02:40:42.868080 Changing the VM state from 'RUNNING' to 'POWERING_OFF'
02:40:42.868130 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={6ac83d89-6ee7-4e33-8ae6-b257b2e81be8} aComponent={ConsoleWrap} aText={The object is not ready}, preserve=false aResultDetail=0
02:40:42.868190 ****************** Guest state at power off for VCpu 1 ******************
02:40:42.868208 Guest CPUM (VCPU 1) state: 
02:40:42.868228 rax=ffffffffb4779db0 rbx=0000000000000001 rcx=0000000000000000 rdx=ffff8c51bcb31aa0
02:40:42.868229 rsi=0000000000000086 rdi=00000000006633e4 r8 =0000000000000000 r9 =0000000000000000
02:40:42.868230 r10=0000000000000002 r11=0000000000000001 r12=ffff8c510120b200 r13=ffff8c510120b200
02:40:42.868231 r14=0000000000000000 r15=0000000000000000

There are then a few hundred lines of messages and it ends with this:

Code: Select all

02:40:43.143536 E1000#0: TX frames up to 16384: 0
02:40:43.143543 E1000#0: TX frames up to 32768: 0
02:40:43.143549 E1000#0: Larger TX frames    : 0
02:40:43.143556 E1000#0: Max TX Delay        : 0
02:40:43.144836 GIM: KVM: Resetting MSRs
02:40:43.146740 vmmR3LogFlusher: Terminating (VERR_OBJECT_DESTROYED)
02:40:43.146899 Changing the VM state from 'DESTROYING' to 'TERMINATED'
02:40:43.146918 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={6ac83d89-6ee7-4e33-8ae6-b257b2e81be8} aComponent={ConsoleWrap} aText={The object is not ready}, preserve=false aResultDetail=0
02:40:43.147038 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={6ac83d89-6ee7-4e33-8ae6-b257b2e81be8} aComponent={ConsoleWrap} aText={The object is not ready}, preserve=false aResultDetail=0
02:40:43.238513 End of log file - Log started 2023-06-15T03:19:25.460934000Z

I've attached the log where this happened.

[scottgus1]

I'm not sure what the access denied errors mean. But this from your log:

02:40:42.867716 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Running, InUninit=1)

is quite similar to this from my VM:

00:02:20.299271 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Stopping, InUninit=0)

when I closed the VM window with the "power off" option, or when I sent the "vboxmanage controlvm poweroff" command.

I'm not sure if the difference in "mMachineState" or "InUninit" has any meaning, but it looks like something on the host told the VM to turn off.

[fth0]

FWIW, the first log message of the shutdown phase ("GUI: UICommon: Commit data request...") indicates a call from QGuiApplication::commitDataRequest() of the Qt library. I don't know the gory details, but a typical use case is when the user logs out from the host OS while applications are still running. Some applications (e.g. text editors) then give the user the opportunity to save their unsaved data. In general this call indicates the termination of a host OS session, whatever that means for your specific case here.

[scottgus1]

a typical use case is when the user logs out from the host OS while applications are still running.

Ooo, that's a definite VM murder suspect. Interesting detective work, fth0!

Coloradotechie, did your host log out? Virtualbox VMs run in the logged-on user session, and logging out kills the VMs.