Crashed on both of my AppleTVs this morning too. Finally found it in the AppleTV+ app as an event. Hope that the Platform State of the Union streams, that's not public so it's probably not going to be in the public app.

The number one thing that you need to make sure you do, no matter which approach you take, is to return a result BEFORE the deadline value in the es message. If you do not, the kernel WILL kill your process. So, if you block waiting for another thread/process to make a decision, make sure you have a way to return a result to the kernel if your processing takes longer than expected.

This sounded really familiar. I asked the same thing 2 years ago on this thread. Code 2

I submitted this basic concept as an enhancement request 3.5 years ago (FB7613675 March 4, 2020), still shows as open.

I had the same question almost 3 years ago. I was relying on the PID to determine which process started when. But I got this response that cleared this up. I validated this by logging a message at startup in my Endpoint Security extension and in our launchd process. Even though the launchd process had a much lower PID, the system extension logged its message first. HTH Here is the response from DTS: Engineering has provided the following information regarding this issue: We believe this is a misunderstanding of how PIDs get assigned to new processes - this happens at fork(2) time, not execve(2)/posix_spawn(2) time. The early boot mechanism holds up new images from completing the exec, but the original process (e.g. commonly launchd/loginwindow at startup) has already forked a new process. A lower PID number does not mean that a new image has begun executing. The interesting test case to perform here is to execute non-platform code as early as possible during system startup, before your ES client makes its first subscription. What you should see is that process being held up until either the ES client subscribes to some set of events, or the early boot timeout is reached and EndpointSecurity begins allowing non-platform binaries to continue executing. (tip: this is more easily done by running some non-platform command line binary from Terminal.app rather than launching some non-platform GUI app.) This was retested on 10.15.4 and 10.15.5. No issues were encountered and non-platform execs were successfully held until all early boot clients connected and made their first subscriptions (or timeout was reached).

Well, if you have a kernel driver or ES system extension, you could watch for someone reading your plist and deny it.

Mine is working fine on an M1 Mini. I did have to turn Full Disk Access back on after the last install after updating, but other than that, it's working as expected. I know that doesn't help you a lot, but it doesn't seem to be a regression.

The first thing I'd check is to see if the local drive is mounted with noatime set, and the pen drive doesn't have it set. It might have nothing to do with your system extension.

You will need to use an MDM system that has a profile automatically allowing the system extension.

Couldn't you just run systemextensionsctl list | grep <your extension name> in an NSTask and parse the output, if any?

This link says that it's OK now, yesterday there was a problem https://developer.apple.com/system-status/

Monterey beta 6 is behaving like Big Sur and is working. All is good in (my) the world. Thank you again, Quinn, for letting us know to test it again.

This is the same approach I used to use for debugging KEXTs, and for the same reason: Interactive debugging of low-level system components is, at best, deeply unpleasant and, in the worst case, completely infeasible. Deeply unpleasant. Quinn, you are a master of understatement :)

I see the same error from systemextensionsctl afterwards too. I filed a FB ticket for that, FB9163360. Keep updating it after each beta when it happens again. I think in beta 1 and 2 (maybe just 1?) that it literally crashed after logging that. That's when I created the ticket.