Kevin, thank you again for your help (which both clarified this proper sequence here and in the other thread). The key for any others who may come to this thread later: (1) the sequence for IOUserSCSIParallelInterfaceController is different than for other DriverKit drivers, because it implements a lot of functionality on top of what other device drivers (eg raw PCI) would implement (2) the kernel uses Info.plist properties of the DEXT along with what's in the binary to decide what methods to call in what sequence - if these are not exactly right, you may get strange calls during the initialization sequence, and MacOS itself may get confused and panic or otherwise malfunction Yes, we need to file the bug re: "the open-source release does not include IOUserSCSIParallelInterfaceController (and please, do file a bug asking for us to open source it), IOSCSIParallelInterfaceController is the base class for IOUserSCSIParallelInterfaceController" and have others ask for the same, as it would save a lot of time.

Thank you so much for your help. This has gotten us over the problem (to other problems, but better ones). To recap: our IOUserSCSIParallelInterfaceController DEXT was matching, loading and getting its init() method called but then hit this assert - DriverKit assert failure - .driver.dext) Assertion failed: (notsync || !remote || (msgid == IOService_Start_ID) || queue->OnQueue()), function Invoke, file uioserver.cpp, line 1654. - sorry, I haven't had a chance to get the stacktrace you asked for yet it appears that the assert fails because the kernel was unhappy trying to dispatch a SetPowerState call to the wrong or no queue, before the driver was fully initiated This led to a lot of questions and debugging about initialization, queues and C++ inheritance. as my guess is that your IOKitPersonalities dictionary is actually telling the kernel to do something you didn't really want it to do. My physic guess would be this But instead, your answer here was exactly the problem! The IOKitPersonalities were wrong, which apparently (but not obviously to a new user) controls was methods the kernel tries to call in the driver. I mean, it makes sense in retrospect but it's trifficult as you say. For SCSI, it needs to be CFBundleIdentifierKernel: com.apple.iokit.IOSCSIParallelFamily IOClass: IOUserSCSIParallelInterfaceController IOProviderClass: IOPCIDevice IOUserClass: [ourclassname] We had: IOClass: IOService IOProviderClass: IOPCIDevice IOUserClass: [ourclassname] so missing the CFBundleIdentifierKernel and the wrong IOClass. Such a silly thing really, esp. since it tells you exactly what to put in there at the very start of IOUserSCSI documentation... but as a mitigating circumstances: 1. most of the examples out there are about the stripped down examples (like the PEX8733), not the SCSI case 2. the DEXT did match and start running, so it was easy to think that all of the .plist issues were solved 3. it would've been easier to figure out if the kernel (or Xcode) provided some validation of the C++ vtables to the .plist declarations - it never occurred to me to. There was an erroneous bias towards looking at the .iig and C++ code, I think, rather than the property files... Hopefully some of this is helpful to others in the future. Anyway, thanks again for your help. I'm sure there will be more questions with the next set of problems.

Thank you very much for your thoughtful response. Start by using IOService as your provider, NOT the SCSI stack. In my experience, it's MUCH easier to try to figure out why a DEXT that worked broke than it is to figure out "why it just doesn't work". Yes, rapidly learning that. Tried something part way towards that - but not all the way down to IOService as the base class, can try that next. One thing to emphasize is that if we do not attempt to override init(), absolutely no DEXT methods get called before that assert fail. This sounds a bit like this panic. Indeed, was very excited to find that one before posting here! But alas, it doesn't seem to be the same sequence of events: it's immediate, not a timeout and in the simplest case we haven't had a chance to run UserInitializeController() (or any other code) yet? Are any declarations of queues in the header matter or is it only about the initialization code? Watch "Modernize PCI and SCSI drivers with DriverKit" and make sure you create exactly the same queues in exactly the same places. Have watched it but will again, surely it must be something embarrassingly simple. (As an aside, wish the source code in that video was available). Thanks again.

The title should obviously be Our driver DEXT fails due to DriverKit attempting to call SetPowerState()