Ubuntu 19.04 crashes on Virtualbox 6.0.12

[NewDimension]

My Ubuntu 19.04 guest keeps crashing on my Windows 10 host. The error is about not finding something in memory. I'll add a screenshot when it happens again.

Hardware Profile:
Thinkpad P50
CPU Intel i7-6700HQ
OS: Windows 10 Pro, came preinstalled
Memory: 16gb
Video: NVIDIA Quadro

Setup via Vbox GUI. It was mentioned that there is a text file method.

[NewDimension]

Well that didn't take long. See attached screenshot of error, and relevant log.

error.PNG (7.56 KiB) Viewed 7165 times

[socratis]

There's no clear indication of what crashed that I can see, maybe I'm not reading the tea leaves correctly. What were you doing in the guest when VirtualBox crashed? What 3rd party invasive software do you have installed? By invasive I mean software that besides doing its own thing, it has the tendency to get involved in other processes' business...

[fth0]

There is an unhandled exception in the VMSVGA FIFO thread inside VBoxDD.dll in both log files. This probably can only be evaluated by a VirtualBox developer, and I guess the developer will then ask for reproducibility ...

[NewDimension]

What were you doing in the guest when VirtualBox crashed? What 3rd party invasive software do you have installed? By invasive I mean software that besides doing its own thing, it has the tendency to get involved in other processes' business...

I don't have much installed on the VM: Pycharm and Chrome.
Prior to the crashes referenced in this thread I was debugging a JS file in Chrome. Chrome start-up feels correlated to the crashes, as they weren't as frequent before.

I remember finding Error code 0xC0000005 in my hardening logs. But I can't seem to find it anymore. Does the hardening log get overridden on restart?

[scottgus1]

There is an unhandled exception in the VMSVGA FIFO thread inside VBoxDD.dll in both log files.

fth0, where do you see this, please?

[NewDimension]

Attached are logs (log and hardening) of a third crash. I'm going to refrain from uploading more unless someone asks for them.

[socratis]

There is an unhandled exception in the VMSVGA FIFO thread inside VBoxDD.dll in both log files.

fth0, where do you see this, please?

I hope 'fth0' won't mind if I give my (attempt to an) explanation...

From the log, the first sign of things not going right is at the 100:36:32.993973 mark:

100:36:32.993973 
100:36:32.993974 !!! rtR3WinUnhandledXcptFilter caught an exception on thread 0000000000002f20!!!
100:36:32.993986 
100:36:32.993986 ExceptionCode=0xc0000005 ExceptionFlags=0x00000000 ExceptionAddress=00007ffb1f78c619
100:36:32.993991 ExceptionInformation[0]=0000000000000000
100:36:32.993994 ExceptionInformation[1]=0000000000000000

Searching now for "0000000000002f20" (the thread where the exception happened), the very next instance is in:

100:36:32.996078 Thread ID:   0000000000002f20
100:36:32.996086 Thread name: VMSVGA FIFO
100:36:32.996090 Thread IPRT: 0000000005008e70

Edit: Found the connection between the crash and "VBoxDD.dll", thanks 'fth0'.

Now, how 'fth0' got from the "VMSVGA" to the "VBoxDD.dll", is not that obvious at least to someone like myself. Unless he went with this: Looking at the "ExceptionAddress" address in that error, you can find it again in the following stack address, which points to "VBoxDD.dll":

100:36:32.996898 Potential code addresses on the stack:
100:36:32.996901 Xcpt PC         : 00007ffb1f78c619 - 0x0008c619 bytes into
                 C:\Program Files\Oracle\VirtualBox\VBoxDD.DLL

[socratis]

I'm going to refrain from uploading more unless someone asks for them.

Actually I'm seriously considering deleting that 3rd log... Nothing of added value will be lost, it's one more of the same...

[NewDimension]

Does this mean I need to file a bug report? Or are we keeping this in the forums for now.

[socratis]

For now try the 6.0.13 testbuilds, or wait until 6.0.14 comes out on 2019-10-15. Both contain a lot of fixes to the VBoxSVGA code.

[fth0]

I hope 'fth0' won't mind if I give my (attempt to an) explanation...

Not at all, and you got it perfectly right.

There's one additional (and redundant) link in the lines you quoted: Look at ExceptionAddress and Xcpt PC.

And the ExceptionCode value 0xc0000005 aka STATUS_ACCESS_VIOLATION shows one of the most common Windows driver errors (usually seen in a BSOD).

[socratis]

Look at ExceptionAddress and Xcpt PC.

D'oh!
It was looking at me straight in the eye the whole time!

100:36:32.993973 
100:36:32.993974 !!! rtR3WinUnhandledXcptFilter caught an exception on thread 0000000000002f20!!!
100:36:32.993986 
100:36:32.993986 ExceptionCode=0xc0000005 ExceptionFlags=0x00000000 ExceptionAddress=00007ffb1f78c619
100:36:32.993991 ExceptionInformation[0]=0000000000000000
100:36:32.993994 ExceptionInformation[1]=0000000000000000

100:36:32.996898 Potential code addresses on the stack:
100:36:32.996901 Xcpt PC         : 00007ffb1f78c619 - 0x0008c619 bytes into
                 C:\Program Files\Oracle\VirtualBox\VBoxDD.DLL

The '0xc0000005' BSOD is giving the ExceptionAddress ('0x00007ffb1f78c619') where the VBoxDD.DLL is loaded! Editing previous post to make the connection...

Thanks 'fth0' for the added explanation!

Code: Select all

SocratisHuntingSkillsMode +=1

[NewDimension]

The issue persists on Virtualbox 6.0.14. It's somehow correlated with Google Chrome. When I run Google Chrome as part of Pycharm's debugger VB crashes shortly after.

[Roli]

I can reproduce this: whenever I close Google Chrome Virtualbox crashes.

I'm using Virtualbox 6.0.14.

To me also "feels" like Chrome is very slow and I mean not the searching but the performance of the application. Firefox is so much faster that I don't think it's because of Virtualbox settings. (Sorry, I'm not very tech savvy, hth)