Virtualbox.exe "segfault"

[cepal]

bare-metal: HP Zbook G3 / 15" host OS: Win 7 / 64 / company-controlled updates Vbox: latest official = 5.1.10 r112026 + matching additions guest: Lubuntu (ubuntu + LXDE) 16.04 LTS / 64

description: randomly (within 2-3 hours from start) upon opening a new tab in Firefox in VM (or another new window/tab, ie e-mail in Thunderbird), the host's OS pops up following message and shuts the VM (but doesn't shut, if running the Virtualbox GUI app).

Windows Event message (same memory addresses each time): Application popup: VirtualBox.exe - Application Error : The instruction at 0xbefc53ad referenced memory at 0x000000d0. The memory could not be read.

[cepal]

VM's definition file (disk encryption keys masked)

[Frank Mehnert]

We would need a Windows application dump to investigate, see here. Also, any improvement if you disable 3D in the VM settings?

[cepal]

I've set my system for mini dumps, will upload next time the VM crashes...

[cepal]

I've also done a few changes to my VM config:

• CPU cores decreased from 4 to 3; (I have quad-core i7 && hyperthreading physically)
• decreased VM's RAM from 8GiB to 6GiB (host has 16GiB)

so far, the VM didn't crash...

[cepal]

(I mean so far "virtualbox.exe" didn't do the invalid memory operation)

[cepal]

I've had another crash just now (upon opening new firefox profile manager inside the VM). Same addresses - though the CPU cores and RAM has been limited as mentioned above. The OS didn't however generate any dump - although the dump works, I can see a dump from today morning for "nvxdsync.exe" crasghing when I was suspending the host into "sleep" mode when leaving from home to work...

[cepal]

The VirtualBox engine is also crashing now (maybe since the start, can't recall if I ever succeeded on this) on saving the running VM to disk. Same error with same codes / memory addresses. Still no crashdumps generated, the dumps I can see having been generated are "LogonUI.exe.[PID].dmp and nvxdsync.exe.[PID].dmp which are both unrelated, caused by not related circumstances, at a time when the VM wasn't running (or was running without problems, but there is no correlation as I've rebooted the whole host many times before/after these two crashes so in best, they would have affected the runtime between the reboots, at best.

[cepal]

I've just updated VirtualBox to version 5.1.12-112440 (official release), will see if that solved anything...

[cepal]

the Virtualbox.exe just crashed the same way on the new version...

[cepal]

This is becoming really annoying. I'm sure it's some "confusion" between the Lubuntu's LXDE / Qt and the virtualized graphics as it always crashes on graphical operaion ie. opening a new tab in Firefox, switching from window to window, etc. I have downloaded a "preinstalled" Lubuntu 16.04 (same as "mine") from osboxes.org and didn't add any software except the VBox additions and the required packages for their successful compilation, guake, linux-virtual, and tmux and "full-upugrade" keeping sw up to date. I've reset to the same RAM and videoRAM sizes (6G/96MB) and will see if it crashes - so far, but it had only 2G RAM, it didn't.

Now there is an interesting observation on both VMs, "mine" as well as "osboxes" - in "lspci -vvv" they are saying the video memory size is 128MiB, but I'd reserved only 96MiB (both same setting && same behaviour):

00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter (prog-if 00 [VGA controller])

Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M] Expansion ROM at <unassigned> [disabled] Kernel driver in use: vboxvideo Kernel modules: vboxvideo

I am no linux drivers expert, it's possible, that this isn't really size, just "addressable capability" or anything like that or else, but I thought this should better be reported, hopefully discussed, too.

Regarding dumps, The system is NOT creating Virtualbox.exe dumps. There are some other dumps not related to the VirtualBox though, so enabling the dumps the way described on the link provided definitely worked the way it should. If there is any other trick how I could gather dump for you, please let me know.

Also, may I ask for ANY update from Virtualbox/Oracle's side, please?

[cepal]

perhaps worth mentioning I'm using two external screens witht he laptop (three screens in total), engaging DELL USB3.0 dock with 2x displayport towards the external displays. And I've also tried to force as much as I can the system to use exclusively Nvidia and NOT the Intel graphics, perhaps I can try the opposite, however, I'm afraid that's not the root cause of this, as mentioned above.

[cepal]

I've disabled 3D, and it crashed too - when I put the host in sleep (laptop, taking home) - I am sure the VM used to survive host's suspend in the past (different Vbox version, different HW, etc.). The "control" osboxes.org VM crashed too, both upon wake up of the laptop (host) from suspend, at home (plugged in to identical DELL docking station in the same USB port).

[cepal]

just upgraded to VBox version 5.1.14 r112924 (Qt5.6.2), and it's still crashing ...

[Frank Mehnert]

As long as we don't get any dumps we cannot investigate, sorry.

[cepal]

I have finally got Virtualbox.exe dump file, how can I attach it? It's 245MB big and here's 0.5MB limit for attachment.

[cepal]

NOTE: I've compressed the dump of course, but it's still 30MB big using the ultra compression in 7zip.

[Frank Mehnert]

Can you upload it to a server and contact me via private e-mail (frank _dot_ mehnert _at_ oracle _dot_ com) to tell me the URL? When I downloaded the file you can remove it. Please don't forget to add the context (point to this ticket).

Could you also attach the VBox.log file for the crashing VM to this ticket?

[cepal]

I've emailed you with subject "Virtualbox ticket # 16292". Thanks a lot for your effort!

[cepal]

it's so disruptive now that I'm about to give up using Virtualbox, except for some rare tests. However, if you're working on a patch, because my VBox is already very unstable, I'm happy to install any VBox bleeding dev snapshot and test it against my system.

And one correction: it is not related to Mozilla products - the crash happens at opening new windows (ie opening a document in Libre office) or tabs (in Firefox). Also, I'm not sure if I mentioned, that after the popup of invalid memory operation on host, the guest still runs for a few more seconds - ie the new tab in Firefox keeps loading, the mouse keeps changing shape (arrow/cursor/pointy hand...) and after about 5 seconds, maybe a bit more, the guest freezes.

[Frank Mehnert]

We now found where the VM crashes but we still don't know why. At least it seems that you are executing the VM in fullscreen mode, is that correct? The crashing code is in the mini toolbar widget. Do you have any special screen configuration, e.g. multiple screens, (a) very big screen(s) etc?

The crash happens inside Qt and we never saw a similar crash here. It could be also a bug in Qt, hard to say.

[Frank Mehnert]

Actually, to be 100% sure that it's the mini toolbar widget, could you disable the mini toolbar in the VM settings? VM settings / User interface / Mini Toolbar: Show in fullscreen / Seamless => disable.

[Frank Mehnert]

And another request: Could you (with the mini toolbar ENABLED) do another experiment: Start the VM as usual (again, mini toolbar enabled) but start it like this:

set VBOX_RELEASE_LOG=+gui.e.l.l2
VirtualBox --startvm VM_NAME

where VM_NAME is the name of the VM of course. You probably need to add the correct path to the VirtualBox command.

Please try to reproduce the crash and attach the resulting VBox.log file to this ticket. Thank you!

[cepal]

Yes, that is correct, I am executing the VM in full screen mode; also, I tried to start it in headless and then "attach" it, even then it crashed. There is one "workaround" though. When I ran it headless and then RDPed to the VM (from local host) using the Virtualbox's VRDP. Of course, because I'm encrypting one disk, I had to start it from command line...

I am going to disable the minitoolbar and let you know results (for which reason I'll run the VM "as usual" instead of headless and then access via VRDP, of course).

[cepal]

sorry, just read your last update; going to set the LOG as requested.

[cepal]

(however the problem is, that from ALL the crashes, only once the system generated dump for Virtualbox.exe binary, so there's very little chance I'll be that lucky again any soon)

[cepal]

OK, I'm running it the way asked - with the release log set and mini toolbar active...

[cepal]

I think that crash wasn't like the rest of them - it was the only time when Virtualbox crash dump was generated; my vm crashed again without generating dump file. But I'm going to attach VBox.log and VBoxHardening.log (see attached as Logs-2017-01-27.7z ). THis time, just for the record, the VM was fullscreen on my main laptop monitor, not on an external one.

[cepal]

logs of crash when VM is started with the "VBOX_RELEASE_LOG=+gui.e.l.l2"

[cepal]

Just another two crashes with no dump files; But I just realized that until I click on "OK" for the popup about invalid memory operation, there are three VirtualBox processes - and from task manager, it's possible to enforce creating a dump file for each such process - well of course I realized that AFTER I clicked "OK" to terminate the Virtualbox. Another interesting observation - the "main" (biggest) Virtualbox process kept using about 2% of CPU (which is a lot as I have 8 threads i7). Suppose it may have been in some dead loop or whatnot. I'll definitely create the DUMP next time it crashes; of all 3 Virtualbox processes - you shall then be able to identify which of them was the culprit.

[cepal]

another crash logs after having started the VM with the given options; no DUMP file generated for VirtualBox.exe...

[cepal]

Another crash (one of many, but this time I recalled to create the dump before confirming the popup error message). I've created Virtualbox.exe (and VboxSVC.exe) dump files using the function in task manager whilst not having clicked "OK" on the popup alerting on invalid memory operation - so before the processes get killed. I've sent Frank e-mail on where he can download them. Hopefully that could help? The dump of the crippled Virtualbox didn't even finish, yet it reached 9GiB in size before the dumping process failed. It could only have been compressed to 836MiB (I was hoping for better than that with the highest levels of LZMA2/ultra /large dictionary/solid archive compression in 7zip).

[cepal]

I just had another crash; still had been starting the VM with the optional variable set as requested by Frank. This time, creating dump of the "main" Virtualbox.exe process (probably the one which attempted to read from invalid memory address) succeeded to create a dump file by the drop-down item in taskmgr. Just compressing the 6.9GiB dump (and other files - ie Virtualbox logs) and going to send Frank e-mail with the URL for the new dumps.

From now on, I'm booting the VM "normal" way (by opening a symlink to the VM, associated with Virtualbox). Will generate dumps once that crashes too.

[cepal]

not sure what changed but today my VM keeps crashing really every now and then - about every hour...

[cepal]

I'm now installing a new Intel Graphics driver - popped up by the HP Support Assistant... will see if that makes any difference though I don't expect that.

[cepal]

...still crashing (and still frequently).

[cepal]

ok, my VM now crashed after I'd started it in "headless mode" and then connected to it over VRDP (upon starting LibreOffice - so as usual, upon opening a new window). I mean, the Virtualbox crashed, not the VM itself, but it destroyed the running state of the VM indeed. Just to clarify the fault isn't within the VM's OS.

[cepal]

Hello Frank, have you been successful in identifying any possible culprits causing the crashes?

[cepal]

I've updated the Virtualbox to 5.1.16r113841 (Qt5.6.2) and still have the same problem.

I'm 99% confident that it's caused by the quite unstable DisplayLink software (managing external displays via USB3-connected docking station).

[cepal]

oh, interesting, there's already nearly instantly yet another update, 5.1.18.. going to install that one right now.

[cepal]

I didn't realize that this crashes stopped happening some months back, can't exactly tell when. It could have been with new DisplayLink driver or with an update of VirtualBox engine, or both, I've updated them two several times since my last update to this bug.

Please CLOSE as SOLVED.