XPC - Zonto keeps crashing on project load

Something new, I get this error msg when I first start a new project in DR. Tried to delete the offending file but the entire package is locked down, probably a core OSX service:

Doesn't seem to affect performance or doing work, but annoying that I can't find a resolution to fix it.

Nada?

If you're running into crashes on a Mac, go to the Help Menu and select "Create Diagnostics Log on Desktop." Also, provide a Mac System info file by going into Mac System Prefs -> About, and clicking "System Report." Save this file (as an SPX file).

Now, place both files on a download site like Dropbox, post the link here in a forum message and see BMD Support has to say.

Here we go, two docs saved in the cloud:

https://drive.google.com/file/d/1ho-NdM ... sp=sharing

https://drive.google.com/file/d/1b5gsLz ... drive_link

... and still nada.

Those links are not accessible. Please also upload the crash logs of the XPC-Zonto process. Those should be in ~/Library/Logs/DiagnosticReports and ~/Library/Logs/DiagnosticReports/Retired folders, which you can reach by typing or copy/paste that into Finder after doing menu Go>Go to Folder.

No longer needed, I finally took the machine to the Apple Store because the issues became too serious. Turns out the original factory firmware somehow became corrupted and started causing all mess of nonsense with the hardware.

The most obvious issue that proved it was a hardware issue was audio became heavily out-of-sync with any video playback source, whether streaming or a video file on the HDD. So bad it was nearly 1.2 seconds behind any video source being played.

Turns out this is yet another, "we're acknowledging the problem but we're not broadcasting it publicly" issue that Apple can fix, but won't outwardly admit exists, most especially with phone-based tech support who themselves are being kept in the dark.

The fix is a process they call, "revive" which flashes the firmware on the mainboard. ONLY the Apple Store can do this procedure as it requires being connected to their store-only diagnostic box.

There's no online tool available to tech support to do this because Apple wants to keep the lid on the process and, the proprietary box that does it.

Unfortunately getting to the point that they even did the "revive" was painstakingly long - and totally unnecessary, which took 3 hours of testing, testing and more testing. Totally ignoring all the previously done tests and the subsequent sys-diag report that was sent to Apple.

All this could have been avoided had they done what I asked for when I went to the store: The unit is under warranty, has documented serious issues and should be replaced with a factory-fresh unit. Nope, they stuck to their idiotic and OCD-style method of "going by the book" of a testing regimen.

I had a similar issue years ago with a G5 tower (before the Mac Pro came about) that also had some serious hardware glitches. Took the unit to the Apple Store under my paid-for "business warranty", they kept it for two weeks with no result. I finally took it home and diagnosed and fixed the issue myself in less than 24hrs.

Why am I sharing past details? Because this hardware issue caused a mission-critical situation in not being to get work done, and Apple's response was, "we'll get to it when we get to it...". No more.

Back in the day before moving to an Apple-only environment I used to build custom Win-Tel boxes based around Gigabyte or Asus boards. Had this firmware issue happened with one of those systems I could have simply gone to the website of the board manufacturers and downloaded the firmware-flash file and fixed it in minutes. Not half a day or, had I dropped off the Mini would have been DAYS.

I'm sick and tired of the Apple "all our stuff is inaccessible to you" lockdown mentality and, the completely nonsensical method "tech support" handles serious issues.

While Apple Silicon is most certainly the most advanced computer tech available today, I'm no longer going to deal with their total lockdown mentality when it comes to support, upgrades and being able to administer my own hardware when it comes to troubleshooting issues.

The M4 Mini is my last Apple computer. I'm going to get caught up with work, get paid and then put the M4 Mini up for sale and going to build my own WinTel system all over again.

Screw you, Apple. You're not going to put the cuffs on my ability to do work ever again.

Robert, I'm sorry you had this bad experience. I'm just an end-user like you, but I formerly worked in software development so here are a few comments:

I'm not sure your problem is related to Mac hardware, nor was the "revive" procedure indicated. That procedure, along with putting the Mac in "DFU mode," is supposedlynonly for cases where a Mac will not boot. It is documented here: https://support.apple.com/en-us/108900. On YouTube, if you search for "Revive a Dead Macbook," there's a video elaborating on this.

That said, if the "revive" procedure fixed your problem, and if no other corrective steps were taken, that implies it must have done something beneficial.

Since you never uploaded the XPC crash logs, I can't investigate that in detail, but I can explain a few items:

- MacOS runs video decoder software in external processes, which are accessed from the host process (Resolve in this case) via a cross-process XPC call. That is designed to improve stability and security.

- The crashing process was VTDecoderXPCServiceZonto, where VT = Video Toolbox, a low-level MacOS video framework.

