In the interest of education: a solution has been found...and maybe this is obvious to everyone. The reporting afforded by the environment certainly did not get me to this conclusion! The issue between packaged/hardened applications and the same code in development is: The PATH I finally set up a repeatable test where I didn't need to sign anything to get it to fail. After a couple of hours I had it pinned down to the process.Start() not being able to find the executable that I was trying to start! In development the external process was on the path...so everything just worked. In the hardened runtime the path is the barebones '/usr/bin'...etc. I am 'smarterer' now! ;) Thanks for all of your help!!

Thanks for the insight. I will try to explain a little more about what is happening at the point of failing...and to express my frustration that I can't even reproduce the problem outside of the hardened runtime. The application is processing MR images using a mix of our own code, in C# and a third-party MRI image processing suite, running in a docker/podman container. The application sets up the data so that podman can access it and then triggers a podman process to start its processing. The triggering happens by preparing a 'Process' object...like a command shell invocation. Like: podman exec <options> <container_name> <command> In development, this all works perfectly on all platforms. In packaged form, it works on Windows...because Microsoft has nothing even close to the hardened runtime in their distribution model. On the Mac, it generates the crash log provided above. This leads me to believe that I need some sort of Entitlement but which one? The test loop time is around 30 minutes and I don't which one might be the culprit. Alternately, I need some flag or other as-yet-unknown configuration in the ProcessStartInfo object. In C#, the ProcessStartInfo object describes the command that we intend to 'launch'. This object is injected into a Process object, and Start() is called. Something like: ... var process = new Process(); process.StartInfo = startInfo; try { process.Start(); } catch (ApplicationException exception) { Console.WriteLine(exception.Message); } ... If there's anything else I can offer, just let me know. I have resisted building a 'non-product' product that contains only the suspect code because it would mean packaging and signing something that isn't meant for distribution, which feels wrong. I now don't see any other way to ensure that I have truly isolated the offending code.

Any help you can offer will be fantastic and greatly appreciated. Our Mac testers are getting jealous of our Windows testers. We can't have THAT!! CVRAT Crash log