VirtualBox makes use of the Microsoft Component Object Model (COM)
for inter- and intra-process communication. This allows VirtualBox to
share a common configuration among different virtual machine processes
and provide several user interface options based on a common
architecture. All global status information and configuration is
maintained by the process VBoxSVC.exe
,
which is an out-of-process COM server. Whenever a VirtualBox process is
started, it requests access to the COM server and Windows automatically
starts the process. Note that it should never be started by the end
user.
When the last process disconnects from the COM server, it will terminate itself after some seconds. The VirtualBox configuration (XML files) is maintained and owned by the COM server and the files are locked whenever the server runs.
In some cases - such as when a virtual machine is terminated
unexpectedly - the COM server will not notice that the client is
disconnected and stay active for a longer period (10 minutes or so)
keeping the configuration files locked. In other rare cases the COM
server might experience an internal error and subsequently other
processes fail to initialize it. In these situations, it is recommended
to use the Windows task manager to kill the process
VBoxSVC.exe
.
In case you have assigned a physical CD/DVD drive to a guest and the guest does not notice when the medium changes, make sure that the Windows media change notification (MCN) feature is not turned off. This is represented by the following key in the Windows registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Cdrom\Autorun
Certain applications may disable this key against Microsoft's advice. If it is set to 0, change it to 1 and reboot your system. VirtualBox relies on Windows notifying it of media changes.
If connecting to a Virtual Machine via the Microsoft RDP client (called Remote Desktop Connection), there can be large delays between input (moving the mouse over a menu is the most obvious situation) and output. This is because this RDP client collects input for a certain time before sending it to the RDP server.
The interval can be decreased by setting a Windows registry key to smaller values than the default of 100. The key does not exist initially and must be of type DWORD. The unit for its values is milliseconds. Values around 20 are suitable for low-bandwidth connections between the RDP client and server. Values around 4 can be used for a gigabit Ethernet connection. Generally values below 10 achieve a performance that is very close to that of the local input devices and screen of the host on which the Virtual Machine is running.
Depending whether the setting should be changed for an individual user or for the system, either
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Min Send Interval
or
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\Min Send Interval
can be set appropriately.
Deadlocks can occur on a Windows host when attempting to access an iSCSI target running in a guest virtual machine with an iSCSI initiator (e.g. Microsoft iSCSI Initiator) that is running on the host. This is caused by a flaw in the Windows cache manager component, and causes sluggish host system response for several minutes, followed by a "Delayed Write Failed" error message in the system tray or in a separate message window. The guest is blocked during that period and may show error messages or become unstable.
Setting the environment variable
VBOX_DISABLE_HOST_DISK_CACHE
to 1 will
enable a workaround for this problem until Microsoft addresses the
issue. For example, open a command prompt window and start VirtualBox
like this:
set VBOX_DISABLE_HOST_DISK_CACHE=1 VirtualBox
While this will decrease guest disk performance (especially writes), it does not affect the performance of other applications running on the host.
If no bridged adapters show up in the "Networking" section of the VM settings, this typically means that the bridged networking driver was not installed properly on your host. This could be due to the following reasons:
-
The maximum allowed filter count was reached on the host. In this case, the MSI log would mention the
0x8004a029
error code returned on NetFlt network component install:VBoxNetCfgWinInstallComponent: Install failed, hr (0x8004a029)
You can try to increase the maximum filter count in the Windows registry at the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\MaxNumFilters
The maximum number allowed is 14. After a reboot, try to re-install VirtualBox.
-
The INF cache is corrupt. In this case, the install log (
%windir%\inf\setupapi.log
on XP or%windir%\inf\setupapi.dev.log
on Vista or later) would typically mention the failure to find a suitable driver package for either thesun_VBoxNetFlt
orsun_VBoxNetFltmp
components. The solution then is to uninstall VirtualBox, remove the INF cache (%windir%\inf\INFCACHE.1
), reboot and try to re-install VirtualBox
If host-only adapter cannot be created (either via the Manager or
VBoxManage), then the INF cache is probably corrupt. In this case, the
install log (%windir%\inf\setupapi.log
on XP or %windir%\inf\setupapi.dev.log
on Vista or later) would typically mention the failure to find a
suitable driver package for the
sun_VBoxNetAdp
component. Again, as
with the bridged networking problem described above, the solution is to
uninstall VirtualBox, remove the INF cache
(%windir%\inf\INFCACHE.1
), reboot and
try to re-install VirtualBox.