USB driver installation breaks other driver's functionality

Question

5.00/5 (2 votes)

See more:

, +

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 http://www.ftdichip.com/[^]. 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.

Effects
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.

[Edit]
I got two regedit.exe exports from before and after the software installation. The already mentioned DevicePath registry key baffles me:

before:
"DevicePath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
  00,74,00,25,00,5c,00,69,00,6e,00,66,00,00,00
after:
"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.
[/Edit]

Posted 26-Feb-14 3:58am

lukeer

Updated 26-Feb-14 23:30pm

v2

Add a Solution

Comments

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.

lukeer 28-Feb-14 5:11am

Our research resulted in this approach.
What would be the correct approach from your point of view?

Nelek 28-Feb-14 5:36am

+5 for a well asked question

lukeer 28-Feb-14 6:26am

Thank you. I appreciate your appreciation.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

S Houghtelin · Answer 1 · 2014-02-27T09:26:00

Solution 1

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.

Posted 27-Feb-14 9:26am

S Houghtelin

Comments

[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.

lukeer · Answer 2 · 2014-02-27T22:58:00

Stupid me!

To write my changes to the registry, I use this method

C#

[DllImport("advapi32.dll", SetLastError = true)]
static extern uint RegSetValueEx(
    int hKey,
    [MarshalAs(UnmanagedType.LPStr)]
    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.