PORTS Forum
Ports and Interfaces => USB => Topic started by: NicOfTime on October 01, 2014, 10:00:58 am
-
Hi, Jan.
I get repeated “access denied” (err 5) errors when trying to use WinUSB_Initialize to get a WinUSB handle to a device. It’s possible that I may conflating the terms “device handle” and “device interface handle”. I understand that, in some cases, the device handle and device interface handle may be the same thing – but, as a general rule, is WinUSB always communicating through device interface handles rather than device handles? I can pass a device handle to CreateFile, and it returns “success”. But when I pass the Windows handle from CreateFile to WinUSB_Initialize, I get “access denied”. Is the system denying access because I’m trying to get a WinUSB handle via a device handle (which is valid) instead of a device interface handle (which is not really valid because I haven’t enumerated and passed them to Createfile yet)?
-
WinUSB_Initialize accepts a handle obtained by passing a device interface GUID to CreateFile.
Access denied might be due to the device already being opened by another driver.
What device are you trying to access?
-
Hi, Jan.
Thanks so much for getting back with me.
I have a number of devices that are all supposed to abide by the USB-MIDI standard. Two of them respond as expected using the winmm.dll USB-MIDI API (midiOutGetNumDevs() / midiOutGetDevCapsA / etc). I can find and control these devices programmatically (with the MIDI functions) without a problem.
Some MIDI devices aren’t detected through those functions – the MIDI functions appear to filter out devices that don’t have a MIDI-streaming interface.
Even if they don’t stream MIDI, these devices will still respond to standard MIDI program and control change information through a USB connection – but only if I can get a handle to them. I can talk to them through a hardware USB-MIDI interface (using the round 5-pin DIN connector cables), but those kinds of interfaces are giving way to USB-MIDI (much faster, more versatile interface). The MIDI-specific API is becoming more and more obsolete – this is not been a priority for Microsoft, it hasn’t been updated in over a decade.
Since the MIDI-specific API doesn’t work, I have to take another approach.
I’ve successfully found the devices by feeding a suitable class ID to SetupDiGetClassDevs; I used SetupDiEnumDeviceInterfaces and SetupDiGetDeviceInterfaceDetail to get the device instance ID; I fed the device instance ID to CreateFile to get a Windows handle, then used that Windows handle with WinUSB_Initialize to get a WinUSB handle. And this always fails with “access denied”, even when I know I’m feeding the intended device instance ID into those SetupDi functions.
So I’m guessing that I should be talking to specific interface ID’s in the device, not the device ID itself. With a bit of trial and error, I can find the interface that will execute standard MIDI commands – for some devices, this has been through an interface labeled “AUDIO”. My question had to do with a possible conceptual misunderstanding on my part -- that maybe communication links should be with interfaces rather than devices. (?)
-
WinUsb_Initialize uses the first (default) interface on the device:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff540277%28v=vs.85%29.aspx
So I think the MIDI interface needs to be interface 0.
If the device is already installed using another driver, WinUSB might be unable to access it. In Device Manager, select Driver > Uninstall.