Is it possible you flipped the two logs you posted? The one you've labeled "18" shows DriverKit attempting to load your DEXT after it had been deleted, which seems incorrect. No, I checked and the logs are named correctly. As you mentioned, in the iPadOS 18 log, the driver is re-loaded and goes through the Start phase again which is not the case if you look at the iPadOS 17 log. Also, I can see Stop getting called only in the 18 log maybe because of this reload. One thing I'd look for here is the I/O registry state of your kernel driver after you uninstall the app and then hot plug the accessory without reinstalling your app. Could you please guide me on what you mean by the kernel driver here? I have already checked the IORegistry to see whether any instances of my driver is still present after a hot plug and I can't seem to find any. Also, it doesn't help if I reinstall the app, enable the driver and hot plug the accessory (still non-functional). Alternatively, what does your driver "do" to your hardware during teardown? In my actual implementation, I stop ongoing transfers if any and close the queues which were created in my Start(). I also suspected whether I was doing something wrong in my Stop() implementation first. However, I later changed my Start and Stop to be minimal (just open the PCI device and enable/disable bus mastering) to verify this. I get the same kind of logs even with this. What happens if you uninstall your app/DEXT while your hardware ISN'T attached? Whenever my hardware gets detached, Stop() is successful without any crashes. Doing an uninstall in this case seems to be of no harm. I went through the IOPCIDevice::ClientCrashed_Impl which is getting called in both the logs here. Below is the code excerpt from the link. kern_return_t IOPCIDevice::ClientCrashed_Impl(IOService *client, uint64_t options) { DLOG(ALWAYS_ON, "IOPCIDevice::ClientCrashed_Impl() for client %s\n", (client) ? client->getName() : "unknown"); // only reset the device if the driver potentially changed the state of the device if(isOpen(client) == true) { DLOG(ALWAYS_ON, "%s: PCIDriverKit client, %s, crashed for device %s[" BDF() "], attempting to recover\n", __PRETTY_FUNCTION__, (client != NULL) ? client->getName() : "unknown", getName(), PCI_ADDRESS_TUPLE(this)); IOReturn ret = parent->childClientCrashRecovery(this); // rdar://122664049 (Remove terminate-on-crash option from PCIDriverKit crash recovery) if (ret == kIOReturnSuccess && getProperty("terminate-on-crash")) { launchReprobeThread(); } } This exact log inside the if-block is getting printed in my case and I suspect whether the childClientCrashRecovery() and launchReprobeThread() functions are actually the ones triggering the reload in the case of 18. I have not got a chance to investigate deeper into this. The only difference between the two logs is the recovery/reprobe mechanism which happens in 18 but fails to do so in 17. Can it be something where the recovery mechanism with launchReprobeThread() was added starting from iPadOS 18 (maybe Driverkit 24) and not present in iPadOS 17 altogether? If this would help, I have another driver for matching some USB3 accessories (USBDriverKit) which seems to follow the same cycle of [Uninstall -> Recovery/Reprobe -> Driver Start/Init -> Driver Stop] but across all versions of iPadOS without any issues.

@DTS Engineer Hi Kevin, Have you verified through the I/O Registry that your DEXT is unloading correctly at uninstall? What does the I/O Registry show after you unplug the device? Yes, I have verified this. When a device is connected and the driver is active, I have my driver instance and IOUserServer instance in the IORegistry. Whenever the device is removed or on uninstallation of the app, I can see that these entries are not present. What does the I/O Registry show when you plug your device back in (and it remains non-functional)? When I plug my device back in (non-functional state), there is no driver instance in the IORegistry. What happens if you plug an entirely different accessory, particularly a very simple configuration like a USB3 adaptor and keyboard? Do they work, and does your accessory return to normal operation after that? I have tried connecting some other USB3 accessory and it seems to function just fine. When I try to connect my USB4 accessory back again, it is still non-functional. Have you looked at the system console at all three transitions? What is it logging? Yes, I looked at the system console during uninstallation. I have attached the logs from both iPadOS 17 (non-functional) and iPadOS 18 (functional). iPadOS 17 console log (non-functional) iPadOS 18 console log (functional) To add, I have also tried having a very minimal implementation in my Start/Stop methods like the one in here. I can see from the logs that IOPCIDevice::ClientCrashed is getting called in both the OS versions. iPadOS 18 recovers and is able to call Stop successfully whereas 17 fails to do so. I open an IOUserClient to the driver during app launch when an accessory gets connected and close it when the accessory is detached. So, I have also tried the below just to verify in iPadOS 17 if IOUserClient being open might be the case: Install app. Do not launch. Go to settings and enable driver. Attach accessory. Driver matched and loaded in IORegistry. Uninstall the app. I can see the same crash from the console even in this case.

