Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#3724 closed defect (wontfix)

Host crash: vboxdrv crashes, when run in VMX mode, together with coLinux

Reported by: Technologov Owned by:
Component: other Version: VirtualBox 2.2.0
Keywords: Cc:
Guest type: other Host type: other



Host: Windows XP, SP2, 32-bit, Intel Core 2 Quad, VirtualBox 2.2.0

Guest: Ubuntu 8.04, 32-bit

I decided to try Ubuntu 8.04 - in both "coLinux" mode and "virtualized" mode side-by-side.

For "coLinux" mode I used "Portable Ubuntu for Windows" distro. (

For "virtualized" mode I used VirtualBox 2.2.0. with VT-x enabled.

Running those two solutions together at the same time results in Host Crash with BSOD, if VMX is used by VirtualBox. If running software virtualization, no crash occur.

I cannot blame VirtualBox for it, as I don't know who is responsible for crash, but it would be helpful if VirtualBox checked whenever it is safe to enter VMX mode.

Due to crash, no logs were generated.

-Technologov, 14.4.2009.

Attachments (1)

colinux-0.7.4-log.txt (12.5 KB ) - added by Technologov 15 years ago.
coLinux 0.7.4 rc2 -- /var/log/messages -- before crash

Download all attachments as: .zip

Change History (14)

comment:1 by Sander van Leeuwen, 15 years ago

We do check if it's safe to enable VT-x. I don't know what this coLinux does though.

comment:2 by Technologov, 15 years ago

Could we check what else could be of conflict ? which resources ? (assuming coLinux doesn't enters VMX mode)

comment:3 by Frank Mehnert, 15 years ago

priority: blockermajor

comment:4 by Technologov, 15 years ago

Host crash deserves higher priority in my opinion.

Added /var/log/messages from coLinux -0.7.4-rc2 before crash.


by Technologov, 15 years ago

Attachment: colinux-0.7.4-log.txt added

coLinux 0.7.4 rc2 -- /var/log/messages -- before crash

comment:5 by Technologov, 15 years ago

To summarize:

The Good news:

I have added /var/log/messages from coLinux -0.7.4-rc2 before crash.

The Bad news:

Crash is so hard that no core dumps get generated. Mini dumps generation is set, but there are no mini-dumps from year 2009 exists in "\WINDOWS\Minidump".

..and The ugly:

I have no idea what to do next.


comment:6 by Technologov, 15 years ago

We have opened a new bug report at coLinux bugzilla: coLinux bug report


comment:7 by Sander van Leeuwen, 15 years ago

Resolution: wontfix
Status: newclosed

Same happens with MS VirtualPC apparently. See

So it looks like it's their bug or the coLinux driver does things that are not allowed in VMX root mode. Either way not much we can do about it.

comment:8 by Sander van Leeuwen, 15 years ago

coLinux can easily see if VMX root is active on the CPU by checking X86_CR4_VMXE (bit 13 in CR4).

in reply to:  8 comment:9 by Henry N., 15 years ago

Replying to sandervl73:

coLinux can easily see if VMX root is active on the CPU by checking X86_CR4_VMXE (bit 13 in CR4).

Thanks sandervl73 for pointing to this bit. Checking X86_CR4_VMXE would help to avoid crashing the host. But this does not help to running coLinux. While switching from Windows host to Linux Guest coLinux needs to clear CR4 and disable paging. Both would GP-fault the host, if VMX is running.

Can we disable VMX for short time while the coLinux machine is running, and can we restore the VMX running state later?

comment:10 by Technologov, 15 years ago

sandervl73: HenryN is a core developer of coLinux.

HenryN: sandervl73 is a core developer of VirtualBox.

I really hope two Open-Source drivers needs to "co"-exists together, and find status-quo. All-in-all that's where "co" in coLinux comes from in the first place, isn't it?


comment:11 by Sander van Leeuwen, 15 years ago

You can disable VMX root mode if you want to, but you'll have to restore it exactly as it was. Unfortunately Intel designed VT-x in this way; no such issues exist with AMD-V.

We perform similar checks to see if somebody else has activated VMX root mode and simply refuse to run in that case. VirtualBox only activates VMX root mode when it's running VMs, so refusing to run and issuing a warning might be sufficient.

comment:12 by Sander van Leeuwen, 14 years ago

VirtualBox 3.1.0 has changed the way VMX and AMD-V are used. (at least for Windows hosts) It only turns on VMX root mode on the cpu that is executing guest code and turns it back off again afterwards.

The above mentioned conflict should no longer exist as of 3.1.2. I strongly suggest you implement the VMX root mode check anyway to prevent crashes.

comment:13 by Technologov, 14 years ago

coLinux 0.7.5 check if someone uses VMX mode, and refuses to run.


Anyway it may make sense to test VBox 3.1.2 together with problematic drivers (VirtualPC 5.1/2004, or coLinux 0.7.3/4)


Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use