It's hard to tell, since it works properly at least 80% of the time... Next times it happens, I'll try getting it to think it's a fresh install.

Huh, we have this happen a lot. I'll get a sysdiagnose and file a feedback.

It happened to someone again, and I had them unload all of the daemons and the agent, and clean up /Applications and the application support directory, and then re-install. Same behaviour. It did install the right version, according to systemextensionctl list.

An update: the user did a manual install (opening the pkg file) while it was in this state, and things worked properly after this. I'm going to see if that is reproducible.

Ideally I'd put this in one of the daemons, so that monitoring won't be a problem. I am not currently using kMDQueryWantsUpdates... but can I? That is, will it keep working forever?

I couldn't get NSMetadataQuery to work outside of a GUI context, while the C api did. So... This is helpful thank you!

We've now gotten to the point where we can get it to reproduce -- not on demand, but within an hour or two. This involves opening up a thousand web pages (yay osascript), closing the windows, and then installing another version. Upgrade or downgrade doesn't seem to matter. The extension gets loaded, and starts, but nothing can communicate with it via XPC. Doing the install again fixes it. I am going to add explicit "install extension" and "uninstall extension" menu actions to the containing app, to see if that also does it (I suspect it will). I still have absolutely no idea what is going on here. I'm also pretty annoyed that the invalidation handler doesn't get called for a surprisingly long period.

I can fix the issue by unloading the extension (which requires user interaction), and then reloading the extension (which requires more user interaction). This is not really acceptable, of course. I have no idea what is causing it :(.

Well, duh, because I didn't read enough: Complete path to the file. This value of this attribute can be retrieved, but can't be used in a query or to sort search results..

How can I get the system to not run it on login as part of the transparent application lifecycle feature? (This particular issue, btw, may end up being a single person's machine. Since they have installed & deleted & upgraded the app more than even I have, I suspect there's some crumbs left over.) It's a LaunchAgent because it needs to be run for every user, on login. I initially had the agent invoke the containing app if necessary, but then I realized it was simply duplicating a lot of code and behaviour, and I could simply embed the network extension in the agent. The only problem I've run into so far has been with fast user switching and the system weirdly trying to reload the extension.

I’m not sure you can. This is meant to be under the control of the user. For example, if the user chooses Apple > Restart, the confirmation alert has a “Reopen windows when logging back in” checkbox. I really thought I remembered a way to opt out -- but I thought that was part of AppDelegate and I can't find anything there. (I thought it was something like appShouldRestoreState. that you create a dedicated agent instead of running your main app as an agent. The only thing the applet does is load and monitor the extension (oh, it also shows some state information, I guess). So given that it would have to always launch a containing app, which would then need to be a faceless app on its own, and which would need to be relaunched if/when it crashed or was killed, that didn't seem too feasible. Especially since we still can't ship a product using Endpoint Security.

Hm, the crash said it was a possible PA crash. Why would that happen if it's not available for user space code?

Note that it was a network extension that crashed.

My apologies; I forget I tend to rotate through my terms like BIND and A records. I use the term "applet" to mean an application which only shows up as a menu-bar item. Typically fairly small, our case isn't really any different, except that I rolled the extension loading code into it. It does a few things, including showing status, and ensuring that the extension stays loaded and running when it is intended to. I would prefer to have that capability in a daemon, but Apple insists that the network extension be loaded by an app that lives in /Applications and has the ability to (indirectly) invoke user interaction. Because we need it to run for each user, and not be (easily 😄) quittable (being a security-focused product), it is started as a LaunchAgent. So that's a single application. Just faceless, interacted via the menubar, and does the extension loading/unloading. (There's a bunch of other stuff, such as we need it to keep track of the extension's status because of crashes, and because on upgrades we sometimes get into a state where we can no longer communicate with it via XPC so we need to unload and reload it, so we need to have something ping it to check that, and so forth, and so forth, and so forth.) Does that make more sense?

Ok... so I'm still confused why there is a document saying "here's what you need to know about Pointer Authentication," which specifically mentions a couple of types and circumstances. Should I file a feedback request for improving that page? And the crash reports that say "this might be a pointer authentication crash"? 😄