virtualbox.org

Kernel panic report attached.
For information only, worked around the resulting inaccessible VM by reverting to the older one.

Kernel panic while working on a Windows guest VM, under OSX 10.7.4, VBox 4.1.16
After rebooting the host, the VM was inaccessible with this message:

Start tag expected, '<' not found.
Location: '/Volumes/~/W7Pro_X86_2007.vbox', line 1 (0), column 1.
/Users/vbox/tinderbox/4.1-mac-rel/src/VBox/Main/src-server/MachineImpl.cpp[707] (nsresult Machine::registeredInit()).
Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
VirtualBox
Interface:
IVirtualBox {~}

(Workaround (I hope) -- I renamed the current .vbox file .vbox-broken, and renamed the last previous older .vbox file.)

And, that workaround only lasted for one session, now the VM is inaccessible, showing:
"Could not find an open hard disk with UUID {...}.
Result Code:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component:
VirtualBox
Interface:
IVirtualBox {c28be65f-1a8f-43b4-81f1-eb60cb516e66}


So -- looking back at the original broken file, the beginning of it looks like this:

=00000000'00000000'00000000'00000000 XMM9 =00000000'00000000'00000000'00000000
00:54:46.108 XMM10=00000000'00000000'00000000'00000000 XMM11=00000000'00000000'00000000'00000000
00:54:46.108 XMM12=00000000'00000000'00000000'00000000 XMM13=00000000'00000000'00000000'00000000
00:54:46.108 XMM14=00000000'00000000'00000000'00000000 XMM15=00000000'00000000'00000000'00000000
00:54:46.108 EFER =0000000000000800
00:54:46.108 PAT =0007010600070106
00:54:46.108 STAR =0000000000000000
00:54:46.108 CSTAR =0000000000000000
00:54:46.108 LSTAR =0000000000000000
00:54:46.108 SFMASK =0000000000000000
00:54:46.108 KERNELGSBASE =0000000000000000
00:54:46.108 ***
00:54:46.108 Guest paging mode: PAE+NX, changed 32938 times, A20 enabled
00:54:46.108 Shadow paging mode: EPT
00:54:46.108 Host paging mode: AMD64+G+NX
00:54:46.108 *** ...


By contrast, a good file starts like this:

<?xml version="1.0"?>
<!--
** DO NOT EDIT THIS FILE.
** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.
-->


So -- I'm convinced the kernel panic broke the VM. Not sure if there's a way to recover anything useful.
No worry, I have backups -- just reporting this in case it's an unexpectedly bad result from a kernel crash.

hank wrote:So -- looking back at the original broken file, the beginning of it looks like this:

=00000000'00000000'00000000'00000000 XMM9 =00000000'00000000'00000000'00000000
00:54:46.108 XMM10=00000000'00000000'00000000'00000000 XMM11=00000000'00000000'00000000'00000000
00:54:46.108 XMM12=00000000'00000000'00000000'00000000 XMM13=00000000'00000000'00000000'00000000

That indicates corruption of the host hard drive. Basically the file's directory indicates where on the disk the file starts, but when we go there we're finding data from a completely different file: the data shown did not come from VirtualBox. Most easily done if a system crash occurs while this file was being written.

If I was you I would run some disk check tools, though I couldn't tell you what that would be, on a Mac host.

For what it's worth, I ran into the same problem today, but I'm using 10.6.8. The kernel panic happened after a machine shutdown. At the next restart, analyzing the vbox file, content was overwritten with log information (!), hence the '<' error. Unfortunately I have not been able to use the vbox.prev file as it complains "... still in use", even though I cleaned out all relevant disks in the virtual media manager - some problem with the Snapshot files it seems.

(update: I fixed it by manually removing a snapshot uuid in the vbox backup file that did not exist or disappeared due to the crash.)

I had a couple more crashes today, all happening after a shutdown of a VM. I usually have about 3 or 4 open. Windows and Oracle Linux. The last crash happened with a 3 min. delay after shutting down a Windows 7 machine, just sitting there and grey screen.

I wonder if Oracle is aware of the problem and trying to fix this. These crashes are nasty and seem to be an ongoing issue.

waldorfm wrote:I wonder if Oracle is aware of the problem and trying to fix this. These crashes are nasty and seem to be an ongoing issue.

At the moment, Oracle a) isn't able to reproduce the crashes, and b) in the absence of a reproduction scenario, doesn't have enough information from users that would point to a cause.

Usually the "bug reports" come in a form of "yeah, it crashes for me too", which is fairly worthless. If someone has a 100% reproduction scenario, please tell us what it is. If someone has crash logs or core dumps or other diagnostic information clearly pointing at a bug in VirtualBox, please attach the relevant files to a ticket on the public bug tracker.

So yes, Oracle is aware of a problem, but doesn't know what causes it, let alone how to fix it. There isn't even any conclusive evidence that "feature X causes it".

And to the OP - yes, getting the corrupted .vbox file out of the way and renaming .vbox-prev to .vbox was the right thing to do. That situation can occur if the system is not shut down cleanly for any reason (crash, power outage, anything).

If anyone can specify any log file that might be useful beyond those I already attached, I'll do that.
If there's any switch to enable more logging, I'd appreciate it if you'd spell it out; I do read the manual but can't keep it all in mind and I only vaguely recall there may be something I could do that would be useful.

PS -- I try not to ever have two VMs open at once; it's possible I started a second one while the first wasn't finished shutting down to get that crash.

I know someone else has posted that he can reproduce the kernel panics by having multiple VMs open and closing one of them.
I haven't heard about this overwriting by chunks of log file til this thread.