How can i programmatically eject USB Device even if it is in use?
Scenarios:
USB device attached to the system.
We get WM_DEVICECHANGE message by "RegisterDeviceNotification" through which we can handle events like DBT_DEVICEARRIVAL, DBT_DEVICEQUERYREMOVE etc.
Now if the device is in use, if we want to eject it from explorer, it prompts as "Problem Ejecting USB Mass Storage Device "This device is currently in use. Close any programs or windows that might be using the device, and then try again."
Question: 1: How can we eject USB without any prompt while it is in use?
Question: 2: How can we get notification when the user press eject from explorer for USB device ?
Thanks in advance :)
Well, you can't mechanically eject it. So what does it mean to software-eject it? It means that Windows will prevent any further handles to be created for files or directories. As a result, it's safe to remove the USB stick afterwards
Now what does it mean that the USB stick is in use? That just means there are open handles. It doesn't make a difference whether you prevent any further handles from being created. Removing a USB stick while there's a handle open means that you risk corrupting the content on the USB stick.
Therefore, it's not a matter of wanting to ejecting the USB stick while in use. The question simply makes no sense at all.
Note that Windows already tells you what you should in fact do: Close any programs or windows that might be using the device, and then try again.
Question two similarly does not make a lot of sense either. When disk F: is gone, why should you care about the details? After all, if you had reasons to care (e.g. open file), Windows would have blocked that operation.
Related
I want to ditch Razer Synapse because it eats up to 600MB of RAM for nothing. I just want to use my macros for two additional keys found on my Razer Deathadder. I've sucessfully captured the HID packets for my Corsair K95 keyboard with C++ HID API and executed my macros, finally was able to say bye bye to iCUE. But I'm not able to open mouse as HID device. Everything should be configured properly, VID/PID, UsagePage and Usage too. But the interesting thing is that wireshark is able to capture the mouse, for me it doesn't for even when I try to open it with admin priveliges. Does somebody have any idea what I should do?
I've tried hidapitester application which is part of HIDAPI C++ library, it automatically closes the device and doesn't receive anything. If it's not possible to solve it in this way, which approach I should use to be able to capture the packets?
Thank you.
Is it possible to make a program auto run (execute) when the USB it is stored on is plugged into a computer
I don't think this is possible due to the searching I have looked at on the Internet and also the security risk such coding would have
E.g. I have a simple countdown timer (10 to 1) programmed in C++ (complied on windows), when the USB (which the .exe file is stored on) is plugged into a computer the timer will start without me executing it manually.
You can create an Autorun.inf file and place it on the USB drive. Windows will read this file when the drive is connected. In the file you can specify the name of the program you'd like to run, as well as icons, etc.
You cannot force the program to run when the USB drive is inserted. That's up to the security policy of the operating system, and most will at least prompt the user "Do you want to run 'Setup.exe' from this drive?" or something like that.
By default it's not possible, since Windows puts users in control of their computers as much as possible—if they don't want autorun enabled, it will not be possible to have a program executed automatically.
You could write a helper program that runs in the background (possibly as a service) that sleeps most of the time, waiting for a USB device to be plugged in. There might be a way to receive notifications of this, or you might just have to poll it periodically, I don't know. Once it detects a USB device, it can then of course do whatever it wants (CreateProcess etc.).
Since Windows 7, the autorun.inf file is ignored when it comes to USB devices. U3 technology allows a thumb drive to be treated as a CD/DVD which might be a possible solution.
I think you can do so using system(), if you are familiar with disktype command in cmd, then I think you can figure things out. All what you can do in command prompt you can also do in c++ using system(). But it will consume alot of memory space
I'm trying to write an application that will take specific action when it detects an overcurrent condition on any USB port.
However, my googlefu is not able to come up with anything useful (though I can now tell you 101 ways to fix a USB overcurrent problem).
Is there are standard windows API to retrieve USB status info?
If not is there another/better way to detect USB overcurrent conditions programatically?
As far as I can see here http://msdn.microsoft.com/en-us/library/ff539687 you need to turn to the WDK (Window Driver Kit).
I have a piece of code to check the removable drives connected to the computer. But I have to check when the drive is available or inserted into the USB port.Should I write a while loop constantly checking for the drive with certain ID to become available? If I make it into a windows service, do I have to do the same i.e keep looping until the device is found?
Create a hidden window and use it to listen for WM_DEVICECHANGE messages.
Whatever you do, don't poll. That's horribly wasteful and inefficient.
You could use WMI (from C++ this will mean using WMI's COM API): creation events for the Win32_LogicalDisk class.
I am working with USB device on Windows that is seen as a virtual serial port. I can communicate with the device using CreateFile and ReadFile functions, but in some cases my application does not call CloseHandle (when my application in development crashes). After that all calls to CreateFile fail (ERROR_ACCESS_DENIED), and the only solution is to log in to my computer again. Is there any way to force closing the open handle (or reopening) programmatically?
This is certainly not normal. Windows automatically closes any handles that are left open after the process terminates. This must be a flaw in your USB device driver, although it is hard to see how it could mess this up. The ones that emulate serial ports are however notoriously lousy. Well, nothing much you can do but hope for a driver update from the manufacturer. Or a device from another manufacturer.
I agree with both previous posts.
This is not a normal situation.
Unplugging the USB device usually helps.
This problem is related to the glitches in the FTDI driver, which is responsible for implementing a virtual COM port.
On the other hand those "glitches" are related to various malfunctions of the USB devices. (Of course this doesn't justify the FTDI driver).
BTW there're several other known problems with some FTDI drivers:
Sometimes call to CloseHandle just hangs the calling thread.
Sometimes also the application is still "visible" in the task manager, even after it's closed. Task manager can't terminate the application, and the debugger can't be attached to it. Its EXE file is locked (can't be erased).
Usually unplugging the USB device immediately helps in those situations. The FTDI driver, which seems to be "waiting for something" awakes.
Is there any possibility that some threads or child processes of your crashed program are still running and holding a copy of the file handle? Perhaps a debugger process is still open? If so, those might be keeping the device open. I'd check Task Manager just to be sure; if so, force-killing the leftover processes might fix the problem.
One other thing that you don't want to happen is to have an open usb serial port and the user pull the usb to serial adapter. That bug has (is?) been around for a long time. Here was an answer to the bug
"Posted by Microsoft on 3/27/2009 at 4:03 PM
Hi,
Thank you for reporting this issue. We are aware of this problem and have fixed
it for the next major release of the .NET framework.
If you have any concerns, please reactivate this issue and I'll respond asap.
Thanks,
Kim Hamilton
Base Class Libraries"
Don't know if the problems are related. Microsoft Connect has more than a few USB Serial bugs reported.
Maybe you can add a Try catch close around your main code, and call CloseHandle in the catch close. Then even if the program craches, CloseHandle will be called.
try
{
HANDLE hPort = NULL;
hPort = CreateFile(...);
// You code...
}
catch (...)
{
if (hPort != NULL)
CloseHandle(hPort);
}
Try unplugging the device and plugging it back in. Sometimes Windows needs to be reminded that nobody's connected to that port anymore.