DriverKit IOUSBHostDevice Open returns kIOReturnNotOpen

Question

Created 2w

Replies 2

Boosts 0

Participants 2

I have a USBDriverKit driver which tries to send vendor-specific DeviceRequests to the IOUSBHostDevice. A few short months ago this worked, and as far as I know, the only change since it last worked is an update to macOS 14.5.

The dext user client calls through to the driver, which wants to do this:

ivars->mDevice->Open()
ivars->mDevice->DeviceRequest()
ivars->mDevice->Close()

the problem is that the call to Open returns 0xe00002cde, which is kIOReturnNotOpen. If I don't call Open, but simply call DeviceRequest, I get the same result, kIOReturnNotOpen, which I would expect.

I'm pretty sure that in macOS 14.4, the call to Open() did not return an error. I haven't seen any system logs that clue me in to why Open() is failing. It would be handy if the error gave me some reason why the device cannot be opened.

Has anyone else seen this? I've searched high and low and I can't find any examples of dexts which actually do anything at all with a USB device.

Answered by DTS Engineer in 790558022

Sorry for the late reply on this, but "kIOReturnNotOpen" is basically "just what you'll get" when "Open" fails in IOUSBHostDevice (other families are different). Currently (could change in the future of course), it's internal implementation is actually just returning true/false and "kIOReturnNotOpen" is the hard coded return for "false".

From our meeting I know that your failure was caused by a collision with another driver and I think that's going to be the most common case you'll actually see. For example, you'd could also fail if you called "Open" while the driver was in the process of terminating but the timing window of that is so small that it's hard to see that happening in real world conditions.

Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

1w

Accepted Answer

Sorry for the late reply on this, but "kIOReturnNotOpen" is basically "just what you'll get" when "Open" fails in IOUSBHostDevice (other families are different). Currently (could change in the future of course), it's internal implementation is actually just returning true/false and "kIOReturnNotOpen" is the hard coded return for "false".

From our meeting I know that your failure was caused by a collision with another driver and I think that's going to be the most common case you'll actually see. For example, you'd could also fail if you called "Open" while the driver was in the process of terminating but the timing window of that is so small that it's hard to see that happening in real world conditions.

Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

ssmith_c OP

1w

Thank you Kevin!

The collision was with IOUSBLib. I would have expected kIOReturnExclusiveAccess but I understand how boolean return values aren't very informative.

For future readers of this issue, if you run IORegistryExplorer (from the Additional Tools for Xcode download), and look for the device you have problems with, you can see an object with a IOUserClientCreator property of the form "pid=1234, The Nasty App".

In a large tree, you can search for the problematic object by name using the search field at the top of the window, select it, then clear the search field, scroll the window to bring the object back into view, and its attached descendants.

0