What are you trying to do? Read the name of a USB device? Stop a USB device?
Get the list of all USB devices inserted in the system and yes, stop (or eject) any at a user's request. (I know how to eject them, so all I need is to get names.) The code currently uses GetVolumeInformation() to retrieve a USB device name but that method has a flaw when it returns an empty string for some of them.
See the attached project that uses WMI to grab the info. It's a VC2008 project, so you'll have to move the stdafx.h, wmi.h, and wmitest.cpp into an earlier project.
The sample uses a WMI class that I develop here. I extended that class to handle WMI associations.
At any rate, here's the output on my machine with 3 USB drives attached:
Code:
USB Flash Memory
Removable Disk (H:)
Generic Flash Disk
USB DISK (F:)
Lexar USB Flash Drive
Lexar (I:)
Nice! Thank you, Arjay and Igor. Both approaches work. Now I have a new dilemma -- which method to use No, seriously, I like WMI method, it's more elegant, but on the other hand it carries a heavier overhead than Igor's Windows Driver Kit one.
Re: [RESOLVED] Need to get name of a USB flash drive device
WMI is atrociously slow compared to IOCTL. I once tried to use WMI to get various hardware signatures for a machine ID for software protection. This ran before the app would come up and it was so slow what with initializing all the WMI prerequisites and all that we had to abandon it.
Re: [RESOLVED] Need to get name of a USB flash drive device
Yes, as I said, WMI is way too slow but in most cases it is the only way to retrieve some hardware information. My way to use it is to call it once at the app start-up, preferably in a separate thread and cache the results.
In my original question here WMI works perfectly since a small overhead doesn't matter that much.
On the side note, guys, are there lower-level APIs to WMI? Because the stuff you can get with it is amazing.
Re: [RESOLVED] Need to get name of a USB flash drive device
To help speed things up (as you know), you can initialize WMI at app startup and keep the WMI object around.
Also, it seems that some of the WMI info (or infrastructure) is cached. I believe you will find that the first call to getting WMI info (other than initialization) takes longer than subsequent calls.
I believe the performance would be acceptable if you initialized WMI at start up and grabbed the info on demand - say to fill out a context menu. I was actually going to code up a taskbar sample with a context menu, but I got lazy.
Btw, many of what is available with WMI isn't easily obtained by other methods.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.