If the UPDD driver cannot access a USB device, the UPDD.log file captured when running a UPDD Diagnostic procedure will show access denied error:
UPDD V6: 2022/09/23-10:44:43: ERR: USB error: (claiming interface) Access denied (insufficient permissions)
UPDD V7: 2022/09/23-12:17:49: ERR: Unable to open interface: exclusive access and device already open(IOReturn = 0xe00002c5)
This can be caused in two ways, either the UPDD System Extension has not been activated or another driver has taken control.
In cases whereby another driver is blocking access, this fault is totally random and intermittent and can occur at any time, even when systems have been working perfectly fine. It can be triggered over a reboot, or when plugging in the device or during an OS upgrade.
System Extension not activated
To access a USB device, the UPDD software has to inform the macOS what USB device(s) it would like to access.
This is required to prevent native macOS drivers trying to handle the device and thus preventing the UPDD driver access to the device.
To register our request for exclusive access to a USB device(s), we install and register a codeless system extension that specifies the USB device we would like to control.
Early versions of UPDD V6 use a kernel extension, whereas recent versions and UPDD V7 use the new System extension.
Since macOS 10.13, these extensions need to be manually 'Allowed' to be activated and during UPDD installation the macOS system will indicate the installation of the extension was blocked and request they are 'Allowed' to be installed, as described here.
If the old kernel extension is not activated, the driver will still try to access the device, but will fail with 'Access denied'.
If the newer system extension is not activated, the driver will stall and wait until it is activated.
Another driver preventing access
In cases whereby the System Extension has been activated, the driver can still be prevented from getting access.
The main cause of this situation seems to be that the macOS HID driver takes control of the device despite our driver being registered as the principle driver for the device.
We have worked very closely with Apple technicians to resolve this issue, and they could not find a reason why this occurs.
However, based on their recommendations, UPDD v7 uses a different USB interface to that used in V6 and this resulted in this error being significantly reduced but unfortunately not totally eradicated.
However, as annoying as this issue is, it can always be resolved by trying the following:
We have investigated a number of these cases and have always managed to find a solution by performing one or other of the steps below:
- If using UPDD V6, try using UPDD v7.
- If you have installed on top of an old V6 driver, we suggest you uninstall, reboot and reinstall. This seems to be the case that gives access denied even though system extension has been activated.
- If you have trouble getting the System extension to show up in the Security & Privacy settings, you can try to uninstall and reinstall - we believe this may also have resolved the issue in a number of systems, especially in systems installing V6 over UPDD V5 utilising a different kext file of the same name.
- Some users have reported rebooting 2 or 3 times and eventually the driver gets access to the device.
- Another driver developer shared this 'work round' with us that apparently works in some cases:
1. Open "System Preferences", "Keyboard", "Shortcuts" tab
2. Set "Full Keyboard Access" to "All controls"
3. Open "System Preferences", "Security & Privacy", "General" tab
4. Press tab key until the "Allow" button is highlighted
5. Press space bar
This is essentially just using the keyboard to allow access. This has worked for us and is the preferential to the other more invasive options.
- Reinstall MacOS - this was undertaken by one customer and the software then installed correctly - extreme solution, but it worked!