- The "Zonto" term apparently refers to certain MacOS codecs which are x86-only. Some examples of these: AppleHEVCProCodec, AppleAVCLGCodec, AppleAVCIntraEncoder. By contrast, these are universal binaries (x86 + ARM64): DNXDecoder, AppleMXFImport, AppleAVCIntraCodec, AppleDVCPROHDCodec, AppleProResRAWCodec, AppleIntermediateCodec, AppleIMXCodec.

- I don't know why certain Apple codecs are x86-only. Apple often licenses codec technology through arrangements that may provide them with pre-compiled binaries rather than source code. Those might include contractual requirements about maintaining compatibility.

After the Apple Store did the DFU mode "revive" procedure, did that solve the problems? Or were other corrective steps taken? It would be useful to know the specifics in case other Resolve users encounter this scenario.

If you encounter a recurrence of this, if you post your Resolve logs and MacOS application crash logs at a location I can access, I'll be happy to examine those.

Robert, I'm sorry you had this bad experience. I'm just an end-user like you, but I formerly worked in software development so here are a few comments:

I'm not sure your problem is related to Mac hardware, nor was the "revive" procedure indicated. That procedure, along with putting the Mac in "DFU mode," is supposedlynonly for cases where a Mac will not boot. It is documented here: https://support.apple.com/en-us/108900. On YouTube, if you search for "Revive a Dead Macbook," there's a video elaborating on this.

That said, if the "revive" procedure fixed your problem, and if no other corrective steps were taken, that implies it must have done something beneficial.

Since you never uploaded the XPC crash logs, I can't investigate that in detail, but I can explain a few items:

- MacOS runs video decoder software in external processes, which are accessed from the host process (Resolve in this case) via a cross-process XPC call. That is designed to improve stability and security.

- The crashing process was VTDecoderXPCServiceZonto, where VT = Video Toolbox, a low-level MacOS video framework.

- The "Zonto" term apparently refers to certain MacOS codecs which are x86-only. Some examples of these: AppleHEVCProCodec, AppleAVCLGCodec, AppleAVCIntraEncoder. By contrast, these are universal binaries (x86 + ARM64): DNXDecoder, AppleMXFImport, AppleAVCIntraCodec, AppleDVCPROHDCodec, AppleProResRAWCodec, AppleIntermediateCodec, AppleIMXCodec.

- I don't know why certain Apple codecs are x86-only. Apple often licenses codec technology through arrangements that may provide them with pre-compiled binaries rather than source code. Those might include contractual requirements about maintaining compatibility.

After the Apple Store did the DFU mode "revive" procedure, did that solve the problems? Or were other corrective steps taken? It would be useful to know the specifics in case other Resolve users encounter this scenario.

If you encounter a recurrence of this, if you post your Resolve logs and MacOS application crash logs at a location I can access, I'll be happy to examine those.

Yes, it did resolve ALL the problems, which became many as the firmware's corruption became worse over time.

I don't know why the logs I uploaded to the cloud weren't available, but now it's irrelevant. I just looked and they were readily available on my Google Drive. Oh well...

The biggest issue for me about this failure was it became a mission-critical situation for my business. Even after paying the the "business services" package from Apple, which was supposed to provide priority repair handling and other "special" services, the Apple Store completely ignored that extra money that was spent and basically treated it like any other general consumer issue. "If you drop it off we'll get to it asap..." was what I got from both techs and managers. Unacceptable.

As I mentioned earlier had this been a system I built I could have simply downloaded the flash-file fix from the motherboard manufacturer and had this resolved in minutes instead of days.

Back during the PowerPC days of Apple (G5 tower) you could actually maintain things like the mainboard control chips. That all went away when Motorola chips were replaced by Intel, and it's 100% lockout now with Apple Silicon.

I've got nothing bad to say about the Mac platform as a whole and until this week I enjoyed the environment thoroughly. But this little bugger has been problematic since day 1, and I'm not putting my business at risk of yet another failure that brings work to a halt.

Although widely adopted by nearly every creative industry (with exception to the EU which would have stuck with the Amiga had Commodore not screwed the pooch) I truly believe Macs are not ideal for the rare breed like myself who not only wants access to all the parts and software, but also has the ability greater than the "geniuses" at Apple Stores to fix things on my own - with greater efficiency. That's just no longer possible with Apple Silicon. It's total lockout.

I'm the guy who wants access to under-the-hood, 100% percent of the time and I'll get it when I build my new PC-based edit suite.

Best.

As I mentioned, my Mac days are done. I just got a used Ryzen 7-based system with an MSI Tomahawk Max II motherboard and a Radeon RX 580 w/8GB of VRAM. I'm getting things all setup.

Although I was really proud to be an M4 Mini owner - at first, being back on a Windows system feels like coming home. This thing flies and yeah, it's WAY faster in everything than even the M4. Makes me wonder why I ever left the PC world.

Later when funds allow I'll build my own system based around a Ryzen 9 and happily spend $3K on a mega edit suite.

Can't wait.
Cheers