Click here to Skip to main content
15,740,826 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
Hi experts,

the installation of my Windows Forms application wreaks havoc on the USB subsystem. Any USB device plugged in the machine won't function unless it has already been plugged into that very USB port at a time before my software was installed.

Has anyone had such behaviour before? And maybe even a solution how to not disturb other vendors' devices?

More detailed description
The application's purpose is to communicate with a device my company sells. Communication is done via a dedicated USB IC from[^]. For the application to be sure to communicate to one of our devices instead of anything that also uses those chips, we have been assigned a separate PID. An adapted ftdibus.inf file reflects this change.

The USB driver files are held in a subdirectory of the installation path (which the user can choose). To make Windows aware of these files, my installer alters the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath. The correct USB driver files path is appended to that key's value. This leaves anything that may have been there untouched. Uninstallation removerts our changes. Since our devices are detected by my application, this seems to work as expected (without the registry change, it does not).

The driver loses its certification due to the changed .inf file. Lack of certification means not to be able to silently install the driver. To save the user a lot of annoying message box clicking, the driver shall not be re-installed every time another one of our devices is plugged in. So there's also a registry entry at HKLM\SYSTEM\CurrentControlSet\Control\UsbFlags\IgnoreHWSerNum1234CDEF

Other than that, I didn't code any registry changes.

USB devices that are already known to the PC in question, and are connected to a USB port that they have already been connected to, keep working.

Plugging a known device into a USB port it has not earlier been connected to result in an "Unknown Device" in Device Manager and the device not working.

Connecting a totally new device to the PC causes its driver to be installed (at least a pop-up from the taskbar tells so) and also shows an "Unknown Device" in Device Manager.

Un-installing the software doesn't restore normal USB behaviour.

All devices that I witnessed refusing to work could be activated by explicitly installing their drivers from within Device Manager.

The problem was observed on Windows XP Prof and Windows 7 64 Prof.

I got two regedit.exe exports from before and after the software installation. The already mentioned DevicePath registry key baffles me:
"DevicePath"="%SystemRoot%\\inf;C:\\Program Files (x86)\\Corporation\\Application Name\\include\\USBDriver"
Using regedit.exe with the nice tree view and edit fields I've never seen this format. Just now in WinMerge.
Updated 26-Feb-14 23:30pm
Jochen Arndt 27-Feb-14 6:00am    
The original registry string is Unicode encoded while the new one is ANSI. So you should check your code that changes the registry.
lukeer 28-Feb-14 5:01am    
Yes, it was a variable type error. My solution has the details.

Thank you very much.
Philippe Mori 27-Feb-14 9:42am    
You should ask the original vendor... since you are using their hardware.

You should never try to go around the system. Windows was designed with some rules and you have to follow them. If changing the PID cause the system to break or the driver to lost certification, them you have to keep the original PID.

Please follows the rules otherwise we don't need your driver.
lukeer 28-Feb-14 5:06am    
In this case, "we" as "the company I work for" are the original vendor. Except you meant the vendor of just the USB IC. Then, yes we asked them. And we were given a range of eight PIDs to use for our products so they won't be confused with other hardware using the same ICs.
Changing the inf file and therefore losing certification is part of that process and to this date no one knows who is going to pay for re-certification, if it ever happens (it's a development for a customer. He says we have to pay, we say it's him).
[no name] 27-Feb-14 17:50pm    
How did you come up with the idea that your approach should be used? As soon as I read what you are doing I switched off because there is no point trying to figure out what is going wrong in your system(s). Even using the correct approach requires plenty of work if you are supporting many OS.

You may find this useful, I did when I needed to do silent install for our USB connected device.

Driver Package Installer (DPInst)[^]

I suggested reading through the documentation though. But it works.

Good luck.
Share this answer
[no name] 27-Feb-14 17:56pm    
Yes with a proper driver and config.sys this is the method I have used for commercial devices. dpinst can be run from installer.
lukeer 28-Feb-14 5:13am    
We checked out DPInst some time ago and decided not to use it. IIRC, it wasn't capable of installing the drivers silently. And customer didn't want its customers to look at two more windows during installation.
[no name] 28-Feb-14 5:29am    
Firstly I am glad you solved your problem. I can't see why the customer was able to override a sound technical decision. What else would they like to get rid of for aesthetic reasons? Dpinst is what MS provides for the task. It will keep up with windows versions. How do you deal with 32 bit and 64 bit systems etc etc. I would be forever nervous about your solution. Do you export and support worldwide for example.
lukeer 28-Feb-14 6:56am    
Rant: What else, you ask? Since I'm not overly fond of every single design decision I, or the hardware development guys, had to implement, I'm risking to resort to language I could regret having used, later. So no rant here, actually.

But 32 vs 64 bit seem to work well, although I have to ease the nervousness by treating possible issues as potential (paid, of course) follow-up work.
Stupid me!

To write my changes to the registry, I use this method
[DllImport("advapi32.dll", SetLastError = true)]
static extern uint RegSetValueEx(
    int hKey,
    String lpValueName,
    int lpReserved,
    Microsoft.Win32.RegistryValueKind dwType,
    IntPtr lpData,
    int cbData
And set dwType, to String. But a freshly installed notebook's registry shows that ExpandString would have been correct. The ExpandString type causes %SystemRoot% to be expanded to the actual path, which is prevented by my accidental change.

The path I added doesn't contain any such variables, therefore works like a charm and passes all our tests. The original entry has to be expanded to work and so I broke it.

Thanks a lot for all your suggestions. That includes the ones I rejected.
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900