Thanks for your reply The break list indeed reports that the breakpoints have been resolved to addresses. [A dissasembly of those addresses indicates the right code is involved]. This was done in debug builds, with optimization off.

Thanks Quinn - I'm back to working on this - will give it a try now. Will it make a difference if I'm using dispatchgetglobalqueue(QOSCLASSUSERINITIATED, 0) instead of the main queue? Devendra.

I'm trying to investigate problems related to performance with our Kernel Extension. This is an audio over ethernet solution, so it involves threads with time-constrained (realtime) priority and the network interface drivers. Thanks. Devendra. ps: I realize we need to move out of the kernel using NWEthernetChannel for our protocol, but we're waiting for Apple to provide a way to receive (and send) packets in realtime priority in user mode (FB7733818).

Hi Quinn, Thanks - yes I'm using the System Trace Instrument. Since this happens on a remote Mac (which doesn't have/want to install Xcode), I'm using ktrace (artrace) to capture a trace which includes the system trace and am using Instruments to analyze this. It would be nice to have taskinfo provide more details about the thread states, but I may be able to get by without it. Thanks for your help and suggestions. Will open the DTS incident if we need to go there. Devendra.

Thanks Quinn - that is a relief! (also Thanks for that link!). So if I want to simply send this app for internal testing (without the Developer ID signature) to other Macs - is it still possible (without having to add each Mac to the provisioning profile first)? I think I don't quite understand the role of having a provisioning profile with Developer ID apps. If you can point to some reference that explain this - it would be useful. Thanks. Devendra.

Thanks again Quinn for the clarification. Devendra.

Thank You Quinn! I was able to build a profile using this information, the Configurator 2 app, inspecting some other profiles, and tweaking the generated xml by hand. It would be nice if the Configurator 2 supported this directly. Here's what I used - in case someone else wants to do this. IMPORTANT: Please consider Quinn's warning about using this on a production Mac! xml ?xml version="1.0" encoding="UTF-8"? !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" plist version="1.0" dict keyConsentText/key dict keydefault/key stringThis will enable showing private strings and data in Unified Logs./string /dict keyPayloadContent/key array dict keyPayloadDisplayName/key stringManagedClient logging/string keyPayloadEnabled/key true/ keyPayloadIdentifier/key stringcom.apple.system.logging.89AE58D8-0A4A-448B-8AE0-761DEE2D007F/string keyPayloadType/key stringcom.apple.system.logging/string keyPayloadUUID/key string89AE58D8-0A4A-448B-8AE0-761DEE2D007F/string keyPayloadVersion/key integer1/integer keySystem/key dict keyEnable-Private-Data/key true/ /dict /dict /array keyPayloadDescription/key stringAllows showing private log messages./string keyPayloadDisplayName/key stringAllow Private Logs/string keyPayloadIdentifier/key stringcom.yourdomain.enable.private.logs/string keyPayloadOrganization/key stringYour Organization/string keyPayloadRemovalDisallowed/key false/ keyPayloadType/key stringConfiguration/string keyPayloadUUID/key string529DF49A-6CB3-4DE9-A29F-4C41EC88BFDD/string keyPayloadVersion/key integer1/integer Save the above in a text file - give it an extension .mobileconfig - and load it in Configurator 2 - and "sign it"! This can now be installed on any Mac. Thanks. Devendra.

Thanks Quinn for looking into this. Here's the situation... We have an Audio over Ethernet solution which communicates using our own Layer 2 protocol to devices connected on the (private) network. As part of this - we allow the user to select which Ethernet interface to use for this audio driver. Typical user workflow often involves the user wanting to select the interface in our software even when no device is physically connected to the interface - because they know where they will be connecting the devices later on. Or simply, they want to setup the rest of the system while the device (or switch) is powered down - etc. All of this is working well in our current releases - but we are using Kernel Extensions and the APIs available there. As you know, we need to move out of the kernel - and thus the need for NWEthernetChannel and friends. Thanks. Devendra.

Thanks Quinn - that's exactly what we ended up doing. It just sounds improper to have to use five different APIs (SCNetwork, NWEthernet, ifaddrs, DynamicStore, and sysctl) to work with the same network interface!! The sysctl is also needed to determine the link speed - we also need to show that to the user - as DynamicStore only provides link status. I hope this gets some attention from Apple in the future! Thanks. Devendra.

Hi Quinn, Agreed - we have some very unique requirements! We need the actual link speed - to be able to identify cable issues, for example. Regarding the enhancement request - I saw that other people had already file some. But I think you are quite right - more is better! So I filed one: FB9074593 - Need coherent APIs for using NWEthernetChannel. As always, Thank You for your support! Devendra.

Seems like this is a bug, so I filed a feedback - FB9077424 Thanks. Devendra.

Hi Quinn, You can get this from the BSD interface name (en7 in my example) using the old school BSD API (SIOCGIFXMEDIA). If I understand this correctly, this ioctl provides the settings - and may not be the actual speed that the interface is working on. (BTW all of that is also available via NWInterface APIs). What we would need seems to what the ifconfig utility seems to use - SIOCGIFLINKPARAMS, but that one seems to be PRIVATE - so we are not able to use that. Thanks. Devendra.

Thanks Quinn for the update! Devendra.

For others who may land up here - this is now fixed in latest Monterey beta. Thanks. Devendra.

Please provide some specifics. Perhaps attach the panic log here.