VirtualBox 4.3.20: Application Error dialog on VM shutdown

[Daniel.Glasser]

I recently upgraded my VirtualBox installation to 4.3.20 r96997 on a Windows 7 Enterprise. For full configuration details, please see the saved virtual box logs in attached .zip file. On the same day, I installed updates within the Ubuntu guest VM.

Now, whenever I shut down my guest VM from within the guest OS, I get a dialog similar to the following:

An example of the Application Error dialog box

vbox-memexception.png (22.63 KiB) Viewed 3791 times

Sometimes the referenced address is 0xffffffff, and I've seen other instruction addresses ("0x0a2c6f9f", most recently).

I've attached a .zip file with three log files, one that came from a normal shut down without error using VirtualBox 4.3.12 ("Ubuntu", dated 2014-11-26), another from a shut down done today with VirtualBox 4.3.20 ("Ubuntu", dated 2014-12-04), and a third one from a different guest VM ("Freescale", dated 2014-12-04 -- more about that later). Note that the Ubuntu 2014-12-04 log ends with "Console::powerDown(): A Request to power off the VM has been issued (mMachineState=Stopping, InUninit=0)", whereas the the 2014-11-26 log has a lot of additional information following that line. Also note that the VM can reboot without exhibiting an error. This problem appears to be only present when the guest VM has requested a power-down. The result is that my VM, after having been shut down, always says "Aborted".

Interestingly enough, another VM I have (also the same version of Ubuntu) that has the host additions for VirtualBox 4.3.12 still in place, does still shut down cleanly (see "Freescale" log file). It is possible that this is a problem with the guest extensions for 4.3.20, or this may be unrelated. As far as Linux is concerned, the kernel has halted, I believe.

Is there any way to clear this behavior? I'd like my VMs to show up as "Powered Off", not "Aborted".

Thanks,

Daniel Glasser

[mpack]

I assume you mean "Guest Additions". Yes, if this was a GAs bug then it wouldn't be the first. I generally don't update working GAs unless the update has a specific feature or bugfix I want. Unlike the extension pack there is no requirement that the GAs version must align with the VBox version.

You should probably raise a BugTracker ticket for this, if you can pin it down so the devs can reproduce it.

[Daniel.Glasser]

A quick update

After posting the first message, I discovered that when I start the guest VM, then shut it down from the system menu on the login screen without logging in to a user account, the VM exits cleanly. If I start the VM, log in to a user account, then shut down from the systems menu within my logged in session, the error occurs.

Attached is a .zip file with a pair of log files, the earlier one is the "didn't log in", the later one is "logged in".

Thanks,
Daniel Glasser

[Perryg]

Does the guest still have shutdown issues if you disable the 3D acceleration in the guests settings?

[Daniel.Glasser]

Does the guest still have shutdown issues if you disable the 3D acceleration in the guests settings?

With a sample of 2 cycles, the answer is "no". It seems that disabling 3D acceleration in the guest VM's settings does prevent the Application Error on exit. That would not have occurred to me to try. I'll have to add that to the BugTracker ticket I submitted for this issue...

I suppose that points at the video driver as being a source of trouble. I can see from comparing logs that there were a number of changes in what got logged between 4.3.12 and 4.3.20 that seem display related.

Thanks for the suggestion.

Daniel

[mjStallinger]

Hi there!

I almost have the same troubles shutting down my fedora client with 'guest additions' installed and 3D-Acceleration enabled.
My graphics hardware is a 'Saphire/ATI Radeon HD 4800 OC' (dual monitor) on a Windows 7 pro machine.

To work around that issue, I found out, that switching to another machine within virtualbox, while the affected one (fedora) boots up - and further - not leaving the screen with the mouse cursor during shutdown, until the machine is finally off, prevents that problem.

Regards
Michal

[mhanor]

This is a known issue