5.3. Windows Guests

5.3.1. No USB 3.0 Support in Windows 7 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 through 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.

5.3.2. Windows Bluescreens After Changing VM Configuration

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:

  • The ACPI and I/O APIC settings should never be changed after installing Windows. Depending on the presence of these hardware features, the Windows installation program chooses special kernel and device driver versions and will fail to startup should these hardware features be removed. Enabling them for a Windows VM which was installed without them does not cause any harm. However, Windows will not use these features in this case.

  • Changing the storage controller hardware will cause bootup failures as well. This might also apply to you if you copy a disk image from an older version of Oracle VM VirtualBox to a virtual machine created with a newer Oracle VM VirtualBox version. The default subtype of IDE controller hardware was changed from PIIX3 to PIIX4 with Oracle VM VirtualBox 2.2. Make sure these settings are identical.

5.3.3. Windows 0x101 Bluescreens with SMP Enabled (IPI Timeout)

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 interprocessor 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. See http://support.microsoft.com/kb/955076.

If this does not help, please reduce the number of virtual processors to 1.

5.3.4. Windows 2000 Installation Failures

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

  • Installation reboots, usually during component registration.

  • Installation fills the whole hard disk with empty log files.

  • Installation complains about a failure installing msgina.dll.

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. For example, 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 also reproduce it on physical hardware. 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 does not 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.

5.3.5. How to Record Bluescreen Information from Windows Guests

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.

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

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

5.3.6. PCnet Driver Failure in 32-bit Windows Server 2003 Guests

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.

5.3.7. No Networking in Windows Vista Guests

With Windows Vista, Microsoft dropped support for the AMD PCNet card that Oracle VM VirtualBox used to provide as the default virtual network card before version 1.6.0. For Windows Vista guests, Oracle VM 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. This driver is available for 32-bit Windows only. You can transfer it into the virtual machine using a shared folder. See Shared Folders.

5.3.8. Windows Guests may Cause a High CPU Load

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.

5.3.9. Long Delays When Accessing Shared Folders

The performance for accesses to shared folders from a Windows guest might be decreased due to delays during the resolution of the Oracle VM 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.

5.3.10. USB Tablet Coordinates Wrong in Windows 98 Guests

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 as more recent operating systems do. For example, Windows 2000 and later, Mac OS X, and Oracle Solaris. To work around the problem, use 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.

5.3.11. Windows Guests are Removed From an Active Directory Domain After Restoring a Snapshot

If a Windows guest is a member of an Active Directory domain and the snapshot feature of Oracle VM 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 at regular intervals for security purposes. You can disable this feature by following the instruction of the following article from Microsoft: http://support.microsoft.com/kb/154501

5.3.12. Restoring d3d8.dll and d3d9.dll

Oracle VM 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 Guest Additions so that Direct3D calls can be handled correctly. Although this issue was fixed with Oracle VM VirtualBox 4.1.8, there is no way the Windows Guest Additions installer can repair these files.

Corruption of these files has no implications if 3D acceleration is enabled and basic Direct3D support is installed. That is, without WDDM on Windows Vista or later, or on older Windows systems like Windows XP. With the basic Direct3D support all Direct3D 8.0 and Direct3D 9.0 applications will utilize Oracle VM 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 Oracle VM VirtualBox Guest Additions installer warned about those incorrect files or when having trouble running Direct3D applications.

Note

Starting at Windows 7 the 3D desktop, called Aero, uses DirectX 10 for rendering so that corrupted d3d8.dll and d3d9.dll system files will have no effect on the actual rendering.

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:

  1. Download and install the latest version of 7-Zip File Manager.

  2. Browse into the installation CD. For example E:\i386, or E:\amd64 for the 64-bit version.

  3. Locate the entries d3d8.dl_ and d3d9.dl_. Double-click on the file names and extract d3d8.dll and d3d9.dll.

  4. Reboot Windows in Safe mode.

  5. Copy the extracted d3d8.dll and d3d9.dll files to C:\Windows\system32 and C:\Windows\system32\dllcache.

  6. Reboot Windows.

Extracting d3d8 and d3d9.dll from a Windows XP Service pack:

  1. Download and install the latest version of 7-Zip File Manager.

  2. Choose Open Inside, to open WindowsXP-KB936929-SP3-x86.exe as an archive and browse the i386 directory.

  3. Locate the entries d3d8.dl_ and d3d9.dl_. Double-click on the file names and extract d3d8.dll and d3d9.dll.

  4. Reboot Windows in Safe mode.

  5. Copy the extracted d3d8.dll and d3d9.dll files to C:\Windows\system32 and C:\Windows\system32\dllcache.

  6. Reboot Windows.

Extracting d3d8 and d3d9.dll from a Vista/Windows7 installation CD or Service Pack ISO:

  1. Download and install the latest version of 7-Zip File Manager.

  2. Browse into the installation CD. For example E:\sources.

  3. Locate file install.wim and double-click the file. After the 7-Zip utility unzips the file, you will see a few numbered folders. Each numeric subfolder represents a different version of Windows such as Starter or Home Basic.

  4. Open one of the numeric folders and browse to the Windows\System32 directory, or C:\Windows\SysWOW64 for the 64-bit version. Locate and extract the d3d8.dll and d3d9.dll files.

  5. Copy extracted the d3d8.dll and d3d9.dll files to C:\Windows\system32 or C:\Windows\SysWOW64. Files from system32 should go to system32, from SysWOW64 to SysWOW64.

  6. Reboot Windows.

5.3.13. Windows 3.x Limited to 64 MB RAM

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.