12.7. Windows hosts

Oracle VM VirtualBox

12.7. Windows hosts

12.7.1. VBoxSVC out-of-process COM server issues

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.

12.7.2. CD/DVD changes not recognized

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.

12.7.3. Sluggish response when using Microsoft RDP client

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.

12.7.4. Running an iSCSI initiator and target on a single system

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.

12.7.5. Bridged networking adapters missing

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 the sun_VBoxNetFlt or sun_VBoxNetFltmp components. The solution then is to uninstall VirtualBox, remove the INF cache (%windir%\inf\INFCACHE.1), reboot and try to re-install VirtualBox

12.7.6. Host-only networking adapters cannot be created

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.