Dext Auto Registration vs. Manual Registration

Question

Created 2w

Replies 3

Boosts 0

Participants 2

I need a bit more support. Per Apple’s guidance, our dext’s hosting app checks to see if the dext is installed, and if it is not installed, it will register the dext. I am going to refer to this as “auto registration.” I have also added a menu option to register the dext, which I am going to call “manual registration.”

The manual registration works. The user is prompted to “Allow” the dext to be loaded, and things proceed normally.

The auto-registration does not work. It produces an error response that is not helpful:

Request did fail with Error 1 (The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.)) Registration failed, unknown error.

They execute the exact same code path – the auto registration calls the menu option’s function that executes from user selection.

When comparing the sysextd logs, they differ starting at “Advancing from validating to validating_by_category.” The manual registration has a trace that reads:
got reply from com.apple.system_extension.driver_extension...

The auto registration does not get this reply.

Attached are the two logs. This is Sonoma 14.7.6, the earliest OS we must support. Any suggestions on what is happening or how to fix it so that auto registration can work?

Validate_by_category failure trace

Validate_by_category success trace

Answered by DTS Engineer in 889745022

Per Apple’s guidance, our DEX’s hosting app checks to see if the DEX is installed, and if it is not installed, it will register the DEX. I am going to refer to this as “auto registration.”

This is a bit of a random "guess", but when are you actually running this check and attempting the install? If you run this code "early enough" (main or pre-main), it's possible that you're basically attempting to register before your app is "visible" to the larger system. What happens if you run this code in applicationDidFinishLaunching or, better yet, a few seconds AFTER that point?

Also, as a side note, if you're actually using "com.MyCompany" in any way (even testing), then I'd strongly recommend you stop. Early in iOS's history, that prefix ended up being used by a whole bunch of apps (basically out of ignorance), to the point that the App Store ended up blocking that prefix to stop the problem. Stay away from that mess and use a valid prefix.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 1

DTS Engineer OP

Apple

2w

Recommended

Per Apple’s guidance, our DEX’s hosting app checks to see if the DEX is installed, and if it is not installed, it will register the DEX. I am going to refer to this as “auto registration.”

This is a bit of a random "guess", but when are you actually running this check and attempting the install? If you run this code "early enough" (main or pre-main), it's possible that you're basically attempting to register before your app is "visible" to the larger system. What happens if you run this code in applicationDidFinishLaunching or, better yet, a few seconds AFTER that point?

Also, as a side note, if you're actually using "com.MyCompany" in any way (even testing), then I'd strongly recommend you stop. Early in iOS's history, that prefix ended up being used by a whole bunch of apps (basically out of ignorance), to the point that the App Store ended up blocking that prefix to stop the problem. Stay away from that mess and use a valid prefix.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 2

DTS Engineer OP

Apple

2w

Two more things to pass along. First off, the sample "Communicating between a DriverKit extension and a client app" shows how DEXT installation works, so I'd suggest embedding your DEXT into that project as an easy way to determine whether the issue is with your app code or something else.

Beyond that, if you've tried my "guesses" and you're still having problems, then please file a bug on this and then post the bug number back in here. In that bug, please include:

A copy of the app you're testing (installing app and embedded DEXT). Note that I won't be running it so I don't care how it's signed (development builds are fine), I just need to be able to see its code signing configuration.
A sysdiagnose of the failure and a list of the times you tested. Make sure the sysdiagnose was taken "recently" (last hour or so) and, most importantly, the machine has NOT been rebooted since the test was done.

Note: To be clear, I don't think this is a bug in the system, this is just the best way to get all the data to me so I can figure out what's wrong.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 3

mcdspkris OP

1w

Sorry - it's been busy.

First - I'm using "proper" reverse-DNS names and Team ID, I just have a habit of scrubbing identifying information when requesting support. (Yes, I see the mistake I made here).

You were right in that it was a timing problem - though the specifics were a bit different. In my "automatic" path, I was querying for the status of the installed dext immediately after sending the request to install the dext. Well, it seems the system cannot work like that. You must wait to receive an answer before posting the next request.

That's thankfully resolved now, and I'm back to moving ahead.

Thanks for the replies!