dsym file

Yeah, HFS is now loaded from a KEXT, which is cool in general but makes things hard for DTrace. It would seem logical for the HFS KEXT’s .dSYM to be included in the Kernel Debug Kit but it is not. You should definitely file a bug requesting that. Please post your bug number, just for the record. If no one else chimes in, you might try asking over on the filesystem-dev mailing list.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Seeing the same issue. We started seeing this for a build which we uploaded to Appstore connect on July 27th 2021. Ever since then all of our bitcode enabled builds uploaded to appstore connect do not have matching UUIDs between the crashes reported and the dsyms downloaded from appstore connect. Even xcode organiser is unable to symbolicate these crash logs. This issue seems to be happening for app targets and not the extension targets such as Intent Service extensions. The app extension crashes appear symbolicated on xcode organiser. If it helps our Compressed File size on appstore connect is 274MB.

But what if I don't download the archive builds from Xcode Cloud and don't have them locally? Does that mean that I won't be able to symbolicate crash? I thought the crashes would be symbolicated in the cloud. It's not the case? When you submit your app to the App Store, there's an option for you to include symbol information as part of the app for that upload. When you do so, crash reports that appear in your Xcode Organizer for that app version will be symbolicated for you already. That's a feature of the App Store, and not specific to builds created and uploaded through Xcode Cloud. However, that doesn't mean you shouldn't download the archives from Xcode Cloud, that is still a best practice. One valuable part of that is access to the dSYMs, which are incredibly detailed debugging assets. While using the dSYMs for symbolication is one function they serve, they also enable significant debugging capabilities using LLDB that aren't possible without them. The symbol information for symbolicat

Please change to No the User script sandboxing under Build Settings. Also for further info: https://stackoverflow.com/questions/48296774/firebase-crashlytics-upload-missing-dsyms-to-see-crashes-from-1-versions-ios/79246834#79246834

Hello there, Instruments 14.0 has known issue to show disassembly for sybmols without access to DWARF information (dSym or executable with debug symbols). It was resolved in Instruments 14.1 which you can download with Xcode 14.1 from App Store or developer.apple.com/download. -- Anton

This issue is definitely not resolved.We are using bitcode, symbols uploaded, and after downloading the dsyms and attempting to manually symbolicate, we are still seeing `hidden` in the stacktrace, meaning we're currently in a frightening place where we cannot fix bugs in our production app.

I just switched to Xcode 16 and a new build machine and I’m getting the warning about missing dsyms. I see that they are in the archive but the UUID doesn’t match what App Store Connect is expecting. Is there a way to update App Store Connect with the new UUID?

Thanks Edford, but this page you mention doesn’t mention how to get the dsyms from Xcode cloud and there is no button to download from App Store Connect on those crash reports. https://help.apple.com/xcode/mac/current/#/devef5928039 can you point me to something that is updated for Xcode cloud?

I also just ran into this issue. I uploaded a build with Bitcode enabled on March 27th and there is no Download dSYM link in App Store Connect for the build although App Store Connect does say the build included symbols. Very frustrating as I am now unable to symbolicate any crashes from this version of my app.

For the record, I am answering my own question. Yes, 'atos' was the correct tool to use. The key was realizing that the '.archive' file was needed by 'atos'... In addition to the console text shown above, there was also this snippet: ... Binary Images: 0x10a062000 - 0x10a325fff +[devProdID] (2.2.3 - 3302) <9248A949-D5CB-3C44-924B-2A9403061E7B> /Applications/AppXYZ.app/Contents/MacOS/AppXYZ ... So the actual command which achieved the desired result was: atos -arch x86_64 -o /Users/steve/Library/Developer/Xcode/Archives/2021-09-10/AppXYZ 9-10-21, 9.05 PM.xcarchive/dSYMs/AppXYZ.app.dSYM/Contents/Resources/DWARF/AppXYZ -l 0x10a062000 0x000000010a069107

First things first, have you verified that the .dSYM has the matching UUID? QA1765 How to Match a Crash Report to a Build shows the steps. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com