I submitted a bug report with a sample project: FB16502596

I cannot describe my relief when I found this thread. I also have a YOLO11 model that started behaving poorly in exactly this way sometime between last November and this week. Changing the computeUnits value didn't do anything, but changing the value of experimentalMLE5EngineUsage did.

Hi Kevin. Thanks for your detailed reply. We are not using NSEndpointSecurityEarlyBoot. None of the calls into Apple frameworks that we've seen lead to killing the extension are during our extension initialization. They're all in response to some event, e.g., ES_EVENT_TYPE_AUTH_MOUNT calls into DiskArbitration, ES_EVENT_TYPE_AUTH_OPEN calls into Security. Important to note: we only care about those OPEN events for a restricted set of paths (our files) and immediately return ALLOW for anything else. Here is a lightly redacted crash log: Process: com.redacted.EndpointSecurity [492] Path: /Library/SystemExtensions/*/com.redacted.EndpointSecurity Identifier: com.redacted.EndpointSecurity Version: v2.10.0-21-g35018b949c-dirty (58)Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2025-02-04 12:18:33.7447 -0500 OS Version: macOS 13.6.7 (22G720) Report Version: 12 Anonymous UUID: 6570580F-1EF2-E6B5-E10B-CA9F00455210 Time Awake Since Boot: 58 seconds System Integrity Protection: enabled Crashed Thread: 1 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace ENDPOINTSECURITY, Code 2 EndpointSecurity client terminated because it failed to respond to a message before its deadline Thread 0: 0 libsystem_pthread.dylib 0x18836ad8c start_wqthread + 0 Thread 1 Crashed: 0 libsystem_kernel.dylib 0x1883375c8 __sigsuspend_nocancel + 8 1 libdispatch.dylib 0x1881d3ba8 _dispatch_sigsuspend + 48 2 libdispatch.dylib 0x1881d3b78 _dispatch_sig_thread + 60 Thread 2:: Dispatch queue: BBReaderQueue 0 libsystem_kernel.dylib 0x18832fef4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x188342220 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x188338b58 mach_msg_overwrite + 604 3 libsystem_kernel.dylib 0x188330270 mach_msg + 24 4 CarbonCore 0x18b17b5f0 _scclient_ServerCheckinWithResult_rpc + 148 5 CarbonCore 0x18b17b3dc SCClientSession::checkinWithServer(unsigned int*) + 224 6 CarbonCore 0x18b17b0f0 connectToCoreServicesD() + 128 7 CarbonCore 0x18b17af1c getStatus() + 64 8 CarbonCore 0x18b17e308 scCreateSystemServiceVersion + 56 9 CarbonCore 0x18b17e17c FileIDTreeGetCachedPort + 276 10 CarbonCore 0x18b17df74 FSNodeStorageGetAndLockCurrentUniverse + 68 11 CarbonCore 0x18b17dd64 FileIDTreeGetAndLockVolumeEntryForDeviceID + 88 12 CarbonCore 0x18b17dbcc FSMount::FSMount(unsigned int, FSMountNumberType, int*, unsigned int const*) + 92 13 CarbonCore 0x18b17db28 FSMountPrepare + 76 14 CoreServicesInternal 0x18b4845dc MountInfoPrepare + 68 15 CoreServicesInternal 0x18b483f9c parseAttributeBuffer(__CFAllocator const*, unsigned char const*, unsigned char, attrlist const*, void const*, void**, _FileAttributes*, unsigned int*) + 2848 16 CoreServicesInternal 0x18b482f58 corePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 1248 17 CoreServicesInternal 0x18b482a04 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 452 18 CoreServicesInternal 0x18b47f86c _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 232 19 CoreFoundation 0x188422f5c CFURLCopyResourcePropertyForKey + 108 20 Security 0x18ac34fcc SecTrustEvaluateIfNecessary + 132 21 Security 0x18ac3699c SecTrustEvaluateInternal + 48 22 Security 0x18acc4fd4 decodeTimeStampTokenWithPolicy + 1320 23 Security 0x18acbf0a8 SecCmsSignerInfoVerifyUnAuthAttrsWithPolicy + 96 24 Security 0x18acc6294 SecCmsSignedDataVerifySignerInfo_internal + 696 25 Security 0x18acc6b60 CMSDecoderCopySignerStatus + 164 26 Security 0x18acde4d0 Security::CodeSigning::SecStaticCode::validateDirectory() + 956 27 Security 0x18ace2240 Security::CodeSigning::SecStaticCode::validateNonResourceComponents() + 24 28 Security 0x18ace6c38 Security::CodeSigning::SecStaticCode::staticValidateCore(unsigned int, Security::CodeSigning::SecRequirement const*) + 72 29 Security 0x18ace5c7c Security::CodeSigning::SecStaticCode::staticValidate(unsigned int, Security::CodeSigning::SecRequirement const*) + 308 30 Security 0x18acdae98 SecStaticCodeCheckValidityWithErrors + 228 31 com.redacted.EndpointSecurity 0x1004396ec 0x100430000 + 38636 32 com.redacted.EndpointSecurity 0x10043489c 0x100430000 + 18588 33 com.redacted.EndpointSecurity 0x1004361cc 0x100430000 + 25036 34 com.redacted.EndpointSecurity 0x100434284 0x100430000 + 17028 35 libEndpointSecurity.dylib 0x19af7d7d0 BBReader<ESMessageReaderConfig>::handleItems() + 356 36 libEndpointSecurity.dylib 0x19af7d558 BBReader<ESMessageReaderConfig>::woke(void*) + 28 37 libdispatch.dylib 0x1881c0400 _dispatch_client_callout + 20 38 libdispatch.dylib 0x1881c3884 _dispatch_continuation_pop + 504 39 libdispatch.dylib 0x1881d6e7c _dispatch_source_invoke + 1588 40 libdispatch.dylib 0x1881c7960 _dispatch_lane_serial_drain + 372 41 libdispatch.dylib 0x1881c862c _dispatch_lane_invoke + 436 42 libdispatch.dylib 0x1881c98e8 _dispatch_workloop_invoke + 1764 43 libdispatch.dylib 0x1881d3244 _dispatch_workloop_worker_thread + 648 44 libsystem_pthread.dylib 0x18836c074 _pthread_wqthread + 288 45 libsystem_pthread.dylib 0x18836ad94 start_wqthread + 8 Thread 3: 0 libsystem_pthread.dylib 0x18836ad8c start_wqthread + 0```

It doesn't. I checked both standalone binaries and .app bundles, and in both cases CMSDigest matches CandidateCDHashFull. The digests signed by the CTK extension are 256-bits, the same length as CMSDigest and sha256 CDHash, but not the same bytes. CandidateCDHashFull sha256=bc8686ef2e5092e3d6e133ed29521fad2db6d6e819c6d2752c8b480be6852fdd Hash choices=sha256 CMSDigest=bc8686ef2e5092e3d6e133ed29521fad2db6d6e819c6d2752c8b480be6852fdd

Thanks, Quinn! We'll take a look at the Darwin code and evaluate the effort there. In the meantime, I filed an enhancement request through Feedback Assistant: FB16386476.

I have the same need. There is some logic I want to run before a window closes. My SwiftUI window contains a NSViewControllerRepresentable view, and I can set the window delegate inside that NSViewController subclass and implement windowShouldClose:, but that interferes with something SwiftUI sets up and my window's resources are never freed on close. (The window goes away, but re-opening it shows the old window with whatever state it had, instead of instantiating a brand new one.)

I need to correct my last reply. After looking at my sample app again, it was calling NSWindow.sendEvent(_:). That works, but I should be calling postEvent(_:atStart:). After making that change, the sample app no longer scrolls. This doesn't appear unique to the VM view. Something more general in AppKit's event handling is rejecting my synthesized scroll event.

Here is some info on where I am with scroll events. Unlike keystrokes, flag changes and mouse clicks, these cannot be created directly as NSEvents, so I have to start with a CGEvent and create the NSEvent from that. There is some math involved to create the CGEvent at the proper location in the VM view in screen coordinates, but I believe I have that worked out. My local monitor (inside the VM host app) sees the event. Here is a dump of one: - NSEvent: type=ScrollWheel loc=(50,300) time=903547.3 flags=0 win=0x0 winNum=0 ctxt=0x0 deltaX=0.000000 deltaY=-10.000000 count:0 phase=None momentumPhase=None #0 - super: NSObject The part that jumps out the most from a real scroll event is that the win and winNum values are nil/zero. CGEvents, as much as I understand, sit at a lower level of the system and have no concept of a window. The conversion to NSEvent either doesn't attempt to identify a window or fails to do so. I've tried various ObjC tricks to assign a window, since in Swift this property is read-only. So far, no luck. Real scroll events have a window and flow into the VM just fine, where the global monitor there logs them. Synthesized events are dropped somewhere. They work in a sample app without the VM view. Again, this is an internal tool. It'll never be distributed, Mac App Store or otherwise, so I'm not opposed to some dirty tricks to get this working, even if it means revisiting it when it breaks.

This was the little push I needed. Thank you! I had tried sythesizing .flagsChanged events equivalent to key-down and key-up for the modifier key, but it didn't make a difference. I revisited it once you confirmed that it mattered. The flags are a 32-bit bitmask. There are the device independent bits, which are documented for each of the modifier keys plus some others, in the upper 16 bits. The lower 16 bits are not documented, but if you attach a monitor, you'll notice some are set. In particular, bits 3 and 8 (0x108) are set when the modifier key is pressed down, and bit 8 (0x100) is still set when the modifier is released. I turned my synthesized .keyDown/.keyUp pair into a sequence of .flagsChanged with 0x108 set for each modifier, .keyDown, .keyUp, .flagsChanged with 0x100 set. Injecting this sequence of events produces the desired behavior in the VM. Success! I don't like needing to set these undocumented bits, but my use case is for an internal tool and I can live with it. (Perhaps they can be documented and become part of the public API?) Now I'm hoping we can find a similar breakthrough for scroll wheel events! 😄

The VZVirtualMachineView is in a view hierarchy managed by an NSViewController subclass that is wrapped in NSViewControllerRepresentable, but I doubt that matters, so yes, mostly correct. I have tried both true and false for capturesSystemKeys and it does not change the behavior seen in the VM. Mouse scroll wheel events are similar. Real ones from my mouse scroll content in the VM, synthetic ones never show up in the global monitor in the VM and nothing happens.

Speaking of docs, I should be using NSWindow.postEvent(_:atStart:). Doing that instead now triggers the local monitor, but modified keystrokes still appear in the VM without modifiers and scroll wheel events don't do anything. The latter may be due to how I have to start with a CGEvent since NSEvent doesn't have direct support for creating scroll wheel events.

Yes, it does. "Create Info.plist section in binary" is set to true. Same bundle ID when run inside Xcode or standalone.

I have a project that shows the same error when running tests on macOS. I isolated the problem in a sample project yesterday and attached it to my feedback (FB11992869). The commit that broke it added the Keychain Sharing entitlement, which, unfortunately, is required for some of the tests.