I'm using a Limited User account under Windows XP, and I'm having a bit of trouble getting my Adaptoid (the most coveted N64 controller -> USB adapter, because of it's support for sending raw N64 controller commands + the fact that it's been discontinued) to work smoothly: as installed, the included software requires Administrator privileges to load the driver.
Presumably, it is possible to arrange for the driver to be loaded automatically when the Adaptoid is inserted by adding some stuff to the INF file for the driver (wishna1.inf):
the question is, what stuff?
(It would also suit me just as well if the driver could be automatically loaded when anything attempted to open \Device\Wish_NA1, or even to have it automatically loaded at every boot, really, but doing it on insertion seems like the right way.)
Note: I do have access to an administrative account, it's just that I prefer not to have to use it day-to-day.
First of all, let's clarify that a USB device has a Plug & Play driver on Windows 2000 and higher, so services start modes are irrelevant. The driver will have an entry as a "service" in the registry, but its start mode is irrelevant here.
Let's split the problem into two parts:
Installing driver for the device: This requires administrative privileges. This happens when you insert a USB device into a port for the first time. Windows goes over your .INF files to find one that matches your hardware. If the driver is WHQL-certified, it'll load automatically. Otherwise, you'd see the dreaded Add New Hardware wizard. If you're running as admin, a few clicks on Next should be enough to install it. Otherwise, better have that Administrator password ready.
Loading the driver for the device: Once the device is installed, the driver will be loaded each time this device is inserted into this USB port without requiring any additional user intervention. Ever noticed how a USB printer, camera or disk drive load much faster the second time you plug it in? That's because that's just loading, without installing.
From looking at the .INF, it looks valid. Also, it's not WHQL-certified, so you'd have to install it manually.
I'm assuming when you insert the Adaptoid, you get an Add New Hardware wizard. If you point it manually to the installation directory, does the Adaptoid install and function? Does it appear in the Device Manager?
P.S. USB devices which have a serial number are an exception. They're installed once for all USB ports. Those devices are rather uncommon, though.
Related
I am trying to create an installer (using Inno Setup) that will pre-install a USB driver for an LCD HMI. I have the drivers from the manufacturer (they appear to be signed). However, no matter what I do, Windows will first detect the driver as a "Gadget Serial v2.4" device, then immediately go to "Windows Update" and downloads a "PNX Bulk Device" driver.
This driver does not work with the HMI. I have to then manually open up Device Manager, find the "PNX Bulk Device", go to "Update Driver Software"..."Browse My Computer", "Have Disk", etc.
This is a very arduous process and may be overwhelming for an inexperienced user.
Is there anyway to automate the process, such that if the package is installed before the USB device is plugged in, then the driver will be in place, and Windows will use the correct driver rather than the Generic ones it is finding?
Note: I have tried the DPInst utility, the SetupCopyOEMInf function and pnputil.exe. All methods "appear" to work (ie: no error messages), but Windows still grabs the generic driver first, no matter what.
I realize my understanding of drivers may be flawed. I'm trying this on a Windows 7 x64 architecture, but I would like it to work universally.
For collecting diagnostic information, I'd like to include which driver will be used for a particular device, even if the device is not connected.
Relevant Driver details would be Provider and Version.
For the device, Vendor ID and Product ID are known.
The driver is preinstalled, but no device of that type may have been connected before.
[edit] The purpose is troubleshooting installation issues. Normally, drivers get preinstalled with the software installation.
However, one 3rd party driver installation is particulary susceptible to get uninstalled due to bad UX that I can't control, and some customers go "creative" when trying to fix something, with some customers the language barrier is too high. I just want support to see reliably "oh, they have an old driver installed, for whatever reason.
I think you should investigate the registry keys in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB. In general, every distinct USB device that was previously plugged into the computer will have an entry there. The entries have a "Driver" entry with a GUID and you can probably figure out what that GUID means by searching for it in other parts of the registry.
If the device has never plugged in, then you would probably want to use Microsoft's devcon utility (which is open source) to list all the installed OEM driver packages (INF files). You can then open the INF files, read them, and see if they might apply to your device.
Our latest WHQL'ed custom driver has an incorrect entry for one of our upcoming product. The upcoming product is composite device and our WHQL'ed driver has an entry which matches the device ID for the composite device instead of the individual interfaces.
When the new device is connected to machines which have the WHQL'ed driver, the device gets binded to our driver and not to Windows Generic Parent Driver (usbccgp.sys). This prevents the interfaces in the device from being listed.
We could manually fix this by uninstalling the driver for the device and making it to bind to usbccgp.sys driver. In Vista and higher versions, we could delete the driver binaries at the time of uninstall. But there is no direct way to completely delete the driver binaries in XP. This makes it very difficult to cleanly uninstall the driver
Can this be fixed using an uninstaller? What is the best way to fix the affected machine in an automated way?
Download the Windows Driver Development Kit (Win DDK) and locate the devcon.exe executable for your architecture. Then, from an elevated command prompt:
devcon.exe find =usb
To list all of your current devices.
devcon.exe -r remove =usb *YOUR_HARDWARE_ID*
Will complete disassociate the device and driver from the target machine. If you have trouble getting the hardware id you can blow away all your USB drivers and let Windows auto-detect them after reboot.
devcon.exe -r remove =usb *
Extreme, yes. Effective, yes. We work with virtual comm ports all day and our test machines often experience your same issue. This technique has yet to fail.
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.
I'm using InstallShield to install my application, a driver and a service.
I need to install the plug-N-play driver only if it's hardware ID was found in the device manager. The driver installation is done using DPInst.exe.
My problem, is that a user can sometimes manually uninstall the driver (After it was installed or even uninstall the "Unknown driver" under "Other devices") and then I can't find the hardware ID in the device tree, although the device is plugged.
If I rescan the device tree during installation using CM_Reenumerate_DevNode_Ex (The code equivalent of "Scan for new hardware"), I can find the hardware ID but this brings up the "Found new hardware wizard".
Is there anyway to rescan the device tree but suppress the "Found new hardware wizard" or to avoid rescanning but still making sure my device hardware ID is present in the system?
I'm writing a new answer since we already have too many comments on my older one, and its content was based on a small misunderstanding of the situation.
The actual problem, as I understand it now, is the "Add new hardware" wizard that pops-up when rescanning for devices, before installing your driver. Unfortunately, this wizard pops-up whenever no suitable driver is found to handle a new device in the system, so in order to overcome it, the only option is to make sure that such a driver exists in the system. This leads to two possible solutions that I can see:
Go for a software first installation, and make sure that your driver is suitable for the device (the inf is well formed, and you have WHQL signing). As far I understand, this is not an option, because you do not want to install the driver on machines that don't have the device connected (I would love to hear why).
Make sure that some other driver in the system is suitable to handle it. In that case you need to choose one of the built-in drivers (one that wouldn't wreak havoc if it were to act as a function driver for your device), and give your device a matching compatible ID - one that would cause the built-in driver to be found suitable. This way you will not have to wait for the user after re-scanning for devices, but depending on your device, finding a fitting built-in driver might be impossible.
It sounds like you're going about it the wrong way. If you have an MSI based installation, why not use DIFxApp instead of DPInst?
As for the "Found new hardware" wizard, you'll need two things here:
Make sure that your inf file is correct (so that your driver is associated with the hardware id)
Get a WHQL signature from MS. This step is needed for XP, as untrusted drivers will not be automatically assigned to devices. With Vista and 7 you can digitally sign the driver yourself, but you'll get a warning during installation, asking the user whether he/she wishes to trust this publisher (you).