Unplug Computer. So how did I finally fix the problem? Well, if you are lucky, it’s a super simple. Fix USB Drivers using Device manager. View our post on fixing USB Driver issues in Windows 8. Go to Menu Run; Type device manager in the text box; Select Device Manager; Find Universal Serial Bus controllers and expand the list; Right-click Unknown Device; Select Properties from the context-sensitive menu; Select Drivers; Click Update Driver.
This topic provides guidelines for choosing the best driver model for developing a USB client driver that acts as the device's function driver.
USB device manufacturers must often provide a way for applications to access the device's features. To choose the best mechanism for accessing a USB device, start with the simplest approach and move to more complex solutions only if it is necessary. The following list summarizes the choices discussed in this topic:
- If your device belongs to a USB device class for which Windows includes an inbox driver, you don’t need to write a driver.
- If your device does not have a Microsoft-provided class driver, and the device is accessed by a single application, then load WinUSB as the function driver.
- If the device needs to be accessed by concurrent applications and your device does not have isochronous endpoints, write a UMDF-based client driver.
- If class driver, WinUSB, or UMDF solutions are not options that work for you, write a KMDF-based client driver.
- If a particular feature is not supported by KMDF, write a hybrid driver that calls WDM routines.
The most common approach has been to implement a device driver, (termed as a USB client driver in this documentation set) and provide an installation package that installs the driver as the function driver in the device stack above the Microsoft-provided USB driver stack. The client driver exposes a device interface that applications can use to obtain the device's file handle. Applications can then use this file handle to communicate with the driver by calling Windows APIs.
Writing a driver that is customized to the device's requirements is the most flexible way to provide access to a USB device. However, implementing a driver requires a lot of work. The driver must perform complex tasks, such as driver initialization when new devices are detected, power management, I/O operations, surprise removal, state management, and cleanup when the device is removed. Before you choose to write a driver, ask the following questions:
Can you use a Microsoft-provided driver?
You might not need to write a driver if:
Your device belongs to a USB device class that is supported by Microsoft.
In that case, the corresponding class driver is loaded as the device driver. For a list of device classes for which Windows includes an inbox driver, see USB device class drivers included in Windows.
Your device does not belong to a device class.
For such devices, evaluate the device features to determine whether you can load the Microsoft-provided WinUSB (Winusb.sys) as the device's function driver. Using WinUSB is the best solution if:
- Your device is accessed by a single application.
- Your device supports bulk, interrupt, or isochronous endpoints.
- Your device is intended to work with a target computer running Windows XP with Service Pack 2 (SP2) and later versions of Windows.
Loading WinUSB as the function driver provides a simpler alternative to implementing a custom USB driver. For example, WinUSB is the preferred approach for an electronic weather station that is accessed only by an application that is packaged with the device. It is also useful for diagnostic communication with a device and for flashing firmware.
To make it easy for applications to send requests to Winusb.sys, we provide a user-mode DLL, Winusb.dll, that exposes WinUSB functions. An application can call those functions to access the device, configure it, and transfer data to the device’s endpoints.
WinUSB is not an option if:
- Your device is accessed by multiple applications.
- Your device has functions that already have kernel-mode support in the Windows operating system. For example, for modem functions (which TAPI supports) or LAN functions (which NDIS supports), you must use the interface that the Usbser.sys driver supports to manage modem devices with user-mode software.
In Windows 8, we've added a new compatible ID to the INF for WinUSB installation. If the device firmware contains that compatible ID, WinUSB is loaded by default as the function driver for the device. This means that hardware manufacturers are not required to distribute INF files for their WinUSB devices. For more information, see WinUSB Device.
If you write a USB client driver, which driver model is best?
The answer depends on the design of your device. First, determine whether a particular driver model meets your requirements. Some design considerations are based on whether you want the USB device to be accessed by multiple concurrent applications and support data streaming through isochronous endpoints.
If you choose to write a driver, here are your options:
User-Mode Driver Framework (UMDF)
UMDF provides device driver interfaces (DDIs) that a client driver can use to integrate with Windows components such as the Plug and Play Manager and Power Manager. UMDF also provides specialized target objects for USB devices, which abstract the hardware in user mode and simplify I/O operations for the driver. In addition to the UMDF interfaces, WDF provides enhanced debugger extensions and tracing tools for user-mode drivers. UMDF is based on the component object model (COM) and developing a user-mode driver is easier for a C++ developer.
Implement a UMDF-based client driver for a USB device in the following cases:
- The device is accessed by concurrently by multiple applications.
- The device supports bulk or interrupt transfers.
Drivers that run in user mode can access only the (virtual) user address space and pose a much lower risk to the system. Kernel-mode drivers can access the system address space and the internal system structures. A badly coded kernel-mode driver might cause problems that affect other drivers or the system, and eventually crash the computer. Therefore, a user-mode driver can be safer than a kernel-mode driver in terms of security and stability.
Another advantage of user-mode drivers is that they leverage all the Win32 APIs. For example, the drivers can call APIs such as Winsock, Compression, Encryption APIs, and so on. Those APIs are not available to kernel-mode drivers.
A UMDF-based client driver is not an option for USB devices that support isochronous endpoints.
Note Windows 8.1 introduces version 2.0 of UMDF. With UMDF version 2.0, you can write a UMDF driver in the C programming language that calls many of the methods that are available to KMDF drivers. You cannot use UMDF version 2.0 to write lower filter drivers for USB.
Kernel-Mode Driver Framework (KMDF)
KMDF was designed to make the driver models easy to extend to support new types of hardware. KMDF provides DDIs and data structures that make kernel-mode USB drivers easier to implement than the earlier Windows Driver Model (WDM) drivers. In addition, KMDF provides specialized input/output (I/O) targets that you can use to write a fully functional client driver that uses the Microsoft USB driver stack.
In certain cases where a particular feature is not exposed through KMDF, the driver must call WDM routines. The driver does not need to implement the entire WDM infrastructure but uses KMDF methods to access a select set of WDM routines. For example, to perform isochronous transfers, a KMDF-based client driver can send WDM-style URBs that describe the request to the USB driver stack. Such drivers are called hybrid drivers in this documentation set.
KMDF also supports the port-miniport driver model. For instance, a kernel streaming miniport driver (such as a USB webcam) that uses kernel streaming on the upper edge can use KMDF USB I/O target objects to send requests to the USB driver stack. NDIS drivers can also be written by using KMDF for protocol-based buses such as USB.
Pure WDM drivers are difficult to write, complex, and not robust. With the evolution of KMDF, writing this type of driver is no longer necessary.
Microsoft Visual Studio 2012 includes USB User-Mode Driver and USB Kernel-Mode Driver templates that generate starter code for a UMDF and KMDF USB client driver, respectively. The template code initializes a USB target device object to enable communication with the hardware. For more information, see the following topics:
For information about how to implement UMDF and KMDF drivers, see the Microsoft Press book Developing Drivers with the Windows Driver Foundation.
WinUSB, UMDF, KMDF Feature Comparison
The following table summarizes the capabilities of WinUSB, UMDF-based USB drivers, and KMDF-based USB drivers.
| Feature | WinUSB | UMDF | KMDF |
|---|---|---|---|
| Supports multiple concurrent applications | No | Yes | Yes |
| Isolates driver address space from application address space | No | Yes | No |
| Supports bulk, interrupt, and control transfers | Yes | Yes | Yes |
| Supports isochronous transfers | Yes ⁴ | No | Yes |
| Supports the installation of kernel-mode drivers, such as filter drivers, as an overlying layer on the USB stack | No | No | Yes |
| Supports selective suspend and the wait/wake state | Yes | Yes | Yes |
The following table summarizes the WDF options that are supported by different versions of Windows.
| Windows version | WinUSB | UMDF | KMDF |
|---|---|---|---|
| Windows 8 | Yes | Yes | Yes |
| Windows 7 | Yes | Yes | Yes |
| Windows Vista | Yes¹ | Yes¹ | Yes |
| Windows Server 2003 | No | No | Yes |
| Windows XP | Yes² | Yes² | Yes |
| Microsoft Windows 2000 | No | No | Yes³ |
Note Yes¹: WinUSB and UMDF are supported only on x86-based and x64-based versions of Windows.
Yes²: WINUSB and UMDF are supported in Windows XP with Service Pack 2 (SP2) or later versions of Windows.
Yes³: KMDF is supported in Windows 2000 with SP4 or later versions of Windows.
Yes⁴: Isochronous transfers are supported in Windows 8.1 or later versions of Windows.
All client SKUs of the 32-bit versions of Windows XP with SP2support WinUSB. WinUSB is not native to Windows XP; it must be installed with the WinUSB co-installer. All Windows Vista SKUs and later versions of Windows support WinUSB.
Related topics
Getting started with USB client driver development
WinUSB
Write your first USB client driver (UMDF)
Write your first USB client driver (KMDF)
Features | Documentation | Knowledge Base | Discussion Forums
The following sections describe how to use USB devices in a virtual machine:
VMware Workstation 4 provides a two-port USB 1.1 controller. You can use up to two USB devices in your virtual machine if both your host operating system and your guest operating system support USB. If your host computer supports USB 2.0 devices, you can use those devices in the virtual machine.
Note: Windows NT and Linux kernels older than 2.2.17 do not support USB.
Although your host operating system must support USB, you do not need to install device-specific drivers for your USB devices in the host operating system if you want to use those devices only in the virtual machine.
On a Windows 2000 host computer with USB 2.0 support, be sure you are using the Microsoft USB 2.0 driver for the USB controller. Third-party USB 2.0 drivers, such as those provided by some motherboard manufacturers, are not supported. For notes on replacing the third-party drivers, see Replacing USB 2.0 Drivers on a Windows 2000 Host.
We have tested a variety of USB devices with this release. In general, if the guest operating system has appropriate drivers, you should be able to use PDAs, printers, storage (disk) devices, scanners, MP3 players, digital cameras and memory card readers.
Modems and certain streaming data devices, such as speakers and Web cams, do not work properly.
The virtual machine's USB ports are enabled by default. If you will not be using USB devices in a virtual machine, you can disable its USB controller using the virtual machine settings editor.
When a virtual machine is running, its window is the active window and a USB device is plugged into the host computer, the device automatically connects to the guest instead of the host. This autoconnect feature can be disabled in the USB Controller panel of the virtual machine settings editor (VM > Settings). If all of the virtual machine's USB ports are already occupied when it is trying to connect automatically to a new device, a dialog box gives you a choice: you can either disconnect one of the existing USB devices to free its port or ignore the new device, allowing the device to connect to the host.
Choose VM > Removable Devices to connect specific USB devices to your virtual machine. You can connect up to two USB devices at a time. If the physical USB devices are connected to the host computer through a hub, the virtual machine sees only the USB devices, not the hub.
There is a menu item for each of the USB ports. Move the mouse over one of these items to see a cascading menu of devices that are plugged into your host computer and available for use. To connect a device to the virtual machine, click its name.
If a device is already connected to that port, click the name of a new device to release the first device and connect the new one.
To release a connected device, click None on the cascading menu for the port to which it is connected.
If you physically plug a new device into the host computer and the autoconnect feature does not connect it to a virtual machine, the device is initially connected to the host. Its name is also added to the VM > Removable Devices menu so you can connect it to the virtual machine manually.
Windows 2000, Windows XP and Windows Server 2003 hosts: When a particular USB device is connected to a virtual machine for the first time, the host detects it as a new device named VMware USB Device and installs the appropriate VMware driver.
Windows XP and Windows Server 2003 hosts: User confirmation is required in the Found New Hardware Wizard. Select the default action — Install the software automatically. Once the software is installed, the guest operating system detects the USB device and searches for a suitable driver.
These actions include automatically extending Alaska's driver license expiration dates until the end of the disaster declaration, suspending the requirement that non-residents acquire an Alaskan driver's license and suspending the requirement that the new owner of a vehicle title and register a vehicle in their name within 30 days of new ownership. Drivers alaska.
When you are synchronizing a PDA, such as a Palm handheld or Handspring Visor, to a virtual machine for the first time, the total time required to load the VMware USB device driver in the host and the PDA driver in the guest may exceed the device's connection timeout value. This causes the device to disconnect itself from the computer before the guest can synchronize with it. If this occurs, let the guest finish installing the PDA driver, dismiss any connection error warnings, then try synchronizing the PDA again. The second attempt should succeed.
To use VMware Workstation 4 on a Windows 2000 host that has USB 2.0 ports, you must use the Microsoft USB 2.0 drivers for the USB controller in the host operating system. If your host operating system is using a third-party driver — a driver supplied by your motherboard vendor, for example — you must replace it.
Take the following steps to check the provider of your driver:
- Go to the Device Manager. Right-click My Computer, choose Properties, click the Hardware tab, then click Device Manager.
- Expand the listing for Universal Serial Bus controllers.
- Right-click the listing for the controller and choose Properties.
- Click the Driver tab. If the driver provider shown on that page is Microsoft, you have the correct driver already.
If the driver provider is not Microsoft, download the latest USB driver for your host operating system from the Microsoft Web site and follow the Microsoft instructions to install it. Details are available in Microsoft knowledge base article 319973.
Any user on a Windows host can connect USB devices for use in a virtual machine. You no longer need administrative privileges on the host to connect a USB device to a virtual machine.
This functionality is not enabled by default. To enable it, you must use a text editor such as Notepad to add one line to the global configuration file. This file is
C:Documents and Settings<username>Application DataVMwareconfig.ini
Add the following line anywhere in the file:
Acer (Notebooks, Tablets, Desktops) Any Windows 10 drivers by Acer, for your Acer computer, are. 
Download the latest drivers, software, firmware, and diagnostics for your HP products from the official HP Support website. Will damage your computer message displays when printing or while installing - Click Here. Depending on your desktop model you can find it on the side, top, front or back of the computer. Having an issue with your display, audio, or touchpad? Whether you're working on an Alienware, Inspiron, Latitude, or other Dell product, driver updates keep your device running at top performance. Step 1: Identify your product above. Step 2: Run the detect drivers scan to see available updates. Step 3: Choose which driver updates to install.
usb.EnablePnpMgr = TRUE
Note: A user with administrative privileges on the host operating system must install a USB device on the host before it can be connected by users who do not have administrative privileges.
Drivers Cruiser Team Usb Devices 3.0
On Linux hosts, VMware Workstation uses the USB device file system to connect to USB devices. In most Linux systems that support USB, the USB device file system is at /proc/bus/usb. If your host operating system uses a different path to the USB device file system, you can change it in the virtual machine settings editor (VM > Settings > USB). Enter the correct path in the Path to usbdevfs field.
Drivers Cruiser Team Usb Devices Pc Camera
Only one computer — host or guest — can have control of a USB device at any one time.
/how-to-connect-usb-devices-to-ipad-1999862_v7-5b2d680243a103003683c3dc.png "Cruiser")
Device Control on a Windows Host When you connect a device to a virtual machine, it is 'unplugged' from the host or from the virtual machine that previously had control of the device. When you disconnect a device from a virtual machine, it is 'plugged in' to the host.
Caution: On Windows 2000, Windows XP and Windows Server 2003 hosts, you need to take a special step to disconnect USB network and storage devices from the host. There is a system tray icon called Eject Hardware on Windows 2000 and Safely Remove Hardware on Windows XP and Windows Server 2003. Use this icon to disconnect the device from the host before connecting it to a virtual machine.
Note: On Windows 2000, Windows XP and Windows Server 2003 hosts, when you connect a USB network or storage device in a virtual machine, you may see a message on your host that says the device can be removed safely. This is normal behavior, and you can simply dismiss the dialog box. However, do not remove the device from your physical computer. VMware Workstation automatically transfers control of the device to the virtual machine.
Under some circumstances, if a USB storage device is in use on the host (for example, one or more files stored on the device are open on the host), an error appears in the virtual machine when you try to connect to the device. You must let the host complete its operation or close any application connected to the device on the host, then connect to the device in the virtual machine again.
On Linux hosts, guest operating systems can use devices that are not already in use by the host — that is, devices that are not claimed by a host operating system driver.
If your device is in use by the host and you try to connect it to the guest using the VM > Removable Devices menu, a dialog box appears, informing you that there is a problem connecting to the device.
To disconnect the device from the host, you must unload the device driver. You can unload the driver manually as root (su) using the rmmod command. Or, if the driver was automatically loaded by hotplug, you can disable it in the hotplug configuration files in the /etc/hotplug directory. See your Linux distribution's documentation for details on editing these configuration files.
A related issue sometimes affects devices that rely on automatic connection (as PDAs often do).
If you have successfully used autoconnection to connect the device to your virtual machine, then experience problems with the connection to the device, take the following steps:
- Disconnect and reconnect the device. You can either unplug it physically, then plug it back in or use the VM > Removable Devices menu to disconnect it and reconnect it.
- If you see a dialog box warning that the device is in use, disable it in the hotplug configuration files in the /etc/hotplug directory.
Disconnecting USB Devices from a Virtual Machine Before unplugging a USB device or using the VM > Removable Devices menu to disconnect it from a virtual machine, be sure it is in a safe state.
You should follow the procedures the device manufacturer specifies for unplugging the device from a physical computer. Drivers cst usb devices. This is true whether you are physically unplugging it, moving it from host to virtual machine, moving it between virtual machines or moving it from virtual machine to host.
This is particularly important with data storage devices (a Zip drive, for example). If you move a data storage device too soon after saving a file and the operating system has not actually written the data to the disk, you can lose data.
USB human interface devices, such as the keyboard and mouse, are not handled though the virtual machine's USB controller. Instead, they appear in the virtual machine as a standard PS/2 keyboard and mouse, even though they are plugged into USB ports on the host.