Device Driver Wizard

[Jermale Kunstler]

Thekey you show in your registry search is for the usbccgp service which is a generic driver from Microsoft that device implementers can use for devices that offer multiple USB class interfaces. There is no use in trying to interface to that generic driver. It is simply a management layer that coordinates the multiple underlying USB class drivers.

The second device in your list is VID_fff&PID_5678 and that is the identifier for the ROF Disk 2.0 product. Seems like an USB stick probably but Windows already claimed that driver and you will not be able to just make VISA use it like that.

And as explained in the other article that Gerd already linked to, you do almost certainly not want to program an USB Raw device in VISA even if you can get the driver installed in VISA. You would need the protocol description of the devie. I guess the Disk 2.0 product would be a mass storage device class, so the protocol (at least the official part) would be documented in some of the many thousand pages of USB protocol documentation from the USB IF. It's a lot of fun to wade through those documents.

And what is your problem? VISA USB Raw drivers are not a very practical option on modern OSes anymore. Since Windows 7, a device driver MUST be signed with a valid certificate in order for Windows to accept it. That also applies to INF driver files for NI-VISA. Since you create those driver files you must sign them with a certificate of your own, which you can buy for a yearly fee from most certificate agencies.

Without that you have to put your Windows system into a special debug mode, otherwise it will simply refuse to load your driver. Putting Windows in debug mode is definitely not something you want to do on a production system nor should you ever try to do that for more than real debugging sessions. It's similar to not only keep your front door unlocked but wide open, while you are gone.

You still haven't explained what you really want to do. If it is a virtual COM port device simply use NI VISA to access the serial port. If it is some proprietary USB device, which it likely is as it uses a Silicon Laboratories USB controller to implement a debugger device such as for JTAG or similar bus, then use its user facing DLL through the LabVIEW Call Library Node. Anything else is a nice experiment into USB bus protocol programming but in the first place a good way to burn up time and effort for nothing.

I found that Silicon Labs calls the dll file of the device, but I don't know how to use it yet, there is another article published.(USB Reset Utility for Silicon Labs .dll), Tried for a long time, still can't get SN.

Now I want to move the compiled application to another PC, using the same OS (Windows 7 x64). I tried to install the generated driver by right clicking the inf file and choosing install. After that I will be asked if I want to install the driver, which I agree. The installation process runs, but at the end, the device is not visible in the device manager.

So I switched back to the development system and uninstall the actual driver. Now I did the same steps as above (right click inf -> install -> ...). Same problem, the device is not visible in the device manager.

The device I want to use is a USB-HID compliant device (as mentioned above with the wizard everything works fine. Only the switch to another computer does not work). By generating the driver with NI VISA Driver Wizard, I get the message:

"Windows Vista/7 Installation:

To apply the contents of this file to a system's settings, right-click this file and choose "Install". If the device was plugged in before this file is installed, the device will need to be removed from the "Unknown Devices" class in the Windows Device Manager."

the solution is very easy. A HID compliant device gets two entries in the device manager. By installing the driver over the device manager, you have to choose the "USB Input Device" not the "HID compliant device" for updating the driver.

It asks for location of the driver. For PC that has never connected to this special usb cable, it requires me to explicitly specify the location of the .inf and .cat files; otherwise, it can't find them and will fail. (For PC that had used the special usb cable before, it automatically finds it alright.)

I wonder what I am missing that causes the "Found New Hardware" wizard unable to automatically find the .inf and .cat files. It looks like the previous step 'Device Driver Installation" wizard had not installed the .inf/.cat file successfully. When I look into the "c:Windows\Inf" folder, I can't see the associated oem or inf file.

What I did find though in my tests, is that in XP DPisnt doesn't actually install the drivers if there isn't hardware to associate it to. Run it with /c and you can see for yourself it fails because no devices match the ID in your INF. Yet if you plug the USB device/cable into your PC first, and just ignore/close the Found New Hardware dialog, NOW install the driver and it will install correctly. At least this is how it worked for me.

