12.3. Windows guests

If a Windows 7 or Windows Server 2008 R2 guest is configured for USB 3.0 (xHCI) support, the guest OS will not have any USB support at all. This happens because Windows 7 predates USB 3.0 and therefore does not ship with any xHCI drivers; Microsoft also does not offer any vendor-provided xHCI drivers via Windows Update.

To solve this problem, it is necessary to download and install the Intel xHCI driver in the guest. Intel offers the driver as the USB 3.0 eXtensible Host Controller (xHCI) driver for Intel 7 Series/C216 chipsets.

Note that the driver only supports Windows 7 and Windows Server 2008 R2. The driver package includes support for both 32-bit and 64-bit OS variants.

Changing certain virtual machine settings can cause Windows guests to fail during start up with a bluescreen. This may happen if you change VM settings after installing Windows, or if you copy a disk image with an already installed Windows to a newly created VM which has settings that differ from the original machine.

This applies in particular to the following settings:

If a VM is configured to have more than one processor (symmetrical multiprocessing, SMP), some configurations of Windows guests crash with an 0x101 error message, indicating a timeout for inter-processor interrupts (IPIs). These interrupts synchronize memory management between processors.

According to Microsoft, this is due to a race condition in Windows. A hotfix is available.^[50] If this does not help, please reduce the number of virtual processors to 1.

When installing Windows 2000 guests, you might run into one of the following issues:

These problems are all caused by a bug in the hard disk driver of Windows 2000. After issuing a hard disk request, there is a race condition in the Windows driver code which leads to corruption if the operation completes too fast, i.e. the hardware interrupt from the IDE controller arrives too soon. With physical hardware, there is a guaranteed delay in most systems so the problem is usually hidden there (however it should be possible to reproduce it on physical hardware as well). In a virtual environment, it is possible for the operation to be done immediately (especially on very fast systems with multiple CPUs) and the interrupt is signaled sooner than on a physical system. The solution is to introduce an artificial delay before delivering such interrupts. This delay can be configured for a VM using the following command:

VBoxManage setextradata "VM name" "VBoxInternal/Devices/piix3ide/0/Config/IRQDelay" 1

This sets the delay to one millisecond. In case this doesn't help, increase it to a value between 1 and 5 milliseconds. Please note that this slows down disk performance. After installation, you should be able to remove the key (or set it to 0).

When Windows guests run into a kernel crash, they display the infamous bluescreen. Depending on how Windows is configured, the information will remain on the screen until the machine is restarted or it will reboot automatically. During installation, Windows is usually configured to reboot automatically. With automatic reboots, there is no chance to record the bluescreen information which might be important for problem determination.

VirtualBox provides a method of halting a guest when it wants to perform a reset. In order to enable this feature, issue the following command:

VBoxManage setextradata "VM name" "VBoxInternal/PDM/HaltOnReset" 1

Certain editions of Windows 2000 and 2003 servers support more than 4 GB RAM on 32-bit systems. The AMD PCnet network driver shipped with Windows Server 2003 fails to load if the 32-bit guest OS uses paging extensions (which will occur with more than approximately 3.5 GB RAM assigned to the VM).

This problem is known to occur with version 4.38.0.0 of the PCnet driver. The issue was fixed in version 4.51.0.0 of the driver, which is available as a separate download. An alternative solution may be changing the emulated NIC type to Intel PRO/1000 MT Desktop (82540EM), or reducing the RAM assigned to the VM to approximately 3.5 GB or less.

With Windows Vista, Microsoft dropped support for the AMD PCNet card that VirtualBox used to provide as the default virtual network card before version 1.6.0. For Windows Vista guests, VirtualBox now uses an Intel E1000 card by default.

If, for some reason, you still want to use the AMD card, you need to download the PCNet driver from the AMD website (available for 32-bit Windows only). You can transfer it into the virtual machine using a shared folder, see (see Section 4.3, “Shared folders”).

Several background applications of Windows guests, especially virus scanners, are known to increases the CPU load notably even if the guest appears to be idle. We recommend to deactivate virus scanners within virtualized guests if possible.

The performance for accesses to shared folders from a Windows guest might be decreased due to delays during the resolution of the VirtualBox shared folders name service. To fix these delays, add the following entries to the file \windows\system32\drivers\etc\lmhosts of the Windows guest:

255.255.255.255        VBOXSVR #PRE
255.255.255.255        VBOXSRV #PRE

After doing this change, a reboot of the guest is required.

If a Windows 98 VM is configured to use the emulated USB tablet (absolute pointing device), the coordinate translation may be incorrect and the pointer is restricted to the upper left quarter of the guest's screen.

The USB HID (Human Interface Device) drivers in Windows 98 are very old and do not handle tablets the same way all more recent operating systems do (Windows 2000 and later, Mac OS X, Solaris). To work around the problem, issue the following command:

VBoxManage setextradata "VM name" "VBoxInternal/USB/HidMouse/0/Config/CoordShift" 0

To restore the default behavior, remove the key or set its value to 1.

If a Windows guest is a member of an Active Directory domain and the snapshot feature of VirtualBox is used, it could happen it loses this status after you restore an older snapshot.

The reason is the automatic machine password changing performed by Windows in regular intervals for security purposes. You can disable this feature by following the instruction of this http://support.microsoft.com/kb/154501 article from Microsoft.

VirtualBox Guest Additions for Windows prior to 4.1.8 did not properly back up the original d3d8.dll and d3d9.dll system files when selecting and installing the experimental Direct3D support. This process replaces both system files with files from the VirtualBox Guest Additions so that Direct3D calls can be handled correctly. Although this issue was fixed with VirtualBox 4.1.8, there is no way the Windows Guest Additions installer can repair these files.

Corruption of these files has no implications in case 3D acceleration is enabled and basic Direct3D support is installed, that is, without WDDM (on Windows Vista or higher) or on older Windows systems like Windows XP. With the basic Direct3D support all Direct3D 8.0 and Direct3D 9.0 applications will utilize VirtualBox Direct3D files directly and thus will run as expected.

For WDDM Direct3D support however, the originally shipped d3d8.dll and d3d9.dll files are required in order to run Direct3D 8.0 and Direct3D 9.0 applications. As a result of the above mentioned system files corruption these applications will not work anymore. See below for a step-by-step guide for restoring the original d3d8.dll and d3d9.dll system files in case the VirtualBox Guest Additions installer warned about those incorrect files or when having trouble running Direct3D applications.

This is why such a detected file corruption is not considered as fatal for the basic Direct3D installation on all supported Windows guests, and for WDDM Direct3D installation on Windows 7 and later guests.

Extracting d3d8 and d3d9.dll from a Windows XP installation CD:

Extracting d3d8 and d3d9.dll from Windows XP Service pack

Extracting d3d8 and d3d9.dll from Vista/Windows7 installation CD or Service Pack iso

Windows 3.x guests are typically limited to 64 MB RAM, even if a VM is assigned much more memory. While Windows 3.1 is theoretically capable of using up to 512 MB RAM, it only uses memory available through the XMS interface. Versions of HIMEM.SYS (the Microsoft XMS manager) shipped with MS-DOS and Microsoft Windows 3.x can only use up to 64 MB on standard PCs.

This is a HIMEM.SYS limitation documented by Microsoft in Knowledge base article KB 116256. Windows 3.1 memory limits are described in detail in Microsoft Knowledge base article KB 84388.

It is possible for Windows 3.x guests to utilize more than 64 MB RAM if a different XMS provider is used. That could be a newer HIMEM.SYS version (such as that shipped with Windows 98), or a more capable third-party memory manager (such as QEMM).