NI-VISA is an NI instrument driver that is an implementation of the Virtual Instrument Software Architecture (VISA) I/O standard. VISA is a standard for configuring, programming, and troubleshooting instrumentation systems comprising GPIB, VXI, PXI, serial (RS232/RS485), Ethernet/LXI, and/or USB interfaces.
For certain Universal Serial Bus (USB) devices, such as devices that are accessed by only a single application, you can install WinUSB (Winusb.sys) in the device's kernel-mode stack as the USB device's function driver instead of implementing a driver.
This topic contains these sections:
Automatic installation of WinUSB without an INF file
As an OEM or independent hardware vendor (IHV), you can build your device so that the Winusb.sys gets installed automatically on Windows 8 and later versions of the operating system. Such a device is called a WinUSB device and does not require you to write a custom INF file that references in-box Winusb.inf.
When you connect a WinUSB device, the system reads device information and loads Winusb.sys automatically.
For more information, see WinUSB Device.
Installing WinUSB by specifying the system-provided device class
When you connect your device, you might notice that Windows loads Winusb.sys automatically (if the IHV has defined the device as a WinUSB Device). Otherwise follow these instructions to load the driver:
- Plug in your device to the host system.
- Open Device Manager and locate the device.
- Select and hold (or right-click) the device and select Update driver software... from the context menu.
- In the wizard, select Browse my computer for driver software.
- Select Let me pick from a list of device drivers on my computer.
- From the list of device classes, select Universal Serial Bus devices.
- The wizard displays WinUsb Device. Select it to load the driver.
If Universal Serial Bus devices does not appear in the list of device classes, then you need to install the driver by using a custom INF.The preceding procedure does not add a device interface GUID for an app (UWP app or Windows desktop app) to access the device. You must add the GUID manually by following this procedure.
Load the driver as described in the preceding procedure.
Generate a device interface GUID for your device, by using a tool such as guidgen.exe.
Find the registry key for the device under this key:
Under the Device Parameters key, add a String registry entry named DeviceInterfaceGUID or a Multi-String entry named DeviceInterfaceGUIDs. Set the value to the GUID you generated in step 2.
Disconnect the device from the system and reconnect it to the same physical port.Note If you change the physical port then you must repeat steps 1 through 4.
Writing a custom INF for WinUSB installation
As part of the driver package, you provide an .inf file that installs Winusb.sys as the function driver for the USB device.
The following example .inf file shows WinUSB installation for most USB devices with some modifications, such as changing USB_Install in section names to an appropriate DDInstall value. You should also change the version, manufacturer, and model sections as necessary. For example, provide an appropriate manufacture's name, the name of your signed catalog file, the correct device class, and the vendor identifier (VID) and product identifier (PID) for the device.
Download Microsoft USB Flash Drive Manager (Standard) From ...
Also notice that the setup class is set to 'USBDevice'. Vendors can use the 'USBDevice' setup class for devices that do not belong to another class and are not USB host controllers or hubs.
If you are installing WinUSB as the function driver for one of the functions in a USB composite device, you must provide the hardware ID that is associated with the function, in the INF. You can obtain the hardware ID for the function from the properties of the devnode in Device Manager. The hardware ID string format is 'USBVID_vvvv&PID_pppp'.
The following INF installs WinUSB as the OSR USB FX2 board's function driver on a x64-based system.
Starting in Windows 10, version 1709, the Windows Driver Kit provides InfVerif.exe that you can use to test a driver INF file to make sure there are no syntax issues and the INF file is universal. We recommened that you provide a universal INF. For more information, see Using a Universal INF File.
Only include a ClassInstall32 section in a device INF file to install a new custom device setup class. INF files for devices in an installed class, whether a system-supplied device setup class or a custom class, must not include a ClassInstall32 section.
Except for device-specific values and several issues that are noted in the following list, you can use these sections and directives to install WinUSB for any USB device. These list items describe the Includes and Directives in the preceding .inf file.
USB Mass Storage Driver Missing - Microsoft Community
USB_Install: The Include and Needs directives in the USB_Install section are required for installing WinUSB. You should not modify these directives.
USB_Install.Services: The Include directive in the USB_Install.Services section includes the system-supplied .inf for WinUSB (WinUSB.inf). This .inf file is installed by the WinUSB co-installer if it isn't already on the target system. The Needs directive specifies the section within WinUSB.inf that contains information required to install Winusb.sys as the device's function driver. You should not modify these directives.Note Because Windows XP doesn't provide WinUSB.inf, the file must either be copied to Windows XP systems by the co-installer, or you should provide a separate decorated section for Windows XP.
USB_Install.HW: This section is the key in the .inf file. It specifies the device interface globally unique identifier (GUID) for your device. The AddReg directive sets the specified interface GUID in a standard registry value. When Winusb.sys is loaded as the device's function driver, it reads the registry value DeviceInterfaceGUIDs key and uses the specified GUID to represent the device interface. You should replace the GUID in this example with one that you create specifically for your device. If the protocols for the device change, create a new device interface GUID.
Note User-mode software must call SetupDiGetClassDevs to enumerate the registered device interfaces that are associated with one of the device interface classes specified under the DeviceInterfaceGUIDs key. SetupDiGetClassDevs returns the device handle for the device that the user-mode software must then pass to the WinUsb_Initialize routine to obtain a WinUSB handle for the device interface. For more info about these routines, see How to Access a USB Device by Using WinUSB Functions.
The following INF installs WinUSB as the OSR USB FX2 board's function driver on a x64-based system. The example shows INF with WDF coinstallers.
USB_Install.CoInstallers: This section, which includes the referenced AddReg and CopyFiles sections, contains data and instructions to install the WinUSB and KMDF co-installers and associate them with the device. Most USB devices can use these sections and directives without modification.
The x86-based and x64-based versions of Windows have separate co-installers.
Note Each co-installer has free and checked versions. Use the free version to install WinUSB on free builds of Windows, including all retail versions. Use the checked version (with the '_chk' suffix) to install WinUSB on checked builds of Windows.
Each time Winusb.sys loads, it registers a device interface that has the device interface classes that are specified in the registry under the DeviceInterfaceGUIDs key.
Note If you use the redistributable WinUSB package for Windows XP or Windows Server 2003, make sure that you don't uninstall WinUSB in your uninstall packages. Other USB devices might be using WinUSB, so its binaries must remain in the shared folder.
How to create a driver package that installs Winusb.sys
To use WinUSB as the device's function driver, you create a driver package. The driver package must contain these files:
- WinUSB co-installer (Winusbcoinstaller.dll)
- KMDF co-installer (WdfcoinstallerXXX.dll)
- An .inf file that installs Winusb.sys as the device's function driver. For more information, see Writing an .Inf File for WinUSB Installation.
- A signed catalog file for the package. This file is required to install WinUSB on x64 versions of Windows starting with Vista.
Note Make sure that the driver package contents meet these requirements:
- The KMDF and WinUSB co-installer files must be obtained from the same version of the Windows Driver Kit (WDK).
- The co-installer files must be obtained from the latest version of the WDK, so that the driver supports all the latest Windows releases.
- The contents of the driver package must be digitally signed with a Winqual release signature. For more info about how to create and test signed catalog files, see Kernel-Mode Code Signing Walkthrough on the Windows Dev Center - Hardware site.
Download the Windows Driver Kit (WDK) and install it.
Create a driver package folder on the machine that the USB device is connected to. For example, c:UsbDevice.
Copy the WinUSB co-installer (WinusbcoinstallerX.dll) from the WinDDKBuildNumberredistwinusb folder to the driver package folder.
The WinUSB co-installer (Winusbcoinstaller.dll) installs WinUSB on the target system, if necessary. The WDK includes three versions of the co-installer depending on the system architecture: x86-based, x64-based, and Itanium-based systems. They are all named WinusbcoinstallerX.dll and are located in the appropriate subdirectory in the WinDDKBuildNumberredistwinusb folder.
Copy the KMDF co-installer (WdfcoinstallerXXX.dll) from the WinDDKBuildNumberredistwdf folder to the driver package folder.
The KMDF co-installer (WdfcoinstallerXXX.dll) installs the correct version of KMDF on the target system, if necessary. The version of WinUSB co-installer must match the KMDF co-installer because KMDF-based client drivers, such as Winusb.sys, require the corresponding version of the KMDF framework to be installed properly on the system. For example, Winusbcoinstaller2.dll requires KMDF version 1.9, which is installed by Wdfcoinstaller01009.dll. The x86 and x64 versions of WdfcoinstallerXXX.dll are included with the WDK under the WinDDKBuildNumberredistwdf folder. The following table shows the WinUSB co-installer and the associated KMDF co-installer to use on the target system.
Use this table to determine the WinUSB co-installer and the associated KMDF co-installer.
WinUSB co-installer KMDF library version KMDF co-installer Winusbcoinstaller.dll Requires KMDF version 1.5 or later
Winusbcoinstaller2.dll Requires KMDF version 1.9 or later Wdfcoinstaller01009.dll Winusbcoinstaller2.dll Requires KMDF version 1.11 or later WdfCoInstaller01011.dll
Write an .inf file that installs Winusb.sys as the function driver for the USB device.
Create a signed catalog file for the package. This file is required to install WinUSB on x64 versions of Windows.
Attach the USB device to your computer.
Open Device Manager to install the driver. Follow the instructions on the Update Driver Software wizard and choose manual installation. You will need to provide the location of the driver package folder to complete the installation.
WinUSB Architecture and Modules
Choosing a driver model for developing a USB client driver
How to Access a USB Device by Using WinUSB Functions
WinUSB Power Management
WinUSB Functions for Pipe Policy Modification
This article explains the creation process of a Linux kernel device driver foran undocumented USB device. After having reverse-engineered the USBcommunication protocol, I present the architecture of the USB device driver. Inaddition to the kernel driver I introduce a simple user-space tool that can beused to control the device. Although I have to delve into the specifics of aparticular device, the process can be applied to other USB devices as well.
Recently, I found a fancy device while searching eBay: the DreamCheeky USBmissile launcher. The manufacturer neitherprovides a Linux driver nor publishes the USB protocol specification. Only abinary Windows driver is available, turning the missile launcher into complete“black-box” for Linux users. What a challenge! Let’s get the damn gadgetworking under Linux.
To facilitate USB programming, the USB interface is accessible from user-spacewith libusb, a programming API concealinglow-level kernel interaction. The proper way to write a device driver for themissile launcher would hence be to leverage this API and ignore any kernelspecifics. Nevertheless, I wanted to get involved with kernel programming anddecided thus to write a kernel module despite the increased complexity andhigher effort.
The remainder of this article is structured as follows. After pointing to somerelated work, I give a quick USB overview. Thereafter, I present thereverse-engineering process to gather the unknown USB commands steering themissile launcher. To come up with a full-featured kernel device driver, Idescribe the kernel module architecture which incorporates the derived controlcommands. Finally, I demonstrate a simple tool in user-space that makes use ofthe driver.
Apparently I have not been the only one who played with this gadget. However,none of the existing approaches I have encountered pursue the creation of aLinux device driver for the kernel. The LauncherLibrary provides a user-spacelibrary based on libusb. AHmissile is aGTK+ control tool; a ncurses application isavailable, too.Apple users get happy with the USB missile launcherNZ project. Moreover, the python implementationpymissile supports a missilelauncher of a different manufacturer. The author combined the missilelauncher with a webcam in order to to create an automated sentry guard reactingon motion. I will return to these funky ideas later.
The universal serial bus (USB) connects a host computer with numerousperipheral devices. It was designed to unify a wide range of slow and old buses(parallel, serial, and keyboard connections) into a single bus type. It istopologically not constructed as a bus, but rather as a tree of severalpoint-to-point links. The USB host controller periodically polls each device ifit has data to send. With this design, no device can send before it has not beenasked to do so, resulting in a plug-and-play-friendly architecture.
Linux supports two main types of drivers: host and device drivers. Let’s ignorethe host component and have a deeper look at the USB device. As shown on theright side, a USB device consists of one or more configurationswhich in turn have one ore more interfaces. These interfaces contain zero ormore endpoints which make up the basic form of USB communication. An endpointis always uni-directional, either from the host to the device (OUT endpoint)or from the device to the host (IN endpoint). There are four types ofendpoints and each transmits data in a different way:
Control endpoints are generally used to control the USB deviceasynchronously, i.e. sending commands to it or retrieving status informationabout it. Every device possesses a control “endpoint 0” which is used by the USBcore to initialize the device. Interrupt endpoints occur periodicallyand transfer small fixed-size data portions every time when the USB host asksthe device. They are commonly used by mice and keyboards as primary transportmethod. As bulk and isochronous endpoints are not relevant forour missile launcher, I skip their discussion. An excellent introduction from aprogramming perspective gives the Linux DeviceDrivers book. Below issome output from
lsusb -v providing detailed information about the missilelauncher.
The output is structured and indented like a typical USB device. First, vendorand product ID uniquely identify this USB gadget. These IDs are used by the USBcore to decide which driver to give a device to. Moreover, hotplug scripts candecide which driver to load when a particular device is plugged in. Next, wecan read off the maximum power usage (100 mA) in the configuration section. Thesubordinate interface contains apparently one interrupt IN endpoint (besidesthe control endpoint 0) that can be accessed at address
0x81. Because it isan IN endpoint, it returns status information from the device. To handle theincoming data we first need to understand the missile launcher controlprotocol.
Reverse-Engineering the USB Protocol
The first step involves reverse-engineering (or “snooping”) the USBcommunication protocol spoken by the binary Windows driver. One approach wouldbe to consign the device in a VMware and capture the exchanged data on the hostsystem. But since several tools to analyze USB traffic already exist, the easiersolution is to rely on one of those. The most popular free application appearsto be SnoopyPro. Surprisingly I donot have Windows box at hand, so I had to install the binary driver togetherwith SnoopyPro in a VMware.
In order to capture all relevant USB data and intercept all device controlcommands, the missile launcher has to perform every possible action while beingmonitored: moving the two axes alone and together, shooting, and moving to thelimiting axes boundaries (which will trigger a notification that the axescannot be moved further in one direction). While analyzing the SnoopyProdump, one can easily discover the control commands sentto the missile launcher. As an example, the Figure below shows an 8 bytetransfer buffer. When moving the missile launcher to the right, the bufferholds
0x00000008. Moving the launcher up changes the buffer contents to
0x00000001. It is apparently very easy to deduce the control bytes used tocontrol the missile launcher. Unless a “stop” command (
0x00000000) is sent tothe device, it keeps the state of the last command. This means if the “down”command is issued, the device continues to turn until it receives a newcommand. If it is not possible to move further, the motor keeps up running andthe gears crack with a unbearable painful sound. Upon closer examination, theinterrupt IN endpoint buffer varies depending on the current device position.Whensoever an axis reaches its boundary (and creates the maddening sound), thedevice detects it and changes the interrupt buffer contents accordingly. Thismeans of notification can be leveraged by the kernel developer to implement aboundary checking mechanism sending a stop command as soon as the missilelauncher runs against a wall.
Here is an excerpt of the driver source showing the complete list of controlcommands that can be sent to the device.
The following bytes appear in the buffer of the interrupt IN endpoint (shown ascomment) and indicate that a boundary has been reached.
With all required control information in place, let’s now adopt the programmer’sperspective and delve into the land of kernel programming.
The Device Driver
Writing code for the kernel is an art by itself and I will only touch the tip ofthe iceberg. To get a deeper understanding I recommend the books Linux DeviceDrivers and Understanding the LinuxKernel.
As for many other disciplines the separation of mechanism and policy is afundamental paradigm a programmer should follow. The mechanism provides thecapabilities whereas the policy expresses rules how to use those capabilities.Different environments generally access the hardware in different ways. It ishence imperative to write policy-neutral code: a driver should make thehardware available without imposing constraints.
A nice feature of Linux is the ability to dynamically link object code to therunning kernel. That piece of object code is called a kernel module.Linux distinguishes between three basic device types that a module canimplement:
- Character devices
- Block devices
- Network interfaces
A Character (char) device transfers a stream of bytes from and to theuser process. The module therefore implements system calls such asopen, close, read, write and ioctl.A char device looks like a file, except that file is “seekable” and most devicesoperate sequentially. Examples for char devices are the text console(
/dev/console) and serial ports (
/dev/ttyS0). Most simplehardware devices are driven by char drivers. Discussing block devicesand network interfaces goes beyond the scope of this article, pleaserefer to the specified literature for details.
Besides this classification, other orthogonal ways exist. As an example, USBdevices are implemented as USB modules but can show up as char devices (likeour missile launcher), block devices (USB sticks, say), or network interfaces(a USB Ethernet interface). Let us now look at the rough structure of a USBkernel module and then turn to particularities of the missile launcher.
Apart from some global variables, helper functions, and interrupt handlers,this is already the entire kernel module! But let’s start off step by step. TheUSB driver is represented by a
struct usb_driver containing some functioncallbacks and variables identifying the USB driver. When the module is loadedvia the insmod program, the
__init usb_ml_init(void) function is executedwhich registers the driver with the USB subsystem. When the module is unloaded,
__exit usb_ml_exit(void) is called which deregisters the driver from the USBsubsystem. The
__exit tokens indicate that these functions areonly called at initialization and exit time. Having loaded the module, theprobe and disconnect function callbacks are set up. In the probe functioncallback, which is called when the device is being plugged in, the driverinitializes any local data structures used to manage the USB device. Forexample, it allocates memory for the
struct usb_ml which contains run-timestatus information about the connected device. Here is an excerpt from thebeginning of the function:
You might have noted the use of
goto statements in this code snippet. While
goto statements are generally consideredharmful, kernel programmers, however,employ
goto statements to bundle error handling at a central place,eliminating complex, highly-indented logic. The probe function allocates memoryfor the internal device structure, initializes semaphores and spin-locks, andsets up endpoint information. Somewhat later in the function, the device isbeing registered. The device is now ready to be accessed from user space viasystem calls. I will discuss the simple user-space tool accessing the missilelauncher shortly. Yet before that, I present the communication primitives usedto send data to the device.
The Linux USB implementation uses a USB request block (URB) as “datacarrier” to communicate with USB devices. URBs are like data messages that aresent asynchronously from and to endpoints. Remember that the USB standardincludes four types of endpoints. Likewise, four different types of URBs exist,namely control, interrupt, bulk, and isochronous URBs. Once an URB has beenallocated and initialized by the driver, it is be submitted to the USB corewhich forwards it to the device. If the URB was successfully delivered to theUSB core, a completion handler is executed. Then the USB core returnscontrol to the device driver.
As our missile launcher features two endpoints (endpoint 0 and the interruptendpoint), we have to deal with both control and interrupt URBs. Thereverse-engineered commands are basically packed into an control URB and thensent out to the device. Also, we continuously receive status information fromthe periodic interrupt URBs. For example, to send simple data to the missilelauncher, the function
usb_control_msg is used:
cmd is inserted into the buffer
bufcontaining the data to be sent to the device. If the URB completes successfully,the corresponding handler is executed. It performs nothing fancy, except tellingthe driver that we launched a (yet uncorrected) command via the writesyscall:
We do not want the missile launcher hardware to be damaged by neither sendingimproper commands nor sending any commands when it reached an axis boundary.Ideally, whenever an axis boundary is reached (meaning that the missile launchercannot turn further in one direction), the device should stop the movement inthe particular direction. The completion handler of the interrupt URB turns outto be the right place to implement this idea:
The above code is used to set the
correction_required variable which triggersa “correction” control URB: this URB contains simply the last command withoutthe harming bit. Remember that the URB callback functions run in interruptcontext and thus should not perform any memory allocations, hold semaphores,or cause anything putting the process to sleep. With this automatic correctionmechanism, the missile launcher is shielded from improper use. Again, it doesnot impose policy constraints, it protects only the device.
For most folks fun starts in here. One doesn’t kick the bucket whendereferencing NULL-pointers and the good old libc is available, too. Afterhaving loaded the kernel module, the missile launcher is accessible via
/dev/ml0. A second missile launcher would show up as
/dev/ml1 and so on.Here is a very simple application to control the device:
This tool, let’s name it
ml_control, allows the user to send data to thedevice via the write syscall. For example, the device moves three seconds upand left with
./ml_control -ul -t 3000, shoots with
./ml_control -f, orstop with
./ml_control -s. Consider the code as proof of concept, of coursemore sophisticated applications are imaginable.
Just for fun, I mounted an external iSight camera on top of the missilelauncher. Like the author of pymissile suggests, creating anautomated sentry based on motion detection is a funky next step. Whenever amovement in the current view is detected, the missile launcher shouldautomatically align itself and fire a missile. Due to the lack of time, I couldnot pursue this project. Maybe someday, in the unlikely event of getting bored,I will return to this idea. Nevertheless, my friend Thorsten Röder quicklyhacked together a Qt GUI. It somehow resembles an early version of Quake…
Custom Engineering Spa Usb Devices Driver Download For Windows Xp
In this article, I frame the creation of a USB device driver for the Linuxkernel. At first I reverse-engineer the unknown USB protocol by interceptingall USB traffic to and from the device with the Windows driver. Having capturedthe complete communication primitives, I explain how to build a USB kerneldriver. Finally, a proof-of-conecpt user-space tool is presented that lays thefoundation stone for further fancy ideas. Future work touches topics likeaugmenting the missile launcher with a video camera or mounting it on arbitrarydevices. The code from this article and a full implementation of the devicedriver is available at my github repository.