Thank you Kevin, I'll file the incident in a few hours. I'll try to get some fresh sysdiagnose logs as well. We didn't collect those because most users are in managed environments so we need to arrange everything with their admins. Is it always the same "5f45 4545" value being replaced? No, it's same value per instance, but different for each instance. I have no idea why that would have happened, but it would be interesting to confirm whether or not that pattern holds more broadly. Definitely not all instances are replaced. I can still find same sequence in the file. I'll send you the originals and corrupted files so you can see for yourself. At the beginning it looked like all instances of the sequence were replaced but once we got more of these corrupted files it's clear that's not the case - we were just lucky with the first ones. Just to clarify, was that the specific installer pkg they had, not just the same version? I want to make sure you've ruled out the possibility that the bad file wasn't already inside the installer. I think I pretty much ruled this out. I was originally suspecting that admins were installing some modified packages so I asked if I can get those, but they were either links to our CDN or just unmodified packages.

So I found following being all over the logs when issue occurs: HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload The machine is i9 with 64GB of RAM basically idling. Edit: Found another message which seems to lead to source of the problem: HALS_OverloadMessage: Overload due to client running as an adaptive unboosted So indeed it seems to be some priority problem?

Hello Kevin, I found the issue but I'll reply anyway as it may be useful to other people. Are you seeing this issue on later system versions? No, it looks like it's only Monterey, specifically the last two minor releases which I tested on. Is your XPC service directly presenting it's own window(s) or is this coming through your main app? Yes, I'm starting a NSApplication on main thread and the service listener on a second thread. That's only difference to regular XPCService template running just xpc_main(). If you're not already doing so, you may want to try having your app using "beginActivityWithOptions" to ensure that it's remaining active. I tried this both in application and xpc service and it didn't had any effect. I even tried task_policy, setting main thread to user interactive. Particularly on a old system like this, you may find that periodically "resetting" the message (say, every minute) works better than simply holding the same message "forever". I tried exactly this and it works. I was sending the reply block only at the start of the application to kickstart the service and boost it. Sending the block again before I want a playback seems to fix the priority problem on Monterey and doesn't have any side effects on newer systems. I still have a question though. Is there any recommendation how to investigate xpc service priorities (or QoS in general)? I tried launchctl print pid/13422/com.my.service and it gives handful of information but nothing I could figure out the boosting was not working correctly (spawn type seems to reflect only the startup priority). Also in Instruments I was using time profiler, system trace etc. and it shown the correct application lifecycle ("Foreground") but sound was still broken.

[quote='812085022, DTS Engineer, /thread/767612?answerId=812085022#812085022'] If you use the Finder to copy the app off the disk image to somewhere else — say the Applications folder or, if that already have an app of the same name, your home directory — will the app launch from there. [/quote] It doesn't help. I copied it (drag & drop in Finder) from DMG to ~/Desktop and to /Applications and it shows the same dialog. The quarantine attribute is preserved no matter what I do with the bundle. Opening the application from context menu (secondary click on the bundle in the Finder) also yields the same result.

It says that ticket is missing: $ syspolicy_check distribution /Applications/VLC.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: VLC.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error When I run the stapler on it the error goes away but app still doesn't start: $ stapler staple /Applications/VLC.app Processing: /Applications/VLC.app Processing: /Applications/VLC.app The staple and validate action worked! $ syspolicy_check distribution /Applications/VLC.app App passed all pre-distribution checks and is ready for distribution. I ran also the spctl before the stapler: $ spctl --assess -v /Applications/VLC.app /Applications/VLC.app: File created by an AppSandbox, exec/open not allowed

[quote='812627022, DTS Engineer, /thread/767612?answerId=812627022#812627022'] Is your product distributed on the Mac App Store? Or have you sandboxed it because that’s the right thing to do? [/quote] It's not distributed on Mac App Store (but it may eventually get there). But we do the sandboxing because it's right thing to do given the app is basically a web browser in disguise.

Thank you Quinn, I tried the com.apple.security.files.user-selected.executable and it didn't help. [quote='812817022, DTS Engineer, /thread/767612?answerId=812817022#812817022'] And if that doesn’t work for you then the next best option is to un-sandbox the code that creates this disk image. My standard approach for that is to embed an XPC service in the app, because the embedded XPC service can have a custom sandbox, including no sandbox. [/quote] None of these is actually an option for us. We would be eaten alive by security folks in the company if we would disable sandbox. I was looking into it more and dumped the kCFURLQuarantinePropertiesKey: { LSQuarantineAgentName = "Download Helper"; LSQuarantineIsOwnedByCurrentUser = 1; LSQuarantineTimeStamp = "2024-11-11 16:36:18 +0000"; LSQuarantineType = LSQuarantineTypeSandboxed; } That LSQuarantineTypeSandboxed caught my attention and found an older post 650470 stating: That type indicates that the process was touched by a sandboxed process that didn't have permissions to write that file. So maybe it's a same problem like with location services, which don't (or don't used to) consult responsible process for entitlements or something. What entitlements this could be related to, the hardened runtime stuff maybe?

[quote='813819022, DTS Engineer, /thread/767612?answerId=813819022#813819022'] I’m not entirely sure how this flag is getting set on your executable. I tried various mechanism to get it set in a test app, and failed. [/quote] Me either, I'm trying to re-create the problem in isolated form, but the quarantine flag is different. [quote='813819022, DTS Engineer, /thread/767612?answerId=813819022#813819022'] My understanding is that: This flag is set on the executable you’re trying to run. That executable exists on a disk image. If so, what does the com.apple.quarantine attribute look like for: The root of the disk image? The .dmg file itself? [/quote] Just after I download the image it looks like: $ xattr -l /Users/luweber/Downloads/vlc-3.0.21-intel64.dmg com.apple.macl: com.apple.metadata:kMDItemWhereFroms: bplist00?_?https://[redacted]/download?id=abbd13b7-f1b7-4fd2-9e51-72e3d790ad83 ? com.apple.quarantine: 0087;67345866;Download Helper; Then I mount it, but image root, nor the app bundle has a quarantine flag: $ xattr -l /Volumes/VLC\ media\ player com.apple.FinderInfo: $ xattr -l /Volumes/VLC\ media\ player/VLC.app $ xattr -l /Volumes/VLC\ media\ player/VLC.app/Contents/MacOS/VLC Finally when I copy (drag&drop in Finder) application to /Applications: $ xattr -l /Applications/VLC.app com.apple.quarantine: 0187;67345866;Download\x20Helper;

Hello, I found the source of the issue, it may be useful to someone. Our helper app is having LSFileQuarantineEnabled in the Info.plist as it was designed to run without sandbox and delegate to sandboxed helpers. Removing LSFileQuarantineEnabled from the helper fixed the com.apple.quarantine to be set to correct value Thank you Quinn for helping, your last post sent me thru a rabbit hole to find out, it's absolutely obvious now of course :D