virtualbox.org

I've been trying to get help with the XP guest aborting on my PCLinuxOS system. In var/log/messages I find errors with virtualbox pertaining to random segment faults in VBoxREM64.so. Some listed below.

Apr 2 08:39:32 ws135lnx klogd: EMT[26620]: segfault at 0 ip b0b9752a sp b137de30 error 6 in VBoxREM64.so[b0b86000+c2000]
Apr 2 16:21:25 ws135lnx klogd: EMT[19906]: segfault at 0 ip b0b7652a sp b137de30 error 6 in VBoxREM64.so[b0b65000+c2000]
Apr 2 16:41:15 ws135lnx klogd: EMT[21280]: segfault at 42 ip b0c97524 sp b147de30 error 6 in VBoxREM64.so[b0c86000+c2000]

Sometimes it runs 24 hours, sometimes only a minute. Most of the time the XP is idle, no activity. Sometimes I'm in the middle of doing something. The version of Virtualbox has not mattered. There have been 3 upgrades since this first started happening and it has done it with each and every version since. DPMS is intsalled and up to date. I'm dowloading the software from this site in the .run format, installing it as SU. The guest add-ons are also kept up to date.

What comes to my attention is the file VBoxREM64.so. Why that file?

I have upgraded PCLinuxOS to 64 bit, and necessarily upgraded VirtualBox. I still had aborts without errors in the virtual machine log, and only segfaults in the system logs.

What I have found so far is an issue with cpu usage in the virtual machine. It is capped at 100%, and if any processes in the virtual machine tried to push cpu use past 100%, that is when the abort gets triggered. Part of the problem is Zone Alarm firewall with antivirus, one specific process, VSMON.EXE. After disconnecting the network, I removed Zone Alarm. Then cpu usage dropped considerably. Zone Alarm was not the only process that was pushing cpu use, which is what brought me to this conclusion, but it was one I could easily isolate.

I was planning to make a backup of critical files. After running all day while trying to get Windows Backup to do a successful backup, there were no aborts. I reinstalled Zone Alarm firewall only, and so far it has not been pushing the cpu usage like it had before. The virtual machine ran overnight and is still running.

At this point I am going to say that the issue is resolved, but not completely. It is one of those issues that can be avoided, and may not require any specific modification to VirtualBox. It is just a Windows XP thing that VirtualBox clashed with.