One thing I'm noticing is that I'm not seeing the panic if I only have one virtual machine running and I shut it down, start it up, shut it down, and so on. It only seems to occur if I have two or more VMs running and I shut one down.

I am having the same issue with 4.1.4, running on an Xserve with 12 GB of RAM, 10.6.8. I have two VMs, one Linux and the other Windows Server 2003. The kernel panic occurs when I shut one of the VMs down while the other is running. The problem does not occur when I restart a VM.

Seems pretty clear the problem started after 4.0.14 and persists for some of us.
VBox 4.1.x through the current one
More than one VM open
Panic when one closes
Not reproducible or consistent from what's in the blog post reports.

Still no clue. It could be also related to 3D acceleration so it would be interesting if this host panics occur with disabled 3D (in VM settings) as well. And we are also interested in getting more crash logs, if possible for VirtualBox 4.1.10.

Found wide-spread complaints of Lion kernel panics (not VirtualBox-related) that seem to indicate that wifi (Airport) was the culprit.
So I disabled my Airport connection on the MB Air I'm running and low and behold, I'm able to run without any crashes. Ten restarts of Win7 64-bit w/ Airport disabled, no errors. Enable Airport, and I get crashes two on ten reboots.

I use both. My dev machine uses NAT, while my test systems are bridged. The common failure case for me I have a dev and test system running, and I wrap up using a test system and power it down.

As indicated by others (and I've uploaded at least one panic dump for this case also) it is possible to hit this when shutting down the only running VM also.

@cgallery: The bit about wifi is interesting in my case, also. The one panic I've encountered since the 4.1.10 update occurred while I was on the road using wifi; at home, I hadn't hit a panic since the update. I'll keep an eye on this. However, prior to the 4.1.10 update I'm fairly sure I hit this problem with wifi disabled, since my default home setup is to run wired and turn wifi off.

It might be a little late for me to be able to test this meaningfully. I just posted my current state on the forum:

I've been running trouble-free with a mix of Ubuntu 11.10 and Windows 8 guests after my Lion upgrade. I believe I went from 10.6.8 to 10.7.3.

I see the final state of my VM as "Aborted" often after system shutdown completed, and I'm pretty sure there's a localhost crash dump associated with each of these. AFAICT these don't affect the system at all, though - they've never occurred while my system is still running.

So, for me this particular issue seemed to be specific to 10.6.x. I never ran 10.7 before 10.7.3, so I can't comment on whether the panic-on-shutdown problem is an issue there.

Today I've done more than 100 stop/starts of VM's, and I've found an easy way to reproduce the problem.
This problem is definitely network related. Basically, you have to generate traffic thru a vm, and reboot another vm.
In my case, I use the Iron browser to download something from the internet, with a proxy (privoxy) on one of the VM's.
I then reboot two other VM's. I can now reproduce the problem in less than about 5 reboots.

So this is the setup (see also vm-crash-note.txt in the attachment. The web frontend breaks my ascii art...)

I'm seeing the same crashing behaviour, only when stopping a VM. I'm on OSX 10.7.4 and running the new VBox 4.1.16, I've seen those crashes with previous versions of the 4.1.x series (not sure exactly from which it started). The guests I run are Debian 6 or CentOS 5 and 6. I'm not using the wifi connection from my mac-mini.

Here I upload the last crash I've seen when shutting down 3 VM at about the same time and having a 4th VM still running.

I might ask what specific Mac hardware individuals are using who are seeing this issue? Ticket #3783 had NIC-specific networking changes which only applied to Mac Pro and Xserve hardware (at least I think those are the only models that had the specific controller). Just thought I'd bring it up as networking issues may be a possible link--not necessarily a regression here but perhaps just something hardware related.

For my part I've seen what seems to be this issue using an Xserve2,1 running Mac OS X Server 10.6.8 when starting and stopping a Win 2008 Server VM multiple times.

This is killing me on a Retina Macbook Pro. I experience this crash multiple times a day.

I agree with the problem being network related when more than one VM is involved. My setup includes multiple VMs where one acts as a router for all other systems. It runs DNSmasq and has IPtables configured to route traffic from the internal interface eth1 and out to the internet via eth0. In addition to the router VM I also have two additional "permanent" VMs: one that is running a Puppet server and another that is running APT-cacher.

I am using the PCnet-PCI II adapter because the default Intel PRO / 1000 MT Desktop adapter would choke when using this router setup. Basically there would be large timeout periods per request for data over the network, e.g. each .deb would take forever when running apt-get upgrade through the router VM.

When a new VM is brought up, its /etc/apt/sources.list file is updated to point to the apt-cacher server instead of directly out to APT servers on the internet.

I can't confirm exactly when the problem happens, but it feels it happens most when the router VM is shut down than anything else.

Under Mac OS 10.8, the script can cleanly install and start VM, even with other running VM.
But if there are running VM, uninstalling procedure crashes my Mac
(I can not provide log, since crash looses logs...)

Hey, there is a light at the end of the tunnel. We actually found and fixed a bug which is most likely responsible for all these host panics. It affects only 32-bit hosts and Mac OS X hosts. We are doing some more tests. You can expect a 4.1.22 bugfix release soon.

That's great news, Frank. Just out of professional curiosity, what was the root cause for the bug you fixed? I noticed in another bug report that the problem on 32-bit hosts might have been correlated with nested paging being enabled.

Also, has the bugfix been ported forward to the 4.2 branch, or will it be soon?

Also, I think bug 9359 is a duplicate and has a lot of folks following it; I'm going to copy/paste your comment there.

The root cause was kernel memory corruption when shutting down a VM while at least one other VM was running. This only affected 32-bit hosts plus 64-bit OS X (but not 64-bit Windows/Linux/Solaris). Since the memory corruption was unpredictable, it might do nothing bad at all or it might crash the host. Especially on systems with relatively large amount of free memory, this bug tended to remain hidden. On the other hand, it could also crash the system after the last VM had been shut down.

This had absolutely nothing to do with nested paging BTW. If someone thought nested paging, networking, 3D or anything like that had any effect on this bug, they simply drew incorrect conclusions from essentially random data (which is very tempting).

aside -- Any chance whatever this bug did to memory could be blamed for random crashes of other applications at later times? A Mac store 'genius' guy some months ago couldn't explain the high number of panics I get, but said since I'd been running VBox, it might have made other apps unpredictably unstable. Other software developers, looking at crash logs, see random stuff, 'all over the place', that they can't explain, involved in crashes. (Yes, Apple took the Mini and did the hardware stress test. All ok).

Depends on what you mean by "random crashes of other application". Kernel panics, yes. Application crashes ("app quit unexpectedly"), probably not. But the actual application which was active during the kernel panic was often not VirtualBox. Which made all the panic logs that people submitted kind of useless, unfortunately - there kernel panics were not pointing in any particular direction, just random crashes (seemingly always page faults).

Also note that only closing of VMs while other VMs were running triggered this, not running a VM (or VMs).