I have a PC that up until a couple days ago was working fine. I moved it from one site to another and now when I plug in the USB mouse or keyboard (the same ones that were working previously) XP brings up the New Hardware Wizard. Going through it, the correct keyboard and mouse are identified, but XP can't find the drivers.

I've tried manually searching for the driver (using the Have Disk option) - the first file it's looking for is in the c:\i386 directory, but that installs a generic HID mouse device; the system then runs the hardware wizard for a new "unknown" device.

The system was SP2, I have installed SP3 in hopes that would help, and I've also downloaded and installed the mouse drivers from Dell's site (there are no specific drivers for the keyboard), with no change.

If you have the drivers and utilities disc. Then install all the chipset drivers for this system, once this installation is complete, restart the system and connect the keyboard and mouse and check the functionality.

This happens when you connect one USB device to a different USB port on your machine. If you want, you can try to plug the keyboard and mouse into their original USB ports which would bypass all of this mess.

Is there a way to turn off the Found New Hardware Wizard, so that Windows will just automatically search its driver cache for good drivers when a hardware device is inserted, without asking for user input?

I am getting the Found New Hardware Wizard whenever I plug anything in that wasn't plugged in during the Setup. This is bad, because I'm switching keyboards and mice around and then I can't click Next!

If I could turn it OFF and have Windows just search, it would find what it wants. If I click Next on the wizard, then it finds what it wants and installs it automatically (without warning about the driver signing, because the drivers are signed).

At this very moment, I've re-slipstreamed BTS DPs via Method 1, and am installing Windows with that. It does appear that BOTH nLite and BTS DPs will cause this problem, though, which sucks, because I really wanted to use BTS DPs.

Anyawy, this same annoying "feature" has now appeared in my setup as well. Right now I'm pretty clueless as to what exactly causes it and I haven't had too much time to troubleshoot it yet. I'm using the nLite 1.0 b5 to import RyanVM's 1.2.2 Full hotfix pack and 10-15 other hotfixes which are not included in the pack. Also to remove some stuff (not too much) from and tweak the setup. This worked fine at first, but evidently I did something somewhere to invoke this behaviour...

The Wizard first pops up to install some SoundBlaster-related drivers during when RunOnceEx is installing software. I might even be able to live with that since it doesn't really interfere and can be ignored, but where it gets particularly annoying is when it pops up for anything that wasn't plugged in during the installation -- even hard drives. First it asks to install drivers for the newly attached HD itself and then once for every partition that is found from the drive. This is clearly not acceptable.

I don't want to disable the wizard since that would probably just leave all new-found hardware driverless, just find how to restore its original behaviour. Gotta continue the tests when I get off work later...

Yesterday I did 1-3. in one sitting, although only imported the RyanVM's pack and not the other hotfixes and closed nLite. Then again added SATA drivers and $OEM$ dirs and made the ISO with nLite. This time there was no Wizard. Now I just need to try to import the rest of the hotfixes and see what happens...

How to get this working on Windows 10 x64? I have the same problem as mentioned above in that the CC2540 dongle shows up in device manager with no driver installed and is therefore not showing up in the Packet Sniffer. The dongle is untouched as received from TI, which I understand should mean that its flashed with the packet sniffer firmware by default.

My situation is similar to one described by the guys above, but with some difference: when I first installed SmartRF Studio + Packet Sniffer + SmartRF Flash Programmer, everything worked just fine: I was able to use cc2540 dongle with sniffer, read and write firmware from/to cc2540 chips through SmartRF05EB.

Yesterday I tried to read the firmware from cc2531 chip and found out that now neither Packet Sniffer nor Flash Programmer nor Studio don't see any of the chips! It seems that the main big thing that happened in between is the automatic Win 10 upgrade to ver 1703 (build 15063.413 as it says now; don't remember, which one was before). It's x64.

3a8082e126