I'm using win7-64bit
I am in the process of developing a user interface for a USB CDC device (used as a flash programmer) I am adding in exception handlers and constantly testing, but whenever something does go wrong and the program crashes, the USB device disappears from device manager and will not reconnect. I uninstall and reinstall the driver (which I have made automatic in the c# GUI) but this doesn't fix it either. Nor does resetting the computer, changing USB ports, etc.. The only way I know to fix it is to delete the registry entries for the specific PID / VID stuff and then unplug the USB and plug it back in. Windows the reinstalls it (because it still has the inf file) and it works perfectly. This shouldn't be an issue in the release version, but for testing it has been a real problem constantly going through that process.
My question is why is this happening?
Related
It may seems to be an unusual question at first but let me explain what I try to do.
I've developed a program which is able to hook into a 3rd party program called PS4 Remote Play. The PS4 Remote Play program only allows you to use a real Dualshock gamepad for controlling your games.
So my program is hooking into low level APIs from Windows (kernel32.dll, hid.dll) to bypass this limitation. What my hooks are doing is whenever CreateFileW is called for an HID device my program returns a custom dummy pointer and the corresponding hooked hid.dll methods which are called afterwards are acting like this dummy pointer is a Dualshock gamepad.
So far so good. But recently I got some reports from users of my program that the "emulated" Dualshock is not working and the inputs send to this virtual Duashock are not processed. It took me some time to figure out why. Whenever a user is using a laptop or a PC without an HID device connected, the PS4 Remote Play program never calls the CreateFileW, at least not for creating an HID handle.
I don't want to install a dummy driver with my application for just making Windows think an HID device is connected. Instead I try to hook into the functions of setupapi.dll and only make the PS4 Remote Play program think a random dummy HID device is connected so that it calls the CreateFileW method. I'm already hooked into
SetupDiGetClassDevs
SetupDiEnumDeviceInfo
SetupDiGetDeviceInterfaceDetail
But I have no experience with this API so I have a few questions.
Does the device information set returned by SetupDiGetClassDevs always contain a device information element for HID devices even when no HID device is connected? If not, how can I add a fake device information for HID devices or how can I create a fake device information set in C# and return that instead? Or is this not needed at all, as I can just hook into the other two methods and do something there.
Any advice or hint how I could solve this issue would be great. It is not necessary that Windows think an HID device is connected only the 3rd Party program should act like there is one connected to the PC.
The situation:
We have a software suite that interacts with a device we built in-house. The device uses WinUSB for communications, EXCEPT when in boot mode during firmware updates. When in boot mode, the device uses a different VendorID and ProductID and uses HID for communication.
The problem:
To update firmware, we send a command across and tell the device to enter boot mode. The device re-enumerates with the new VID and PID. When updating firmware on a new machine that hasn't had a device in boot mode connected before, Windows does the "installing driver" dance when the bootloader shows up. (There's no driver to be installed). Software gets a DEVICE ATTACHED event, and so we begin the firmware update. Once Windows finishes "installing" the driver, it de-enumerates and re-enumerates the device, closing our file handle in the middle of the update.
The question:
Is there a way to detect if Windows is installing a driver so that we can wait for the device to be re-enumerated before beginning the update process? Is there something we can do in our install to preempt this behavior? Maybe a way to tell Windows that we don't want to allow driver installation while we're connected to the device?
Maybe a way to tell Windows that we don't want to allow driver installation while we're connected to the device?
Microsoft's Developer Network has a section for Hardware Development. They have an article specifically about this issue. Importantly, the document states that your device installation application should "determine whether other installation activities are in progress before performing its installations" (emphasis mine) and - if pending installations are found - "should exit".
This last part of the statement seems to indicate Microsoft gives precedence to already installing or pending device application installations.
If your problem statement is accurate:
When updating firmware on a new machine that hasn't had a device in boot mode connected before, Windows does the "installing driver" dance when the bootloader shows up.
It sounds like you may be out of luck - or breaking a convention - by attempting to preempt the driver installation behavior.
I would utilize the above mentioned CMP_WaitNoPendingInstallEvents function, and then firmware update your device. I think the VID/PID are irrelevant, here, depending upon where your firmware update code is running. It looks like the OSR Online Forum has a question of the same nature and assumes the same precedence (driver installation).
I am creating a Xamarin android application. Most time consuming is build deployment which everyone known.
I tried to send signed APK via Bluetooth from my development machine to device. It gets successfully deployed, but instantly closes after start.
Have anyone tried this way and is there problem testing in device by copying APK?
You can definitely send the signed APK file (as produced by the build process) via Bluetooth, email or even USB, but it's not likely to offer an improvement on speed.
I do this sometimes when I work from home, as I can't easily connect a device to my work PC (which I'm accessing over a VPN).
If your application is crashing on load when you do that, you've almost certainly got a bug in the application that is causing it.
I'm using a Neurosky Mindwave headset to interface with the "HelloEEG" demo program that came in the ThinkGear .NET SDK for Visual Studio.
connector.ConnectScan(); identifies COM3 as the port with the Bluetooth device plugged in, but it won't recognize the device. I wasn't sure if it was a timeout issue (which I read in other questions), so I have it in a loop until it gets any input. Judging by it still scanning after 5 minutes, I would think timing out is not the issue.
Also of note: I have installed everything that came with the headset, but the Bluetooth device still doesn't show up in My Computer.
Could this be a driver problem?
You should see Mindwave in your device manager (in COM Ports) as MindWave USB Adapter. If not, it is problem with driver I think. If you are using windows 8 system the MindWave USB Adapter is often overwriting to CH340. Look at this: Neurosky.
You should also remeber to pair USB adapter with headset in MindWave Manager.
Best regards,
Paweł
I need to connect and disconnect USB programmatically. That is, I have inserted the USB device. I need to transfer the file using C#, .NET application. The application will watch the particular folder and transfer the file from that folder to a USB drive. I need to disconnect the USB device after the file is transfered and connect the USB when needed - without unplug and replug.
What would be some code to do it or is there any DLL file available?
Main thing: NOTE, NOTE: Without unplugging and replugging the USB device.
If your goal is to make a certain disk volume unavailable while you're not using it, a more sensible approach might be to use the volume management APIs, e.g. by using the IOCTL_VOLUME_OFFLINE control code. (I'm assuming that you know which drive letter belongs to your USB disk.)
Alternatively, you can disable and enable the volume device programmatically with the CfgMgr / SetupAPI -- the same as right-clicking the volume in Device Manager and choosing Disable would do. (For information about using SetupAPI, please review the DevCon sample code provided with the Windows WDK, and see MSDN for functions such as SetupDiChangeState.)
The latter option might require a privileged user account.
I'm not exactly sure, but it can be done. In Linux, I've experienced certain situations where power is disconnected to a device programmatically. The kernel usually does this if the connected USB device is exhibiting too many errors. So, it should be possible to do this even in Windows. You may need to write your own external DLL to do it though.