Hi Vasim, Please check whether USBDriverKit and BlockStorageDeviceDriverKit match your requirements. For capabilities, you would need this for USB and this for Block Storage. For sample code, there's not much specific to these frameworks, but you can find the generic ones here. DriverKit Sample Code - Apple DriverKit Sample Code - GitHub

In order to really investigate this, we'd need a sysdiagnose from a device experiencing the problem. Sure, I'll make sure to get the sysdiagnose from the device if at all I can reproduce it. Going forward, OSSystemExtensionsWorkspace.systemExtensionsForApplicationWithBundleID will let you query the system to determine your app driver status. Thank you for pointing me to this. I'll check how this API behaves in older versions of iPadOS or probably wait till iPadOS 27 releases just for it to be reliable as you have said. I looked up your app using the details in your bug and, while I didn't see any direct problem, I am concerned that your DEXT version number doesn't really comply with the kernel version criteria described here. I checked the thread and this is my understanding. Currently, both my app and the driver follow this way of versioning: CFBundleVersion - some value between 100-990 (build number) CFBundleShortVersionString - 9.0.0 (The app/driver version) Ideally, should the CFBundleVersion in my case be set to something like 9.0.0.100 then as per the compliance instead of just 100? I guess it works in my case as it will never be 5 digits but for future proofing, I should fix this to something like above. My recommendation is that you build your DEXT independent of your app project, include it as a "static" resource, and only update it when the DEXT actually changes. I'll make sure to version up and build the driver only when there is an actual change instead of every time. Thanks, Abishek.

@DTS Engineer Hi Kevin, The workaround I've long suggested is to include a settings bundle in your app so that your app always has some kind of setting. I have a Settings bundle included in my app already. Also, I believe this setting is provided by the OS itself and having a custom setting in my bundle is not going to help activate the driver. The issue is that the toggle does not appear suddenly in Settings for some users in some versions of iPadOS even in the presence of a Settings bundle and I am unable to figure out why. What's the bug number? FB24167071 (Toggle to enable Driverkit Driver not appearing in App Settings in iPadOS)

@Justin Thank you for replying. I am developing a custom DEXT for sending SCSI vendor commands over USB using the BOT protocol. Earlier, this was possible with a KEXT by having IOSCSIPeripheralDevice nub as the provider class (no exclusive access required). About your suggested solution, even though I can match on the IOUSBHostDevice on the whole, the device has only one interface/IOUSBHostInterface nub and ultimately after setting up the device, I would have to open a session to this interface for sending commands to the bulk endpoint. I suppose this would again lead to the exclusive access issue mentioned above as IOUSBHostInterface::Open call is necessary in this case.

Thanks Quinn for the quick response. The target that I have for my project currently is a command line tool which I am planning to run as a daemon and so I am unable to add the provisioning profile for this. Should I be creating an app project as a wrapper for this so that I can achieve the same as mentioned here for restricted entitlements, [https://developer.apple.com/documentation/xcode/signing-a-daemon-with-a-restricted-entitlement]?)

Facing the same issue where kIOReturnNotSupported is returned as the error definition when trying to send either common or arbitrary SCSI commands to the device using UserSendCDB. Did you have any luck in making this work?