I ran into a problem when using Silicon Labs' CP2102 USB-UART bridge controller. Silicon Labs offers an application for changing USB related configuration values (PID,VID,Device Description...) so I changed the VID value to the ones assigned to me by the USB-IF Administration. All fields appear to have been correctly updated (I ca see that in Device Manager) but Windows reports that there are no drivers available. Before changing the VID/PID and device description everything worked well.
Any idea how to tell Windows to use the same drivers as before? Is it possible or perhaps even normal for a driver to be tied to a specific VID/PID and by changing it I basically "broke" the controller unless I write my own drivers?
OS: Windows 7
USB-UART Controller: Silicon Labs CP2102
More information about the controller: http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-uart-bridge.aspx
Thank you in advance for all your help.
Take a look at the Driver Customization Wizard (AN220SW). If you create a driver with a matching VID and PID as your customized device you can get it to load again (as well as re-customize back to default, or something else). The documentation for this is in Application Note 220.
Related
I've been asked to help with some problems that a company are having with an Windows installer they have that includes some custom driver installation for some hardware they make.
I've got access to the source code to build the software and installer (which is an WIX/MSI one), but don't have access to the hardware, so can't actually test it properly.
Is it possible (either with a toolkit, or without) to trick windows into thinking that a specific device USB device has been attached to the computer in order to trigger Windows into trying to install the drivers? . I've got access to all the Vendoer Id, DeviceID, etc information.
Thanks
Tom
That should be possible. Take a look at WDK USBSamp and NDIS Virtual miniport (or virtual serial driver) samples. The first one is a USB driver sample and second one demonstrates how to build virtual driver. You should be able to combine the two to create a virtual USB driver.
I need to create an automated process in which a script detects the graphics card type on first boot, then installs the appropriate drivers, which will be included in the image, before performing the next steps. The target platform is Win XP Pro.
I came across some WMI code which can get hardware information but since it uses a PNPSignedDriver class I would presume that it requires drivers to be installed before it can detect the device.
I can't use devcon, as it isn't redistributable. Am I right in assuming that WMI cannot help me here, and if so what are my other options?
Thanks,
Bill.
WMI does seem to be the way to do this, as found here. I will confirm after testing.
EDIT - Not sure if this is possible, WMI can only get the name of the display adapter not the device ID of the card, and before the drivers are installed this is something generic like "Video Controller (VGA)". I will update this page if I find a way.
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 maintain an NDIS 6.0 native WiFi driver. One of my missions is passing a WHQL test. To that end I installed version 1.6 of the Windows Logo Kit. I also installed my driver on a a Windows 7, 32-bit test machine. The device appears in the device manager and works correctly.
As a first step I tried to pass the stand-alone NDIS test. However when I run ndistest.exe, the device does not appear in the list of devices. The following screenshot demonstrates the problem:
My device should have appeared in the 'Support Devices' list, or in the 'Test Device' drop box, but it fails to appear in either.
Can someone point out what may cause a device to not appear in these lists?
Thanks!
Well apparently we forgot to implement a couple of obligatory OIDs. If you encounter this problem, make sure that you implement all required OIDs.
I am writing a UMDF sensor driver for a device that connects to the system via Bluetooth and is accessible as an HID input device. I saw the "Sensor Development Kit" sample driver and noticed that it works with the Freescale hardware via HID also though it connects to the system via USB. Is there any difference in the way the UMDF driver communicates with the device in case it connects to the system via Bluetooth? For some reason, I find that the call to CreateWdfFile returns ERROR_INVALID_FUNCTION even when I have the device paired with the system. I am able to access the device directly via HID just fine.
In the INF for the driver I have specified the hardware ID like so - HID\VID_1234&PID_5678 (haven't used the actual IDs here). Is this sufficient for the UMDF framework to determine which driver it should use further down the stack? Or is there something else that one needs to do?
I managed to resolve this one myself. Turns out I wasn't using the correct hardware ID. On a whim I looked up what hardware IDs the bluetooth device had been registered with under HKLM\SYSTEM\CurrentControlSet\Enum\HID and used another ID that had been given there and voila! - IWDFDevice::CreateWdfFile worked! :) And sure enough, this is described quite clearly on MSDN here. So, all's good!