Determing cause of a crash with a generic stacktrace

We've recently realized there's a pretty large discrepancy between the crash rate Crashlytics has been reporting and the crash rate reported in App Store Connect. Historically, we've been hovering at above 99% crash-free users / sessions as reported by Crashlytics. However, recently we've noticed App Store Connect has reported our crash rate to be between 3.5% and 4% for much of our app's recent history (i.e. the last year). How is this crash rate determined?

After diving into Xcode's organizer to look at crashes, we found one particular crash that has been occurring quite a bit. Unfortunately, it has a pretty generic name and stacktrace:

CoreFoundation: __CFRunLoopServiceMachPort + 160

8       UIKitCore                 -[UIApplication _run]
9       UIKitCore                 UIApplicationMain
10     tenpercenthappier   main
11     dyld                          start

Are these crashes being missed by Crashlytics, or is there some issue with dSYSMs in Crashlytics?

Any thoughts or suggestions for how to figure out what's going on here would be much appreciated.

Are these crashes being missed by Crashlytics, or is there some issue with dSYSMs in Crashlytics?

This isn’t a specific answer, but if using a 3rd party crash reporter you should start with a little light reading on Implementing Your Own Crash Reporter.

"Are these crashes being missed by Crashlytics"

Crashlytics can only know about a crash if the app runs after a crash has occurred and in addition Crashlytics gets a chance to upload crash reports.

If there's a crash that occurs upon app launch, then the app and hence Crashlytics might not get the chance to run long enough in order to upload crash reports before the app terminates due to the current crash. i.e. if its a crash that always or often occurs at app launch, then Crashlytics probably won't have the execution time it needs to upload reports.

Determing cause of a crash with a generic stacktrace
 
 
Q