virtualbox.org

Version 5.0.14 VirtualBox on Windows 7.
Guest is Debian 8.2.

At random times (minutes or days after starting VirtualBox), I see this pop-up
[VirtualBox.exe - Application Error]

The instruction at 0x800c21dc referenced memory at 0x000007b0. The
memory could not be read.

The failing instruction does not appear to be the same, the bad memory address is definitely not the same.

Strangely, the Guest keeps running as I ignore the [OK] button in the dialog ... 8^) ... without any apparent problem, but when you shut down the Guest, VB crashes and the VM is marked as Aborted.

I've been using VB across lots of versions for years with the same Guest image ... this behaviour is new as of VB 5.0.14.

Possibly you have had an unsigned interloper DLL ejected from the VirtualBox address space, and something else which was not ejected is trying to reference it. Look for any potentially dodgy permanently running software you might have installed. Start with your antivirus, things that look for threats in internet browsers etc.

No unusual running processes that I can see.

Virus checker's full scan of the disk reveals nothing unusual.

If an unsigned DLL was "ejected" by VB would there be a log of that someplace, so I can check the DLL(s) in question?

mpack wrote:Start with your antivirus...

kenj_bozo wrote:Virus checker's full scan

Do you see the conflict in the two statements?

kenj_bozo wrote:Virus checker's full scan of the disk reveals nothing unusual.

I wasn't thinking of actual malware, so not something which an AV scan would pick up.

I was thinking of any resident service you might have installed that wasn't from Microsoft. Not because they can't be trusted, but because their DLLs aren't always signed.

p.s. to Socrates: there isn't necessarily a conflict in the statements you highlighted. Some AV scanners work offline, so those wouldn't be a problem for VirtualBox - and perhaps the OP meant that. Or perhaps he simply looked at a last report.

To kenj: if you do still have resident AV then it's quite important to test the effect of disabling it, as poor quality (free) AV is a common source of these problems.

mpack wrote:p.s. to Socrates: there isn't necessarily a conflict in the statements you highlighted.

Yes, reading it again, "Start with your AV" could actually mean "do a full scan", but it was preceded by "Look for any potentially dodgy permanently running software you might have installed. Start with your antivirus"

mpack wrote:if you do still have resident AV then it's quite important to test the effect of disabling it

Actually, I've seen reports that even disabling the AV does no good. People had to outright uninstall it to get VirtualBox working again.

Use Process Monitor from Sysinternals to find out which of the three VirtualBox processes crashes. To do that, set 3 filters in Process Monitor, "Operation" "is" "Process Start" "Include", "Operation" "is" "Process Create" "Include", "Operation" "is" "Process Exit" "Include". The crashing process is not the hardened process, so you could try to enable automatic user memory dump, read here about Enabling Mini Dumps using Windows Error Reporting (WER). Set DumpType to 1. If it doesn't work, use Process Explorer to save the minidump (don't close the error dialog, identify the id of the crashed process first). Upload a minidump to Google Drive and share the link, so we can take a look at it.